Cameron, All,
I agree that, in principle text processing is fragile, but I think that
the salient point is that the PERL library is not well supported (assuming that
is, in fact, the case). Around the Essex-Folsom transition, there were a bunch
of OpenStack API changes that renamed various CLI options, etc. The intent
appears to have been to standardize the symbology across the various APIs, a
goal which I believe they have largely achieved. I'm not 100% hip with upcoming
changes in OpenStack, but the only CLI changes I can see coming are possibly
updating any holdover quantum-xxx to neutron-xxx names (most of these are
already updated, but there may be a few; ones I've noticed have been in config
files, and not the CLI API anyway). However, the output format of the OpenStack
APIs has become quite standardized (commands generally output one of three
formats: table, XML(YAML?), JSON, or can produce custom format specified by CLI
options). I think the problem with investing in the PERL API is that you'll be
stuck with whatever level of support the maintainer provides, ad infinitum. On
the other hand, working with Young Oh's code means that necessary changes can
be made expediently and without hacks around a middle-man. In short, I don't
see the OpenStack API changing at a pace that would render Young's code
obsolete, but I could imagine a scenario where the PERL module becomes out of
date and requires special effort to prop up. Of course, the point is moot if
the PERL api is, in fact, well supported.
As an aside, the burden of text processing could be alleviated somewhat
by using the JSON output format and letting well-worn libraries do the actual
parsing.
Regards,
Chris
-----Original Message-----
From: Cameron Mann [mailto:[email protected]]
Sent: Wednesday, June 25, 2014 2:38 PM
To: [email protected]
Subject: Re: OpenStack Module
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
>
