Chris, Do you (or anyone else for that matter) know if there are plans for the option of a standardized output format in the CLI? It doesn't seem to exist now, though I did find a ticket for JSON output ( https://bugs.launchpad.net/python-novaclient/+bug/1254351), but it was closed because another patch that included the same functionality was in progress, and I couldn't find any more details. If that feature was available it would make a good middle ground.
Cameron On Wed, Jun 25, 2014 at 1:00 PM, Christopher Wolfe <[email protected]> wrote: > 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 > > > >
