Cameron,
AFAICT, the [--request-format {json,xml}] option is applicable to
virtually all of the latest CLI executables. Whether or not they correctly
observe the options, I can't say. I've used the CLI commands extensively, but
have only ever needed the default table format. I'll try and assess the current
state of JSON output compliance and get back to you.
Regards,
Chris
-----Original Message-----
From: Cameron Mann [mailto:[email protected]]
Sent: Monday, June 30, 2014 3:13 PM
To: [email protected]
Subject: Re: OpenStack Module
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
> >
>
>
