Move microservice feature not available through Controller REST API

[cilicivan96]

Hi,

I am creating a dynamic edge network where service migrations are automatically triggered based on different parameters, so I wanted to know if moving a microservice feature will be available through Controller REST API as it would make the automatic system control much easier?

Also, I’ve noticed when triggering move microservice command that in the output of iofogctl get microservice command the microservice status is instantly RUNNING and the agent is changed to the new one even though the service is not immediately available on the new agent. After some time it changes status like it should: STOPPING -> DELETING -> RUNNING and then the service is available on the other agent.
It is important for me that I know the exact moment when service is available on the other agent so I can forward the traffic to that agent.
Is there a possibility of modifying this behavior in the future releases?

Also, as I understand, this feature is implemented in a way that the microservice on a prevoius agent is stopped and deleted only after the microservice on a new agent is running (which is great approach for my point of view) so can this be somehow shown when retrieving microservice information?

Thanks in advance!

[SergeRadinovich]

so I wanted to know if moving a microservice feature will be available through Controller REST API as it would make the automatic system control much easier?

iofogctl makes a series of Controller API calls to perform a Microservice move procedure. It uses the iofog-go-sdk to do this so your automation could do the same.

What programming language were you hoping to implement the automation in? We have a number of SDKs but not all support Microservice move calls at the moment.

Also, I’ve noticed when triggering move microservice command that in the output of iofogctl get microservice command the microservice status is instantly RUNNING and the agent is changed to the new one even though the service is not immediately available on the new agent. After some time it changes status like it should: STOPPING -> DELETING -> RUNNING and then the service is available on the other agent.

I will create a bug ticket regarding the Microservice status transitions when a move occurs. Thank you for the thorough explanation!

[cilicivan96]

Hi, first of all thank you for the prompt reply

What programming language were you hoping to implement the automation in? We have a number of SDKs but not all support Microservice move calls at the moment.

cilicivan96:

I am using NodeJS for system implementation and as far as I see NodeJS SDK only has support for microservice development and not for interaction with controller. But thanks for the link to the implementation, I’ve seen it only makes microservice update with agent being changed so I did the same using Controller API.
In the end I realized that microservice is not available throughout the migration process meaning that microservice is stopped on the previous agent before it is available on the new one. Is this expected behavior or a bug?
As I can’t afford microservice down-time in my system I will have to create completely new one and then after it is running I will delete the old one. It would be perfect if it could be done within migration process that is why I am asking this question.

Thank you again for your help!

[SergeRadinovich]

In the end I realized that microservice is not available throughout the migration process meaning that microservice is stopped on the previous agent before it is available on the new one. Is this expected behavior or a bug?

This is expected behaviour as of now. The Controller will update the Microservice information when the iofogctl move microservice ... command is executed. The corresponding Agents will then pick up the change and simultaneously bring the Microservice up and down on the moved-to Agent and moved-from Agent, respectively.

As I can’t afford microservice down-time in my system I will have to create completely new one and then after it is running I will delete the old one. It would be perfect if it could be done within migration process that is why I am asking this question.

The best thing to do is make a feature request through a Github issue to the corresponding repository (Controller in this case). Please tag the issue with bug label so that a ticket is created for us automatically.

[drluckyspin]

Just curious - why can you tolerate down time? Is it because messages might be lost or something like that that?

If you are moving the micro service is something external pointing at it?

[cilicivan96]

The best thing to do is make a feature request through a Github issue to the corresponding repository (Controller in this case). Please tag the issue with bug label so that a ticket is created for us automatically.

I will do it like this. Thank you for the information and quick replies

Just curious - why can you tolerate down time? Is it because messages might be lost or something like that that?

It’s because I have some devices connected to a microservice, but my system discovers a node with better performanse so while I’m migrating the microservice to that node (in ioFog it’s called an agent) I still want to have the previous one available, otherwise my devices won’t have a microservice to connect to for some period of time (sometimes more than 10 seconds which is unacceptable for my system).