Re: [openstack-dev] extending nova boot
Hi Drew, On Thu, Oct 31, 2013 at 2:10 AM, Drew Fisher wrote: > I hate to be that guy but I have to bump this thread to try to get answer. > > Can anybody help me out? > > Unfortunately its quite hard to work out what is going on without seeing your code. Chris > 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> > >> > Subj
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 > > > > __
Re: [openstack-dev] extending nova boot
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 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] > > Sent: 25 October 2013 16:34 > > To: 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 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] extending nova boot
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] > Sent: 25 October 2013 16:34 > To: 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 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] 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
