Hi all, We had a call earlier today to discuss which OpenStack module we should focus our development efforts on and at this point a community decision is required. For reference, Young Oh's module is available in trunk and ours is on GitHub (https://github.com/cybera/openstack-vcl-module). Our module is based off Young's original module which we've also used successfully in production with only minor modifications. Both modules are perfectly feasible, and I think the end product won't differ much regardless of which we use, but there is one key decision that needs to be made.
Young's module currently calls out to and parses the output of the Nova command line client to interact with the OpenStack API whereas we use a third-party Perl SDK (https://github.com/ironcamel/Net-OpenStack-Compute). The command line client is a more difficult and fragile approach (parsing textual output), but it's an official OpenStack package. There's no risk of it lagging behind OpenStack releases, so while breakages are more likely, they'll occur in areas that we can fix in the provisioning module. The SDK is easier and safer to work with since it's a programmatic way of accessing the API, but it's a third party package maintained by apparently one person. I believe OpenStack's API has generally been very stable; new features are added instead of changing existing ones, but there's always the remote possibility a change breaks the SDK and it never gets fixed which would require replacing it with something else. There are other differences between the modules, but they're relatively minor and are going to be changed for general release regardless so the choice really comes down to which of these approaches the community would prefer. Cameron On Mon, Jun 16, 2014 at 9:59 AM, Andy Kurth <[email protected]> wrote: > I think we're all in agreement that removing dependencies on /etc/hosts is > an improvement. I'm working on this and should have the changes committed > this week. > > To summarize the situation and changes, the backend code currently reads > /etc/hosts in order to determine the private IP address of a node. It does > not rely on the computer.privateIPaddress field in the database. Several > node configuration tasks depend on knowing the correct private IP address. > The backend code also currently uses the computer.hostname value to SSH > into nodes. As a result, it depends on hostname-private IP address > resolution working correctly -- which is usually accomplished via > /etc/hosts. > > I will change the code to: > (1) Not read or reference /etc/hosts at all > (2) Use the computer.privateIPaddress field as the authoritative value > (3) Use the private IP address instead of the hostname for all SSH and > other connections > (4) Add utils.pm::update_private_ip_address > > This will allow any provisioning module to have control over how private IP > addresses are allocated. If they are dynamically allocated when a node is > loaded or instantiated, the provisioning module can retrieve the dynamic > private IP address from Openstack or some other provisioning API, and call > update_private_ip_address to set the correct value in the database. The > provisioning module should also call $self->data->set_private_ip_address. > When control is passed from the provisioning to the OS module, everything > should be set up correctly. > > -Andy >
