Re: [openstack-dev] [all] etcd3 as base service - update
On 6/7/17 4:47 AM, Davanum Srinivas wrote: > Team, > > Here's the update to the base services resolution from the TC: > https://governance.openstack.org/tc/reference/base-services.html > > First request is to Distros, Packagers, Deployers, anyone who > installs/configures OpenStack: > Please make sure you have latest etcd 3.x available in your > environment for Services to use, Fedora already does, we need help in > making sure all distros and architectures are covered. As a Solaris OpenStack dev, I have a questions about this change. If Solaris were to *only* run the nova-compute service, and leave the rest of the OpenStack services to Linux, is etcd 3.x required on the compute node for Pike+ ? Thanks! -Drew __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack moving both too fast and too slow at the same time
This email is meant to be the ML discussion of a question I brought up during the TC meeting on April 25th.; [1] The TL;DR version is: Reading the user survey [2], I see the same issues time and time again. Pages 18-19 of the survey are especially common points. Things move too fast, no LTS release, upgrades are terrifying for anything that isn't N-1 -> N. These come up time and time again How is the TC working with the dev teams to address these critical issues? I asked this because on page 18 is this comment: "Most large customers move slowly and thus are running older versions, which are EOL upstream sometimes before they even deploy them." This is exactly what we're seeing with some of our customers and I wanted to ask the TC about it. Thanks, -Drew [1] http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-177 [2] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 1/16/15 9:08 AM, Doug Hellmann wrote: > We are, and as this conversation has veered off in a destructive > direction, I think we should back up and look at the compromise Radomir > posted [1] to see if that solves the original technical problem we all have. > > Does having the requirements specified in a JSON file, without requiring > a specific build tool to install the files, solve the packaging, > testing, and deployment issue on platforms where node.js isn’t supported > natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. -Drew __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 1/14/15 11:49 AM, Michael Krotscheck wrote: > > Solaris is supported by node.js: > > x86 is certainly supported. Always has been. That's not the issue in > question. My point was that SPARC is not supported. > > > I think Oracle's got enough money to support Node.js on SPARC. How is money relevant here? > > > I think Solaris is no longer relevant > > I won't stoop to comment on this statement other than to say Solaris > is quite relevant to Oracle, Oracle's customers and Oracle's partners. > > > I won't stop to comment on this statement other than to say Javascript > is quite relevant to Oracle, Oracle's customers, and Oracle's partners. > > Your argument is a boondoggle. Refusing to use node because your > favorite platform doesn't support it is not the fault of node.js, it's > the fault of the platform. Under no circumstances am I refusing to use it. I stated in my original email ... ---8<--- For Solaris, a requirement on Node.js is especially problematic as there is no official SPARC port and I'm not aware of anybody else working on one. ---8<--- ... that Node.js is an issue because we can not use it. Not because we don't WANT to use it. This is an important distinction that you seem to have missed. > So let me reframe this argument a bit: If you refuse to allow us > frontend developers to use node, npm, and bower, then I expect you to > reciprocate and no longer use the python executable or pip to write your > code, and you can only debug using wsgi. Since those fill equivalent > roles in our various languages-du-jour, it seems like a perfectly fair > exchange. Deal? I'm sorry, what? Python is fully supported on Solaris (both x86 and SPARC). This discussion has nothing whatsoever to do with the 'language-du-jour'. I continued this thread because we came across the and the blueprint suggesting moving to using Bower rather than XStatic and I'm attempting to voice the concerns we have for moving to Node. It may be that nothing can be done in the short term (for Kilo) with the long term action being to get Node ported to SPARC. -Drew __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 1/14/15 6:25 AM, Anton Zemlyanov wrote: > Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. > > Solaris 32-bit Binary: > http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz > Solaris 64-bit Binary: > http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz > > I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. -Drew __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 1/13/15 7:59 AM, Jeremy Stanley wrote: > On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote: > [...] >> But, as far as I understand, node.js will become a development >> requirement (and most probably a requirement for testing), but not for >> deployment. > [...] > > A requirement for testing _is_ a requirement for deployment. If it's > not tested, it's broken. If you're deploying software on a platform > where it can't be tested then you're simply _hoping_ that it's not > broken, and that is almost certainly a false hope. > Exactly. We have to test this code base extensively before we package it up for Solaris. Under no circumstances do we just blindly repackage the releases and push them out to customers. Node.js is a total incompatibility for Solaris. If upstream moves to using Bower we'll be forced to look for alternatives at managing the JavaScript libraries. Why were the libraries ripped from the Horizon codebase in the first place? It seems to me they belong with the code using it. -Drew __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 12/18/14 6:58 AM, Radomir Dopieralski wrote: > Hello, > > revisiting the package management for the Horizon's static files again, > I would like to propose a particular solution. Hopefully it will allow > us to both simplify the whole setup, and use the popular tools for the > job, without losing too much of benefits of our current process. > > The changes we would need to make are as follows: > > * get rid of XStatic entirely; > * add to the repository a configuration file for Bower, with all the > required bower packages listed and their versions specified; I know I'm very very late to this thread but can I ask why Bower? Bower has a hard requirement on Node.js which was removed as a dependency in Havana. Why are we reintroducing this requirement? For Solaris, a requirement on Node.js is especially problematic as there is no official SPARC port and I'm not aware of anybody else working on one. I agree that XStatic isn't really the best solution here but are there any other solutions that don't involve Node.js? Thanks. -Drew __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?
On 11/25/14, 12:56 PM, Jay S. Bryant wrote: > Monty, > > I agree that upgrade is not a significant concern right now if the > existing driver is not working. > > Drew, > > I am having trouble following where you guys are currently at with this > work. I would like to help get you guys up and going during Kilo. > > I am concerned that maybe there is confusion about the > blueprints/patches that we are all talking about here. I see this > Blueprint that was accepted for Juno and appears to have an associated > patch merged: [1] I also see this Blueprint that doesn't appear to be > started yet: [2] So, can you help me understand what it is you are > hoping to get in for Kilo? OK, so we have two drivers here at Oracle in Solaris. 1: A driver for the ZFS storage appliance (zfssa). That driver was integrated into the Icehouse branch and still there in Juno. That team, separate from mine, is working along side of us with the CI requirements to keep the driver in Kilo 2: The second driver is one for generic ZFS on Solaris. We have three different sub-drivers in one: - An iSCSI driver (COMSTAR on top of ZFS) - A FC driver (on top of ZFS) - A simple "local" ZFS driver useful for single-system / devstack / demo rigs. The local driver simply creates ZVOLs for Zones to use on the local system. It's not designed with any kind of migration abilities unlike iSCSI or FC. > > I know that you have been concerned about CI. For new drivers we are > allowing some grace period to get things working. Once we get the > confusion over blueprints worked out and have some code to start > reviewing we can continue to discuss that issue. My plan is to discuss this plan with my team next week after the holiday. Once we get something in place on our side, we'll try to get a blueprint submitted ASAP for review. Sound good? -Drew > > Look forward to hearing back from you! > Jay > > > [1] > https://blueprints.launchpad.net/cinder/+spec/oracle-zfssa-cinder-driver > [2] > https://blueprints.launchpad.net/cinder/+spec/oracle-zfssa-nfs-cinder-driver > > > On 11/24/2014 11:53 AM, Monty Taylor wrote: >> On 11/24/2014 10:14 AM, Drew Fisher wrote: >>> >>> On 11/17/14 10:27 PM, Duncan Thomas wrote: >>>> Is the new driver drop-in compatible with the old one? IF not, can >>>> existing systems be upgraded to the new driver via some manual >>>> steps, or >>>> is it basically a completely new driver with similar functionality? >> Possibly none of my business- but if the current driver is actually just >> flat broken, then upgrading from it to the new solaris ZFS driver seems >> unlikely to be possibly, simply because the from case is broken. >> >>> The driver in san/solaris.py focuses entirely on iSCSI. I don't think >>> existing systems can be upgraded manually but I've never really tried. >>> We started with a clean slate for Solaris 11 and Cinder and added local >>> ZFS support for single-system and demo rigs along with a fibre channel >>> and iSCSI drivers. >>> >>> The driver is publically viewable here: >>> >>> https://java.net/projects/solaris-userland/sources/gate/content/components/openstack/cinder/files/solaris/zfs.py >>> >>> >>> Please note that this driver is based on Havana. We know it's old and >>> we're working to get it updated to Juno right now. I can try to work >>> with my team to get a blueprint filed and start working on getting it >>> integrated into trunk. >>> >>> -Drew >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?
On 11/17/14 10:27 PM, Duncan Thomas wrote: > Is the new driver drop-in compatible with the old one? IF not, can > existing systems be upgraded to the new driver via some manual steps, or > is it basically a completely new driver with similar functionality? The driver in san/solaris.py focuses entirely on iSCSI. I don't think existing systems can be upgraded manually but I've never really tried. We started with a clean slate for Solaris 11 and Cinder and added local ZFS support for single-system and demo rigs along with a fibre channel and iSCSI drivers. The driver is publically viewable here: https://java.net/projects/solaris-userland/sources/gate/content/components/openstack/cinder/files/solaris/zfs.py Please note that this driver is based on Havana. We know it's old and we're working to get it updated to Juno right now. I can try to work with my team to get a blueprint filed and start working on getting it integrated into trunk. -Drew ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?
We (here at Oracle) have a replacement for this driver which includes local ZFS, iSCSI and FC drivers all with ZFS as the underlying driver. We're in the process of getting CI set up so we can contribute the driver upstream along with our ZFSSA driver (which is already in the tree). If anybody has more questions about this, please let me know. The driver is in the open for folks to look at and if anybody wants us to start upstream integration for it, we'll be happy to do so. -Drew On 11/16/14, 8:45 PM, Mike Perez wrote: > The Open Solaris ZFS driver [1] is currently missing a lot of the minimum > features [2] that the Cinder team requires with all drivers. As a result, it's > really broken. > > I wanted to gauge who is using it, and if anyone was interested in fixing the > driver. If there is not any activity with this driver, I would like to propose > it to be deprecated for removal. > > [1] - > https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/solaris.py > [2] - > http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FreeBSD host support
On 10/27/14, 5:57 PM, Stefano Maffulli wrote: > On 10/27/2014 08:51 AM, Drew Fisher wrote: >> If devstack itself (not CI, but devstack) is a hard requirement for >> integration we need to probably start up a different thread on what the >> best way for other OSes like FreeBSD and Solaris to work around this >> issue. What should we be looking at? A compatible devstack clone that >> configures Solaris as a single-host development OpenStack rig? > > I doubt devstack itself is a hard requirement for CI since > Windows/Hyper-V testing is done without devstack. I think what mordred > meant was that you need to provide a way like devstack for Infra team to > test things. Sounds good. > > To put the thread back in topic, I would assume that the *BSD folks and > Oracle/Solaris would have good amount of overlap in this area. > > How about you team up to either provide good patches to devstack to > support the non-linux options (if this is suitable) or develop a new > tool similar in scope to devstack for all BSD-family? Maybe that would > be good for OS X, too :) > > Chat in Paris? I would love to. Please ping me when you get a moment. -Drew ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FreeBSD host support
On 10/27/14 9:35 AM, Monty Taylor wrote: >> >> I have no problem with supporting FreeBSD as a hypervisor operating system, >> especially if there is a solid team on the FreeBSD side that will commit to >> maintaining the changes required and adding the necessary CI (especially >> ensuring that when it breaks it gets fixed). > > I believe that the CI related things that would be needed would be: > > - solid devstack support I do not want to hijack this thread with Solaris specific questions, but this point is a major sticking point for us too. To my knowledge, modifying devstack for anything not RHEL/Ubuntu is out of the question (they're not interested in supporting other OSes). We desperately WANT to push our Solaris driver upstream and we're in the process of getting our CI infrastructure in place to do so, but devstack has been out of the question so far. If devstack itself (not CI, but devstack) is a hard requirement for integration we need to probably start up a different thread on what the best way for other OSes like FreeBSD and Solaris to work around this issue. What should we be looking at? A compatible devstack clone that configures Solaris as a single-host development OpenStack rig? -Drew ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] Picking a Name for the Tempest Library
What about 'teapot' (as in the idiom 'tempest in a teapot'[1]) -Drew [1] http://en.wikipedia.org/wiki/Tempest_in_a_teapot On 08/15/2014 01:14 PM, Matthew Treinish wrote: Hi Everyone, So as part of splitting out common functionality from tempest into a library [1] we need to create a new repository. Which means we have the fun task of coming up with something to name it. I'm personally thought we should call it: - mesocyclone Which has the advantage of being a cloud/weather thing, and the name sort of fits because it's a precursor to a tornado. Also, it's an available namespace on both launchpad and pypi. But there has been expressed concern that both it is a bit on the long side (which might have 80 char line length implications) and it's unclear from the name what it does. During the last QA meeting some alternatives were also brought up: - tempest-lib / lib-tempest - tsepmet - blackstorm - calm - tempit - integration-test-lib (although I'm not entirely sure I remember which ones were serious suggestions or just jokes) So as a first step I figured that I'd bring it up on the ML to see if anyone had any other suggestions. (or maybe get a consensus around one choice) I'll take the list, check if the namespaces are available, and make a survey so that everyone can vote and hopefully we'll have a clear choice for a name from that. -Matt Treinish [1] http://specs.openstack.org/openstack/qa-specs/specs/tempest-library.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] extending nova boot
I hate to be that guy but I have to bump this thread to try to get answer. Can anybody help me out? On 10/28/13 4:06 PM, Drew Fisher wrote: > Chris and Phil, > > Thanks for the clue on using scheduler_hints as a template. I've > implemented a V2 API version of my extension to get started (for > stable/grizzly) and I can see all of the data moving from > nova/api/openstack/compute/servers.py to nova/compute/api.py.create() -> > _create_instance() -> _validate_and_provision_instance() -> > scheduler_rpcapi.run_instance(). > > From here, I can get into compute/manager.py and in _run_instance(), I > can see that my new data is sitting in a gross triple dictionary: > > filter_properties["request_spec"]["instance_properties"]["newflag"] > > Obviously this is gross and has to be wrong but I'm not seeing what I > might have missed walking back through my extension (it's basically a > C&P clone of contrib/scheduler_hints.py) and my changes to servers.py > (stepping through pdb shows all the right things in all the right places). > > I would love to be able to post some code to show my issue, but I can't > quite do it just yet (see domain name in email address). > > Any ideas for how to get my new flags into the top level instance object > as handled by manager._run_instance()? > > Thanks for the help so far! I just need one more little piece and I'll > have it. > > -Drew > > > On 10/26/13 4:53 AM, Christopher Yeoh wrote: >> Hi Drew, >> >> Unfortunately there's not much up to date documentation on how to write >> an api extension (its on the TODO list), but as Phil mentioned looking >> at existing extensions like scheduler_hints is a good place to start. >> >> You'll need to decide whether you want to write a V2 and V3 API version >> of your extension or only V3. V3 is currently marked experimental but >> should (hopefully!) become the default API with the release of Icehouse. >> So if you submit a V2 extension you will have to also submit a V3 version. >> >> As Phil mentioned, for V2 you'll need to add both a new extension file, >> plus modify nova/api/openstack/compute/servers.py to look for an pass >> the new parameter to compute_api.create. For V2 all parameters have to >> be explicitly handled in servers.py >> >> For V3 (see nova/api/openstack/compute/plugins/v3/) you will only need >> to add a new extension with no modifications to servers.py. >> access_ips.py is probably a good example for V3 to see how parameters >> can be passed to compute_api.create by an extension. In access_ips, see >> the create function in AccessIPsController and server_create in >> AccessIPs. Note that you will need to add some entries in setup.cfg for >> the V3 plugin to be detected. >> >> Depending on how your extension works you may also need to add entries >> to nova/etc/policy.json as well. >> >> Regards, >> >> Chris >> >> >> >> >> On Sat, Oct 26, 2013 at 7:04 AM, Day, Phil > <mailto:philip@hp.com>> wrote: >> >> Hi Drew, >> >> Generally you need to create a new api extention and make some >> changes in the main servers.py >> >> The scheduler-hints API extension does this kind of thing, so if you >> look at: api/openstack/compute/contrib/scheduler_hints.py for how >> the extension is defined, and look in >> api/poenstack/compute/servers.py code for "scheduler_hints" (e.g. >> _extract_scheduler_hints() ) then that should point you in the >> right direction. >> >> Hope that helps, >> Phil >> >> > -Original Message- >> > From: Drew Fisher [mailto:drew.fis...@oracle.com >> <mailto:drew.fis...@oracle.com>] >> > Sent: 25 October 2013 16:34 >> > To: openstack-dev@lists.openstack.org >> <mailto:openstack-dev@lists.openstack.org> >> > Subject: [openstack-dev] extending nova boot >> > >> > Good morning! >> > >> > I am looking at extending nova boot with a few new flags. I've >> found enough >> > examples online that I have a working extension to novaclient (I >> can see the >> > new flags in `nova help boot` and if I run with the --debug flag I >> can see the >> > curl requests to the API have the data. >> > >> > What I can't seem to figure out is how nova-api processes these extra >> > arguments.
Re: [openstack-dev] extending nova boot
Chris and Phil, Thanks for the clue on using scheduler_hints as a template. I've implemented a V2 API version of my extension to get started (for stable/grizzly) and I can see all of the data moving from nova/api/openstack/compute/servers.py to nova/compute/api.py.create() -> _create_instance() -> _validate_and_provision_instance() -> scheduler_rpcapi.run_instance(). >From here, I can get into compute/manager.py and in _run_instance(), I can see that my new data is sitting in a gross triple dictionary: filter_properties["request_spec"]["instance_properties"]["newflag"] Obviously this is gross and has to be wrong but I'm not seeing what I might have missed walking back through my extension (it's basically a C&P clone of contrib/scheduler_hints.py) and my changes to servers.py (stepping through pdb shows all the right things in all the right places). I would love to be able to post some code to show my issue, but I can't quite do it just yet (see domain name in email address). Any ideas for how to get my new flags into the top level instance object as handled by manager._run_instance()? Thanks for the help so far! I just need one more little piece and I'll have it. -Drew On 10/26/13 4:53 AM, Christopher Yeoh wrote: > Hi Drew, > > Unfortunately there's not much up to date documentation on how to write > an api extension (its on the TODO list), but as Phil mentioned looking > at existing extensions like scheduler_hints is a good place to start. > > You'll need to decide whether you want to write a V2 and V3 API version > of your extension or only V3. V3 is currently marked experimental but > should (hopefully!) become the default API with the release of Icehouse. > So if you submit a V2 extension you will have to also submit a V3 version. > > As Phil mentioned, for V2 you'll need to add both a new extension file, > plus modify nova/api/openstack/compute/servers.py to look for an pass > the new parameter to compute_api.create. For V2 all parameters have to > be explicitly handled in servers.py > > For V3 (see nova/api/openstack/compute/plugins/v3/) you will only need > to add a new extension with no modifications to servers.py. > access_ips.py is probably a good example for V3 to see how parameters > can be passed to compute_api.create by an extension. In access_ips, see > the create function in AccessIPsController and server_create in > AccessIPs. Note that you will need to add some entries in setup.cfg for > the V3 plugin to be detected. > > Depending on how your extension works you may also need to add entries > to nova/etc/policy.json as well. > > Regards, > > Chris > > > > > On Sat, Oct 26, 2013 at 7:04 AM, Day, Phil <mailto:philip@hp.com>> wrote: > > Hi Drew, > > Generally you need to create a new api extention and make some > changes in the main servers.py > > The scheduler-hints API extension does this kind of thing, so if you > look at: api/openstack/compute/contrib/scheduler_hints.py for how > the extension is defined, and look in > api/poenstack/compute/servers.py code for "scheduler_hints" (e.g. > _extract_scheduler_hints() ) then that should point you in the > right direction. > > Hope that helps, > Phil > > > -Original Message- > > From: Drew Fisher [mailto:drew.fis...@oracle.com > <mailto:drew.fis...@oracle.com>] > > Sent: 25 October 2013 16:34 > > To: openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org> > > Subject: [openstack-dev] extending nova boot > > > > Good morning! > > > > I am looking at extending nova boot with a few new flags. I've > found enough > > examples online that I have a working extension to novaclient (I > can see the > > new flags in `nova help boot` and if I run with the --debug flag I > can see the > > curl requests to the API have the data. > > > > What I can't seem to figure out is how nova-api processes these extra > > arguments. With stable/grizzly bits, in > > nova/api/openstack/compute/servers.py, I can see where that data is > > processed (in Controller.create()) but it doesn't appear to me > that any > > leftover flags are handled. > > > > What do I need to do to get these new flags to nova boot from > novaclient > > into nova-api and ultimately my compute driver? > > > > Thanks for any help! > > > > -Drew Fisher > > > > __
[openstack-dev] extending nova boot
Good morning! I am looking at extending nova boot with a few new flags. I've found enough examples online that I have a working extension to novaclient (I can see the new flags in `nova help boot` and if I run with the --debug flag I can see the curl requests to the API have the data. What I can't seem to figure out is how nova-api processes these extra arguments. With stable/grizzly bits, in nova/api/openstack/compute/servers.py, I can see where that data is processed (in Controller.create()) but it doesn't appear to me that any leftover flags are handled. What do I need to do to get these new flags to nova boot from novaclient into nova-api and ultimately my compute driver? Thanks for any help! -Drew Fisher ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
