Hi All, I've committed my OpenStack module that replaced OpenStack CLIs to OpenStack Compute APIs v2. I've took a look at the details of OpenStack Perl SDKs and referred some of their features to my module like how it handles OpenStack Compute APIs. This update OpenStack module uses LWP::UserAgent (OpenStack Perl SDKs uses both LWP and HTTP::Request) to both dispatch web requests and receive responses so that it can avoid parsing text outputs from running OpenStack CLIs (previous module) and also can avoid using OpenStack Perl SDKs. Thus, I think this update module can be a solution to integrate two versions of OpenStack Modules. I've tested the update module in RHEL 6.5 x64 with OpenStack Icehouse and I could successfully provisioning and capturing a CentOS 6.3 x64. Please check the update opentack module ( https://svn.apache.org/repos/asf/vcl/trunk/managementnode/lib/VCL/Module/Provisioning/openstack.pm) and let me know about your opinions.
Thanks, Young-Hyun On Tue, Jul 1, 2014 at 12:29 PM, YOUNG OH <[email protected]> wrote: > 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 >> > > >> > >> > >> >> >
