Use Openstack VMs to access bare metal nodes, in addition to the Headnode service.

[naved001]

This was suggested by @okrieg

Rather than HIL spawning up VMs to access your HIL nodes, we should just use Openstack VMs to access them. Of course, there are some per-requisites for this to work.

• HIL should be able to manage vlans on openstack controllers and computes.
• HIL should be using keystone.

I am still mulling over how this would be implemented, once I am sure, I'll propose this in a deatiled spec file. For now we can use this space for discussion about the pros and cons.

cc: @zenhack @SahilTikale

[zenhack]

What happend to the openvpn idea? We were going to junk the headnode system entirely in favor of that, and the last I heard it was just a matter of nobody having implemented it.

[naved001]

I think rather than just entirely gutting out the head-node service, we should just make it another micro service that would work with HIL. So those who don't have an openstack cluster side by side, can just use the headnode service or OpenVPN.

So we can provide these 3 services with HIL:

1. Headnode service
2. Openstack VMs service
3. OpenVPN

One question about OpenVPN: As I understand, OpenVPN will connect a tenant's computer to a linux bridge on the HIL server, yeah? Wouldn't it be risky to provision from a remote host like that (connection issues/latency)?

If you guys think that Headnode service doesn't offer anything in addition to OpenVPN then we can just get rid of it.

[zenhack]

I don't think it makes sense to maintain our own VM service, unless we have a clear sense of why something existing doesn't fit the bill. There has to be something out there that's lighter-weight than openstack for just "I want a one-off VM," and it's not like we have something respectable that we'd be working from. The existing headnode functionality is pretty terrible, and writing something like that is its own project.

Re: connection issues/latency, the thinking at the time was that most likely folks would bootstrap off of a VM or something in the same datacenter; the connectivity wouldn't be much worse (if at all) than a HIL managed node.

While they could just use their laptop, it has the problems that you mentioned.

It's also worth noting that you only have to provision the first node externally; from there you can use one of your HIL managed nodes for provisioning.

[naved001]

I agree that we don't have to maintain a separate headnode micro-service as that would be a lot of work.

@SahilTikale @apoorvemohan @okrieg and I had some discussion regarding this.

• The reason @okrieg suggested using openstack was because it already does VMs and VPNaaS. So we don't reinvent those services. Other reason being, that in theory, it should be simple to implement (import VLAN networks into Openstack, and connect the VMs to it). Though, somebody will still have to play with it.

• For people who don't have an openstack cluster running by their side, we tell them to put an OS on their node using BMI (or some software provisioning tool), and then use a node as a gateway. Given the current state of BMI, I am not very confident about this approach.

Can people tagged on this comment add more to what we had discussed?

[zenhack]

For people who don't have an openstack cluster running by their side, we tell them to put an OS on their node using BMI (or some software provisioning tool), and then use a node as a gateway

How? The whole point of the functionality we're discussing is that we need a way for a user to bootstrap their way into being able to provision; if we plan to use openstack for that, then this introduces a hard dependency on openstack.

in theory, it should be simple to implement (import VLAN networks into Openstack, and connect the VMs to it). Though, somebody will still have to play with it.

1. Nothing involving openstack is ever easy to implement.
2. From what I can tell, Neutron's VPNaaS is nowhere near supporting VLANs. From https://wiki.openstack.org/wiki/Neutron/VPNaaS#Overview:

for the short term we would want to deliver a basic experimental reference implementation based on opensource for IPsec based VPNs using just static routing that will allow us to evaluate the API, resource model and usability of this feature. This will allow us to gather feedback, and make enhancements if required.

...and frankly if the openstack folks are calling it experimental, it's probably nowhere near ready for anyone to use for anything.

Adding hard dependencies on openstack is a massive violation of the tools-not-policy approach that we've had for HIL since the beginning. I am dead set against this.

Re: Reimplementing VMs, we don't need to do that for the openvpn approach, and that was kinda the point. Folks can connect from any box, anywhere, without us having any VM related logic anywhere in the proximity of HIL.

I think you guys are:

1. Dramatically underestimating how complex doing this with openstack would be in practice.
2. Dramatically overestimating how complex the openvpn approach is.

I'll try to find time in the next couple days to write up a more concrete proposal for the OpenVPN approach. I expect it will be simpler than obmd.

[naved001]

will be addressed by this #936

[zenhack]

Can we close this? @naved001, do we have a consensus that this is not the right solution?