Hi Christopher, As I know, the format option is available for the openstack-neutronclient but not openstack-novaclient yet.
-Young On Mon, Jun 30, 2014 at 4:11 PM, Christopher Wolfe <[email protected]> wrote: > 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 > > > > > > > > >
