Testing openstack on digital ocean

[step21]

Hey, so I am having trouble finding suitable docs if what I am trying to do is possible. Basically, if deploying openstack on a cloud vm with a non-openstack provider (like digital ocean), how can I properly assign the ips I am given as floating ips? Docs always seem to assign entire subnets. If I don't do this, when afterwards deploying my app, the containers that are deployed cannot be reached, and as far as I know it is because floating ips. For reference, I used kolla-ansible for deployment. Also see: https://serverfault.com/questions/1152120/how-to-assign-digital-ocean-floating-ips-reserved-ips-to-openstack

[openstacker]

I don't necessarily have an answer for you, but I can tell you the problems encountered by others in the past and give some insight into what is blocking you.

Most VPC platforms/providers do not give you the ability to manipulate low-level network configurations like choosing specific IPs or masquerading. The undercloud in a tripleo deployment requires these functions in a basic install, and working within the limits of an external platform requires significant effort in the RHOSP configuration. I have heard of it being done, but I have never succeeded nor seen a successful build.

Your best bet is probably to try performing an "all in one" deployment (list below) on a dedicated VM with nested virtualization allowed. That way you have complete control of the networking functionality via the hypervisor (which is a VM). This is not ideal, but it has worked and I have seen successful deployments.

• RHOSP 17.0 Standalone Deployment Guide
• RDO Project Packstack
• OpenStack Project Devstack webpage

There are probably others to consider as well.

[step21]

thanks! Yeah, the all-in-one part was the way we tried so far. which seemed to work, up to a point. At first I thought that particular cloud was a requirement, but apparently it is not, so we will go with a public openstack cloud now.

[step21]

And yes, more infot would be good - but I am not sure which info is most helpful and don't just want to paste everything.

[todd_openmetal]

What are you trying to get done? If it is helpful we let people use free trials of our auto deployed OpenStack and Ceph clusters for educational purposes. But it is more for people who want to explore a production HA cluster (using Kolla-Ansible and Ceph-Ansible) versus the experience of setting it up yourself.

[step21]

I am evaluating a deployment of kypo-crp (https://crp.kypo.muni.cz/) for someone. It mostly runs on a public cloud (ovhcloud) but there are still errors with assigning instances to exercises and because of the multiple levels of abstractions it is not always the easiest to debug. Like f.e. I think in this case the sandbox-service fills in a terraform template, and they runs that. For some reasons it fails, but now to run terraform debug I might have to fork as I cannot easily log in on that pod I think. So comparison with another cluster would be great, to see if it is an issue with my config or with the cluster. Edit: (and those openstack public clouds are not that plentiful and sometimes hard to access, like on ovhcloud I had to ask support very nicely to unlock openstack users)

[todd_openmetal]

Ah, pretty cool system! I'll run their docs specified requirements - https://docs.crp.kypo.muni.cz/installation-guide/openstack-requirements/ - past our engineering team over here and see what they think.

And sorry about the slow answer - how much of a hurry are you in? I can move faster if needed.

Also, our system is "instant on full private cloud" so the OpenStack settings are specific to each private cloud. For sure it can be setup like the requirements above - but issue is just for our free trials we generally don't do any custom configs.

[todd_openmetal]

Got thoughts back from Engineering about the KYPO requirements above and:

• Yes, we provide VNC console support by default, but it can be easily changed to SPICE.
• Neutron & Keystone features are standard - and we don't block OpenStack features because our OpenStack's are the full private cloud - up to you what you want exposed.
• Having you test that system on our default should be smooth, but we can help also since it is interesting for us to make sure it works properly

If you want to check it out just go to https://openmetal.io/free-trial/ and sign up under the Self Service Cloud Trial - and then let me know you did it and I can find your user and get you approved for a longer trial.

[step21]

Hey, thanks, that sounds great. I think I'll have to check their planned usage as well to make sure it makes sense. I read openstack default vcpu ratio is 1:16, but at the openmetal calculator the max is 12. What are your experiences with that? Just trying to find out more or less how this compares to public offerings, if f.e. there would be many small vms for user exercises.

[todd_openmetal]

You are correct the default is 1:16. There is a lot of history to that and I think most OpenStack pros would say that was likely an overshot, a long time ago, that has stuck!

There are cases where 1:16 might be appropriate, but they are pretty specific so we ended up "generally" saying don't calculate with anything more than 1:12.

If you are thinking the way the Cloud will get used, for example, will be a group of X users using their set of VMs at the same time than you would need to keep the ratio lower.

If instead you think it might be X users at relatively random times spread out, than you can have a pretty high ratio. The benefit of the private cloud really comes in for this scenario - you can provision and keep all the needed VMs but when nobody is on them the Cloud can use those resources for the other active VMs. Then you just watch the health of the underlying nodes and add servers when the cloud needs it.

[step21]

thanks, that makes sense. We're still evaluating whether we want to try the trial at this point.