<div dir="ltr">Hi Drew,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 31, 2013 at 2:10 AM, Drew Fisher <span dir="ltr"><<a href="mailto:drew.fisher@oracle.com" target="_blank">drew.fisher@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I hate to be that guy but I have to bump this thread to try to get answer.<br>
<br>
Can anybody help me out?<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Unfortunately its quite hard to work out what is going on without seeing your code.<br><br></div><div>Chris<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
On 10/28/13 4:06 PM, Drew Fisher wrote:<br>
> Chris and Phil,<br>
><br>
> Thanks for the clue on using scheduler_hints as a template. I've<br>
> implemented a V2 API version of my extension to get started (for<br>
> stable/grizzly) and I can see all of the data moving from<br>
> nova/api/openstack/compute/servers.py to nova/compute/api.py.create() -><br>
> _create_instance() -> _validate_and_provision_instance() -><br>
> scheduler_rpcapi.run_instance().<br>
><br>
> From here, I can get into compute/manager.py and in _run_instance(), I<br>
> can see that my new data is sitting in a gross triple dictionary:<br>
><br>
> filter_properties["request_spec"]["instance_properties"]["newflag"]<br>
><br>
> Obviously this is gross and has to be wrong but I'm not seeing what I<br>
> might have missed walking back through my extension (it's basically a<br>
> C&P clone of contrib/scheduler_hints.py) and my changes to servers.py<br>
> (stepping through pdb shows all the right things in all the right places).<br>
><br>
> I would love to be able to post some code to show my issue, but I can't<br>
> quite do it just yet (see domain name in email address).<br>
><br>
> Any ideas for how to get my new flags into the top level instance object<br>
> as handled by manager._run_instance()?<br>
><br>
> Thanks for the help so far! I just need one more little piece and I'll<br>
> have it.<br>
><br>
> -Drew<br>
><br>
><br>
> On 10/26/13 4:53 AM, Christopher Yeoh wrote:<br>
>> Hi Drew,<br>
>><br>
>> Unfortunately there's not much up to date documentation on how to write<br>
>> an api extension (its on the TODO list), but as Phil mentioned looking<br>
>> at existing extensions like scheduler_hints is a good place to start.<br>
>><br>
>> You'll need to decide whether you want to write a V2 and V3 API version<br>
>> of your extension or only V3. V3 is currently marked experimental but<br>
>> should (hopefully!) become the default API with the release of Icehouse.<br>
>> So if you submit a V2 extension you will have to also submit a V3 version.<br>
>><br>
>> As Phil mentioned, for V2 you'll need to add both a new extension file,<br>
>> plus modify nova/api/openstack/compute/servers.py to look for an pass<br>
>> the new parameter to compute_api.create. For V2 all parameters have to<br>
>> be explicitly handled in servers.py<br>
>><br>
>> For V3 (see nova/api/openstack/compute/plugins/v3/) you will only need<br>
>> to add a new extension with no modifications to servers.py.<br>
>> access_ips.py is probably a good example for V3 to see how parameters<br>
>> can be passed to compute_api.create by an extension. In access_ips, see<br>
>> the create function in AccessIPsController and server_create in<br>
>> AccessIPs. Note that you will need to add some entries in setup.cfg for<br>
>> the V3 plugin to be detected.<br>
>><br>
>> Depending on how your extension works you may also need to add entries<br>
>> to nova/etc/policy.json as well.<br>
>><br>
>> Regards,<br>
>><br>
>> Chris<br>
>><br>
>><br>
>><br>
>><br>
>> On Sat, Oct 26, 2013 at 7:04 AM, Day, Phil <<a href="mailto:philip.day@hp.com">philip.day@hp.com</a><br>
>> <mailto:<a href="mailto:philip.day@hp.com">philip.day@hp.com</a>>> wrote:<br>
>><br>
>> Hi Drew,<br>
>><br>
>> Generally you need to create a new api extention and make some<br>
>> changes in the main servers.py<br>
>><br>
>> The scheduler-hints API extension does this kind of thing, so if you<br>
>> look at: api/openstack/compute/contrib/scheduler_hints.py for how<br>
>> the extension is defined, and look in<br>
>> api/poenstack/compute/servers.py code for "scheduler_hints" (e.g.<br>
>> _extract_scheduler_hints() ) then that should point you in the<br>
>> right direction.<br>
>><br>
>> Hope that helps,<br>
>> Phil<br>
>><br>
>> > -----Original Message-----<br>
>> > From: Drew Fisher [mailto:<a href="mailto:drew.fisher@oracle.com">drew.fisher@oracle.com</a><br>
>> <mailto:<a href="mailto:drew.fisher@oracle.com">drew.fisher@oracle.com</a>>]<br>
>> > Sent: 25 October 2013 16:34<br>
>> > To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> > Subject: [openstack-dev] extending nova boot<br>
>> ><br>
>> > Good morning!<br>
>> ><br>
>> > I am looking at extending nova boot with a few new flags. I've<br>
>> found enough<br>
>> > examples online that I have a working extension to novaclient (I<br>
>> can see the<br>
>> > new flags in `nova help boot` and if I run with the --debug flag I<br>
>> can see the<br>
>> > curl requests to the API have the data.<br>
>> ><br>
>> > What I can't seem to figure out is how nova-api processes these extra<br>
>> > arguments. With stable/grizzly bits, in<br>
>> > nova/api/openstack/compute/servers.py, I can see where that data is<br>
>> > processed (in Controller.create()) but it doesn't appear to me<br>
>> that any<br>
>> > leftover flags are handled.<br>
>> ><br>
>> > What do I need to do to get these new flags to nova boot from<br>
>> novaclient<br>
>> > into nova-api and ultimately my compute driver?<br>
>> ><br>
>> > Thanks for any help!<br>
>> ><br>
>> > -Drew Fisher<br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>