Re: [openstack-dev] [Ironic] [TripleO] Aborting in(tro)spection process in discoverd
Hi, Thank you for putting it up Dmitry. As I wrote into the blueprint, if there are requests to implement API aborting introspection from operators, we should introduce this feature as API, I think. But if we just want to use this feature as debug, we had better not to introduce it as API. And, instead of introducing as API, I suppose implement only client library and call it from shell script or something like tool. Best Regards, Yuiko Takada 2015-04-21 20:42 GMT+09:00 Dmitry Tantsur dtant...@redhat.com: Hi folks. Recently I got several requests to implement API aborting introspection in discoverd. This is useful mostly when debugging, when you know that introspection has failed, and you want to stop it right now. I've put a blueprint https://blueprints.launchpad.net/ironic-discoverd/+spec/abort-introspection to track it. Such API would cause discoverd to set error state for the node immediately and issue a power off request for it. The technical side is not a big deal. What I'm worried about is whether we want to introduce such a feature at all. Some Ironic processes (deploy, in-band cleaning) are async as well, they also may hang, and IIUC we don't have means of aborting them. Does debugging justify introducing new API? This looks somewhat similar to our discussion about breaking locks in Ironic: it might be useful, but it's an API which we'll support and which can be easily misused. But with introspection the only case where lack of this feature can't be easily worked around is when people want to recreate a node. I've been arguing for some time that recreating a node is not a good way to solve problems. In other cases one can just power off the node via Ironic API and restart the introspection again afterwards. What do you think? Cheers, Dmitry __ 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 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] [Ironic] How to deal with microversions in 3rdparty tools
Hi, In Tempest, there is similar discussion. Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd like to propose consistent test way for microversions of Nova and Ironic. My suggestion is the test target microversions are: * the lowest microversion * the biggest microversion, but don't use the keyword latest on a header and these microversions tests are operated on different gate jobs. The lowest microversion is already tested on check-tempest-dsvm-full or something, so this proposes just to add the biggest microversion job like check-tempest-dsvm-full-big-microversion. Same as Tempest, I propose to use (in other word, test) both; * The lowest microversion * The biggest microversion without the keyword latest How do you think? Best Regards, Yuiko Takada 2015-04-07 22:02 GMT+09:00 Dmitry Tantsur dtant...@redhat.com: Hi again, hope you're not tired of this topic :D I'm seeking for advice on what to do with microversions in discoverd. Basically I have the following options: 1. Do nothing. Get whatever behavior I can get from installed Ironic and Ironic client. Though unlikely, may get broken by future changes. 2. Demand version = 1.6. Looks like it keeps compatibility with old clients and servers, not sure what downsides are here. What are we going to recommend now as upstream? Dmitry __ 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 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] [Ironic] ironic-discoverd release plans
Thank you, Dmitry. I agree! Best Regards, Yuiko Takada 2015-03-20 23:32 GMT+09:00 Imre Farkas ifar...@redhat.com: Hi Dmitry, Sounds good to me! ;-) Imre On 03/20/2015 01:59 PM, Dmitry Tantsur wrote: This is an informational email about upcoming ironic-discoverd-1.1.0 [1]. If you're not interested in discoverd, you may safely skip it. Hi all! Do you know what time is coming? Release time! I'm hoping to align this ironic-discoverd release with the OpenStack one. Here's proposed plan, which will be in effect, unless someone disagrees: Apr 9: feature freeze. The goal is to leave me some time to test it with Ironic RC and in-progress devstack integration [2]. Between this point and the release day, git master can be considered a release candidate :) Apr 30: release and celebration. stable/1.1 is branched and master is opened for features. For better scoping I've untargeted everything from 1.1.0 milestone [1], except for thing I see as particularly important. We might add more if we have time before FF. Please let me know what you think. Cheers, Dmitry [1] https://launchpad.net/ironic-discoverd/+milestone/1.1.0 [2] https://etherpad.openstack.org/p/DiscoverdDevStack __ 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 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 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
