3 answers
- 210
Brian, the OOM project has a solution to this problem in the docker/kubernetes space. Each project has a deployment specification yaml file that not only lists dependencies but ensures that containers come up in a specific order. This takes the "art" out of ONAP startup. OOM is ready for use now (see the OOM User Guide and watch the demo which is 13 minutes long) on your own environment and we are working with the Integration team to get OOM ready for everyone. If you're only interested in a subset of ONAP that is supported as well.
Porting this back to the VM environment may be possible but is not part of the OOM team's mandate.
The OOM team is happy to help you out if you'd like to try it out, just let me know.
- Brian Matt
Thanks! I've played with this on my desktop at home with 48GB of RAM. I did have some issues with AAI actually starting for some reason. I may look at trying it on our openstack environment though.
- Roger Maitland
AAI is currently looking good now (but OOM gets STAGING-LATEST so no guarantees) - Michael O'Brien keep track of the status here: ONAP on Kubernetes#ListofContainers and the integration team is tracking status here: ONAP master branch Stabilization
Add your comment... - 210
Brian Matt You can also leverage Heat "depends_on" attribute to boot specific components first. Update the heat template accordingly will easily solve the problem in VM based deployment.
aai1_vm:
type: OS::Nova::Server
depends_on: aai2_vm- Brian Matt
Thanks! I was going to look into this as well. I think the only limitation here would be that is when openstack starts the VM, I think the install/initialization scripts may be the bigger sticking point, though staggering them can definitely help.
Add your comment... - 210
i dont have a list for you, but for things that need to be after other things (like aai needs to be after dmaap). you can reboot the vm and it will restart everything.
Add your comment...
I know we've run into some issues with certain VMs/applications not booting in order. With the current heat template there isn't any gaurantee that a certain app is running before another. We know that DNS must be up before many others to talk to other applications, this usually isn't an issue as the docker pulls generally take longer to do that DNS can boot.
We are using a shared environment with not a whole lot of bandwidth to initialize the environment in vanilla openstack. We have a number of challenges that seem to prevent things from starting properly, many of which we believe are due to certain applications booting up before another and then failing. Do we have any good information available on what should come up first?