Re: [openstack-dev] [all] etcd3 as base service - update

2017-06-08 Thread Drew Fisher


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

2017-05-03 Thread Drew Fisher
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/

2015-01-16 Thread Drew Fisher
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/

2015-01-14 Thread Drew Fisher


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/

2015-01-14 Thread Drew Fisher


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/

2015-01-13 Thread Drew Fisher


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/

2015-01-12 Thread Drew Fisher


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?

2014-11-25 Thread Drew Fisher


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?

2014-11-24 Thread Drew Fisher


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?

2014-11-16 Thread Drew Fisher
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

2014-10-27 Thread Drew Fisher


On 10/27/14 9:35 AM, Monty Taylor wrote:

snip

 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] FreeBSD host support

2014-10-27 Thread Drew Fisher


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] [QA] Picking a Name for the Tempest Library

2014-08-15 Thread Drew Fisher

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

2013-10-30 Thread Drew Fisher
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
 CP 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 philip@hp.com
 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 mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman

Re: [openstack-dev] extending nova boot

2013-10-28 Thread Drew Fisher
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
CP 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 philip@hp.com
 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 mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto: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