[openstack-dev] Python API of python-.+client
I'm interested to know what is the status of the Python API of the python-novaclient, and the Python APIs of other OpenStack clients. On the github page https://github.com/openstack/python-novaclient/ it is written: *There's also a complete Python API, but it has not yet been documented.* Having written some bash scripts to automate some tasks this week I thought I should really have done this in Python, but then when I see this comment this discourages me - but more importantly raises many questions. There are also few examples available on the web for these APIs - though I have used them in the past for some v. small scripts. I ask these questions about python-novaclient, but am also interested in how they apply to other OpenStack clients. * Are people actually using the Python API ? If so, is it as stable, or more or less stable than the command-line client ? If not why not - are you using other APIs, or just bash scripting around the command-line client ? * What are the plans, if any, to improve the situation ? Is it just a question of someone stepping up and writing documentation ? Is there a clear idea of what needs to be done ? Are there bugs open against the documentation for this API (Sorry not to spend the time to search right now ...) I'd certainly like to contribute to the documentation if this is considered worthwhile ... I'm just surprised that this API seems to be unused. Interested to hear your thoughts/experiences. Thanks, Mike. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Python API of python-.+client
Thanks a lot Jeremy and Brian, a lot of useful information there. I'll have a good look at all this to see where I can help. Regards, Mike. On 8 June 2014 17:07, Brian Curtin br...@python.org wrote: On Sun, Jun 8, 2014 at 3:35 AM, Michael Bright mjbrigh...@gmail.com wrote: I'm interested to know what is the status of the Python API of the python-novaclient, and the Python APIs of other OpenStack clients. On the github page it is written: There's also a complete Python API, but it has not yet been documented. Having written some bash scripts to automate some tasks this week I thought I should really have done this in Python, but then when I see this comment this discourages me - but more importantly raises many questions. There are also few examples available on the web for these APIs - though I have used them in the past for some v. small scripts. I ask these questions about python-novaclient, but am also interested in how they apply to other OpenStack clients. * Are people actually using the Python API ? If so, is it as stable, or more or less stable than the command-line client ? If not why not - are you using other APIs, or just bash scripting around the command-line client ? * What are the plans, if any, to improve the situation ? Is it just a question of someone stepping up and writing documentation ? Is there a clear idea of what needs to be done ? Are there bugs open against the documentation for this API (Sorry not to spend the time to search right now ...) There's currently a new effort going on right now to reimagine all of those separate per-service tools into one complete SDK (libraries, CLIs, docs, examples, etc in one place), but it's early in the process. https://github.com/stackforge/python-openstacksdk and https://wiki.openstack.org/wiki/PythonOpenStackSDK have some details, and we're actively meeting on Tuesdays at 1900, and hang out in the #openstack-sdks room. ___ 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] [Neutron] Building a new open source NFV system for Neutron
Hi Luke, Very pleased to see this initiative in the OpenStack/NFV space. A dumb question - how do you see this related to the ongoing [openstack-dev] [nova] [neutron] PCI pass-through network support discussion on this list? Do you see that work as one component within your proposed architecture for example or an alternative implementation? Regards, Mike. SDN/NFV Solution Architect On 10 January 2014 16:11, Luke Gorrie l...@snabb.co wrote: Howdy Stackers! We are developing a new open source Network Functions Virtualization driver for Neutron. I am writing to you now to ask for early advice that could help us to smoothly bring this work upstream into OpenStack Juno. The background is that we are open source developers working to satisfy the NFV requirements of large service provider networks including Deutsche Telekom's TeraStream project [1] [2]. We are developing a complete NFV stack for this purpose: from the DPDK-like traffic plane all the way up to the Neutron ML2 driver. We are developing against Havana, we attended the Icehouse summit and had a lot of great discussions in Hong Kong, and our ambition is to start bringing running code upstream into Juno. Our work is 100% open source and we want to work in the open with the wider OpenStack community. Currently we are in heads-down hacking mode on the core functionality, but it would be wonderful to connect with the upstream communities who we hope to be working with more in the future (that's you guys). More details on Github: https://github.com/SnabbCo/snabbswitch/tree/snabbnfv-readme/src/designs/nfv Thanks for reading! Cheers, -Luke [1] Ivan Pepelnjak on TeraStream: http://blog.ipspace.net/2013/11/deutsche-telekom-terastream-designed.html [2] Peter Löthberg's presentation on TeraStream at RIPE 67: https://ripe67.ripe.net/archives/video/3/ ___ 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] Propose project story wiki idea
+1 On 20 November 2013 06:33, Boris Pavlovic bpavlo...@mirantis.com wrote: Hi stackers, Currently what I see is growing amount of interesting projects, that at least I would like to track. But reading all mailing lists, and reviewing all patches in all interesting projects to get high level understanding of what is happing in project now, is quite hard or even impossible task (at least for me). Especially after 2 weeks vacation =) The idea of this proposal is that every OpenStack project should have story wiki page. It means to publish every week one short message that contains most interesting updates for the last week, and high level road map for future week. So reading this for 10-15 minutes you can see what changed in project, and get better understanding of high level road map of the project. E.g. we start doing this in Rally: https://wiki.openstack.org/wiki/Rally/Updates I think that the best way to organize this, is to have person (or few persons) that will track all changes in project and prepare such updates each week. Best regards, Boris Pavlovic -- Mirantis Inc. ___ 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] When is it okay for submitters to say 'I don't want to add tests' ?
+1 also. I spent less than half the time on my first fix (so far) understanding the problem, reproducing it, coding it and learning about the code review system. Much more than half the time was spent on reverse engineering existing tests to be able to add new ones (which had to use features not used by the existing tests) and asking for advice even on where to add the tests. It would have been more efficient for everyone had some test examples been proposed to me. On 12 November 2013 03:34, Ed Leafe e...@openstack.org wrote: On Nov 11, 2013, at 6:42 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: It also gives the submitter a specific example of a well-written test, which can be a faster way to learn than forcing them to get there via trial and error. +1. Implementing a policy that has as the end effect more knowledgeable contributors is a big win. -- Ed Leafe ___ 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] When is it okay for submitters to say 'I don't want to add tests' ?
To be clear, that was a +1 for Mark's suggestion: In cases like that, I'd be of a mind to go +2 Awesome! Thanks for catching this! It would be great to have a unit test for this, but it's clear the current code is broken so I'm fine with merging the fix without a test. You could say it's now the reviewers responsibility to merge a test, but if that requirement then turns off reviewers even reviewing such a patch, then that doesn't help either. On 12 November 2013 11:29, Michael Bright mjbrigh...@gmail.com wrote: +1 also. I spent less than half the time on my first fix (so far) understanding the problem, reproducing it, coding it and learning about the code review system. Much more than half the time was spent on reverse engineering existing tests to be able to add new ones (which had to use features not used by the existing tests) and asking for advice even on where to add the tests. It would have been more efficient for everyone had some test examples been proposed to me. On 12 November 2013 03:34, Ed Leafe e...@openstack.org wrote: On Nov 11, 2013, at 6:42 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: It also gives the submitter a specific example of a well-written test, which can be a faster way to learn than forcing them to get there via trial and error. +1. Implementing a policy that has as the end effect more knowledgeable contributors is a big win. -- Ed Leafe ___ 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] Request for review
Could someone review this please, it's a small patch but has taken a while ... https://review.openstack.org/#/c/51263/ Thanks, Mike. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] No Review button - how to add a comment
OK, so I needed to add a comment to a patch set I proposed https://review.openstack.org/#/c/51263 but I don't see the Review button, only a couple of Diff options. Is there a way I can add comments to the current patch set? Thanks in advance, Mike. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] No Review button - how to add a comment
omg ... tired ... Thanks Chris. On 9 November 2013 14:42, Christopher Yeoh cbky...@gmail.com wrote: Hi Michael, My guess would be that you're not logged in - look in the top right hand corner. The review button should appear once you have logged in. Regards, Chris — Sent from Mailbox https://www.dropbox.com/mailbox for iPhone On Sat, Nov 9, 2013 at 9:38 PM, Michael Bright mjbrigh...@gmail.comwrote: OK, so I needed to add a comment to a patch set I proposed https://review.openstack.org/#/c/51263 but I don't see the Review button, only a couple of Diff options. Is there a way I can add comments to the current patch set? Thanks in advance, Mike. ___ 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] How to add a comment to a change review?
Can someone enlighten me as to how I can add a comment to one of my own changes on review.openstack.org. I suppose it's mind numbingly obvious but here for examplehttps://review.openstack.org/#/c/51263/11I just cannot see how to add a comment. It says here: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures Leave a comment on the review referencing the bug causing the transient failure (not the bug you're attempting to fix with your patch): To re-run the check jobs (before a change has been approved), leave a comment with the form recheck bug . To re-run the gate jobs (after a change has been approved), leave a comment with the form reverify bug . It must be so obvious ... Thanks in advance, Mike. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to add a comment to a change review?
Thanks Solly! On 6 November 2013 17:42, Solly Ross sr...@redhat.com wrote: You just click the review button under the change list on Gerrit. It should then take you to a screen where you can see inline comments waiting to be added and enter an overall comment as well. The comment system in Gerrit really should be a bit more intuitive. Best Regards, Solly Ross - Original Message - From: Michael Bright mjbrigh...@gmail.com To: openstack-dev@lists.openstack.org Sent: Wednesday, November 6, 2013 11:34:27 AM Subject: [openstack-dev] How to add a comment to a change review? Can someone enlighten me as to how I can add a comment to one of my own changes on review.openstack.org . I suppose it's mind numbingly obvious but here for example I just cannot see how to add a comment. It says here: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures Leave a comment on the review referencing the bug causing the transient failure (not the bug you're attempting to fix with your patch): To re-run the check jobs (before a change has been approved), leave a comment with the form recheck bug . To re-run the gate jobs (after a change has been approved), leave a comment with the form reverify bug . It must be so obvious ... Thanks in advance, Mike. ___ 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] [Neutron] Jenkins randomly fails?
Hi Siming, Yes there are some intermittent test failures which may be due to infrastructure and/or bugs. Here's my suggestion from recent experiences as a Noob. The e-mail you got from Jenkins includes this line, with a link telling you what to do: Build failed. For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures In your case, at least for https://review.openstack.org/#/c/55370/ it seems that the build system recognized the failure as likely being due to a known bug #1239637. You should check the failing log file, which you can access via the link given in the e-mail or on the above 55370 change page: - check-tempest-devstack-vm-neutron-pghttp://logs.openstack.org/70/55370/1/check/check-tempest-devstack-vm-neutron-pg/6d4cc81 FAILURE in 18m 27s to verify that this is indeed the same bug which has caused your build to fail. If this is the case, you can click on the Review button (for your patch set) and set Code to 0, add a comment (Cover Message): Recheck bug #x that's Recheck bug #1239637 in your case (the bug number suggested by the Elastic recheck). Hopefully that will pass. I hope this helps, I'm learning too ... Regards, Mike. On 7 November 2013 08:09, Siming Yin sael...@gmail.com wrote: Hi all, Please have a look at these two changes: https://review.openstack.org/#/c/55370/ https://review.openstack.org/#/c/55221/ The only change is to remove 4 duplicate definitions. I'm sure this will not cause any new problems, but it seems like the tests are randomly failing in jenkins. Could anyone tell me how to handle this? Thanks, Siming ___ 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] When is it okay for submitters to say 'I don't want to add tests' ?
I like Steve's suggestion:
The approach the Heat team have sometimes taken in this situation is to
merge the patch, but raise a bug (targetted at the next milestone)
identifying the missing coverage.
I'm (almost!) a first time contributor and I've put a fix on the backburner
as I find the time to ramp up on the unit tests suite. The fix was
reviewed 2 weeks ago, requesting unit tests - very reasonable but I
needed help to even start (I got no response from requests on IRC, ML, or
e-mail to the bug reporter).
If it wasn't for the good Upstream University people mentoring me - heh,
they deserve a plug! - I'm sure I would have moved on.
Thankfully, a cunning commit message provoked the guidance I needed so I
just need a long weekend to get back to the tests - which I have now.
I'm not sure in which cases you would/wouldn't want to split the bug for
the implementation of tests but I'm sure it would help other first timers
and encourage new contributors.
Regards,
Mike
On 31 October 2013 19:51, Steven Hardy sha...@redhat.com wrote:
On Thu, Oct 31, 2013 at 01:30:32PM +, Mark McLoughlin wrote:
On Thu, 2013-10-31 at 15:37 +1300, Robert Collins wrote:
This is a bit of a social norms thread
I've been consistently asking for tests in reviews for a while now,
and I get the occasional push-back. I think this falls into a few
broad camps:
A - there is no test suite at all, adding one in unreasonable
B - this thing cannot be tested in this context (e.g. functional tests
are defined in a different tree)
C - this particular thing is very hard to test
D - testing this won't offer benefit
E - other things like this in the project don't have tests
F - submitter doesn't know how to write tests
G - submitter doesn't have time to write tests
Nice breakdown.
Now, of these, I think it's fine not add tests in cases A, B, C in
combination with D, and D.
I don't think E, F or G are sufficient reasons to merge something
without tests, when reviewers are asking for them. G in the special
case that the project really wants the patch landed - but then I'd
expect reviewers to not ask for tests or to volunteer that they might
be optional.
I totally agree with the sentiment but, especially when it's a newcomer
to the project, I try to put myself in the shoes of the patch submitter
and double-check whether what we're asking is reasonable.
For example, if someone shows up to Nova with their first OpenStack
contribution, it fixes something which is unquestionably a bug - think
typo like raise NotFund('foo') - and testing this code patch requires
more than adding a simple new scenario to existing tests ...
That, for me, is an example of -1, we need a test! untested code is
broken! is really shooting the messenger, not valuing the newcomers
contribution and risks turning that person off the project forever.
Reviewers being overly aggressive about this where the project doesn't
have full test coverage to begin with really makes us seem unwelcoming.
The approach the Heat team have sometimes taken in this situation is to
merge the patch, but raise a bug (targetted at the next milestone)
identifying the missing coverage.
This has a few benefits (provided the patch in question is sufficiently
simple that patches aren't deemed essential)
- The bug gets fixed quickly
- The coverage still gets added, and we keep track of the gaps identified
- Less chance of discouraging new submitters
- Provides some low hanging fruit bugs, which new contributors can pick
up
I'm not saying we do this routinely, but it's a possible middle ground to
consider between -1 fix all our tests and +2 shipit!
I think something that's important to recognise is that sometimes (often?)
writing tests is *hard*. I mean, look at the barriers to entry, you need
to have some idea about tox, nose, testr, mox, mock, testscenarios, etc etc
The learning curve is really steep, and thats before you start considering
project specific test abstractions/fixtures/mocking-patterns which can all
be complex and non-obvious.
So +1 on a bit of compassion when reviewing, particularly if the
contributor is a new or casual contributor to the project.
Steve
___
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] Fwd: Change in openstack/nova[master]: Moved quota headroom calculations into quota_reserve
OK Dan, On 20 October 2013 16:08, Dan Smith d...@danplanet.com wrote: I'm afraid I really need help now - in particular on how to add a suitable test case. I've been looking at /opt/stack/nova/nova/tests/compute/test_compute_api.py running test_create_quota_exceeded_messages under the debugger to understand how it works to be able to adapt it. I really think this discussion should be kept in the review, or taken to the mailing list. As I don't see how to keep it in the review, I'll copy to openstack-dev. * When I have a fix I will abandon the current change and submit a new comprehensive change. Please do _not_ do that. You should have one review per logical change, regardless of how many iterations it takes to get it into suitable shape. I don't see a way around this due to the unittest breakage which spans nova/oslo (bare in mind I'm struggling/learning with *everything* here) so I'm unsure how to resync my code in a safe and *reliable* way. OK, I think I see what I need to do to do to not abandon the current changehttps://review.openstack.org/#/c/51263/ (i.e. to merge with master whilst not breaking my DevStack) - I'll be back for help if I muck up! The test failure in the bug you quoted shouldn't be blocking you. You might need to ignore it in your own local runs for a bit. That said, the patch has supposedly been merged to master so you probably just need to rebase your patch on master. There was no test failure, the existing tests have nothing to detect whether the fix for Bug #1224453 “min_count ignored for instance create” : Bugs : OpenStack Compute (nova) https://bugs.launchpad.net/nova/+bug/1224453 is present or not. If some kind soul can guide me on adding unit tests - per my question below - then I'll add them, otherwise I'll just complete the fix for now and add the tests in a later change. I'm afraid I really need help now - in particular on how to add a suitable test case. I've been looking at /opt/stack/nova/nova/tests/compute/test_compute_api.py running test_create_quota_exceeded_messages under the debugger to understand how it works to be able to adapt it. I'm too inexperienced on this to know how to write a suitable unit test (am I even considering this in the correct file?). I don't have a good understanding of the current test code and I don't see how I can do quota setting in test_compute_api.py. Thanks, Mike. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: Change in openstack/nova[master]: Moved quota headroom calculations into quota_reserve
OK Dan, On 20 October 2013 16:08, Dan Smith d...@danplanet.com wrote: I'm afraid I really need help now - in particular on how to add a suitable test case. I've been looking at /opt/stack/nova/nova/tests/compute/test_compute_api.py running test_create_quota_exceeded_messages under the debugger to understand how it works to be able to adapt it. I really think this discussion should be kept in the review, or taken to the mailing list. As I don't see how to keep it in the review, I'll copy to openstack-dev. * When I have a fix I will abandon the current change and submit a new comprehensive change. Please do _not_ do that. You should have one review per logical change, regardless of how many iterations it takes to get it into suitable shape. I don't see a way around this due to the unittest breakage which spans nova/oslo (bare in mind I'm struggling/learning with *everything* here) so I'm unsure how to resync my code in a safe and *reliable* way. OK, I think I see what I need to do to do to not abandon the current changehttps://review.openstack.org/#/c/51263/ (i.e. to merge with master whilst not breaking my DevStack) - I'll be back for help if I muck up! The test failure in the bug you quoted shouldn't be blocking you. You might need to ignore it in your own local runs for a bit. That said, the patch has supposedly been merged to master so you probably just need to rebase your patch on master. There was no test failure, the existing tests have nothing to detect whether the fix for Bug #1224453 “min_count ignored for instance create” : Bugs : OpenStack Compute (nova) https://bugs.launchpad.net/nova/+bug/1224453 is present or not. If some kind soul can guide me on adding unit tests - per my question below - then I'll add them, otherwise I'll just complete the fix for now and add the tests in a later change. I'm afraid I really need help now - in particular on how to add a suitable test case. I've been looking at /opt/stack/nova/nova/tests/compute/test_compute_api.py running test_create_quota_exceeded_messages under the debugger to understand how it works to be able to adapt it. I'm too inexperienced on this to know how to write a suitable unit test (am I even considering this in the correct file?). I don't have a good understanding of the current test code and I don't see how I can do quota setting in test_compute_api.py. Thanks, Mike. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/nova[master]: Moved quota headroom calculations into quota_reserve
Dan, * If some kind soul can guide me on adding unit tests - per my question* * below - then I'll add them, otherwise I'll just complete the fix for now* * and add the tests in a later change.* The change really needs to come with tests. A fix is only good if we know it's a fix :) I pulled out the above lines. OK, I'll plead for help on #openstack-dev/#openstack-nova. Let me restate here though (where I can explain context) that I don't know where to implement such tests and I can only implement them if I find a related test which I understand sufficiently to modify. I looked at I've looked at the tests in nova/tests/compute/test_compute_api.py. In particular at test_create_quota_exceeded_messages which I half understand (literally). I don't know if this is the appropriate place to add tests. If it is I don't see how to modify quota (correctly) to create my test conditions. ... and if it isn't the correct place I of course don't know where is ... Thanks *anyone*, Mike. * As I don't see how to keep it in the review, I'll copy to openstack-dev.* Just keep making your comments in Gerrit. That way all the discussion related to a specific patch is preserved with proper linkage in case we ever need to go back to it. OK, I suppose you mean the comment made when I perform a 'git review'. Nothing is obvious for me I'm afraid ;-) * OK, I think I see what I need to do to do to not abandon the current* * change https://review.openstack.org/#/c/51263/ (i.e. to merge with* * master whilst not breaking my DevStack) - I'll be back for help if I* * muck up!* Probably just: $ git fetch origin $ git rebase origin/master is the safest thing to do. Thanks I'll note that (though my concern was more to do with DevStack's stopping/starting/pulling of code - but I got it done OK). * There was no test failure, the existing tests have nothing to detect* * whether the fix for * * Bug #1224453 “min_count ignored for instance create” : Bugs :* * OpenStack Compute (nova) https://bugs.launchpad.net/nova/+bug/1224453 * * is present or not.* You were referencing a bug in your original mail that alaski pointed you at, which I thought you said you were hitting locally: https://bugs.launchpad.net/nova/+bug/1239898 If not, then ignore. Yeah, it's OK now. Thanks! --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
