Re: [openstack-dev] [Ironic] When to bump the microversion?

On 06/04/2015 10:14 AM, Devananda van der Veen wrote: On Jun 4, 2015 8:57 AM, "Monty Taylor" > So, seriously - let's grow up and start telling people that they do not > get to pick and choose user-visible feature sets. If they have an unholy > obsession with a particular backend technology

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

I am interested but not sure how much time I have this release cycle. I can take on a more hands-off approach and help review to make sure that magnum-ui is align with future horizon directions.-"Steven Dake (stdake)" wrote: -To: "OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

+1 to single team -- dims On Thu, Jun 4, 2015 at 2:02 PM, Steven Dake (stdake) wrote: > My vote is +1 for a unified core team for all Magnum development which in > the future will include the magnum-ui repo, the python-magnumclient repo, > the magnum repo, and the python-k8sclient repo. > > Rega

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

I’m really keen to take on this effort, to echo what Steve said I think adding a dashboard component to Magnum is critical in adoption and delivering good usability to all. Thanks, Brad Jones On 4 Jun 2015, at 18:58, Steven Dake (stdake) mailto:std...@cisco.com>> wrote: Hey folks, I think i

[openstack-dev] [horizon] Prioritize tests over JSCS

Hi folks,I know a lot of people are tackling the JSCS stuff, and thats really great. But it would be extra nice to see JSCS stuff along with JP's guidelines in your patches. Furthermore, if the file you are working on doesn't have an accompanying spec file, please make sure that the tests for it ex

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Same here. I’m definitely interested in helping out but not sure how much time I can commit to. Will most definitely help out with reviews and other decision making process to help ensure magnum-ui is implemented and in the correct direction relating to Horizon. From: Thai Q Tran mailto:tqt...@

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

Ann, Thanks for bringing this up. It has been on the shelf for a while now. Carl On Thu, Jun 4, 2015 at 8:54 AM, Salvatore Orlando wrote: > One reason for not sending the heartbeat from a separate greenthread could > be that the agent is already doing it [1]. > The current proposed patch addre

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

I am happy to be involved in these additional projects. It helps as I get to understand OpenStack, Magnum and containers more in my available free time. I have plenty of HTML/BootStrap/JQuery skills and some Angular skills, all helpful for Horizon. Ronald Ronald Bradford Web Site: http://ronal

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

On 06/04/2015 11:58 AM, Steven Dake (stdake) wrote: > Hey folks, > > I think it is critical for self-service needs that we have a Horizon > dashboard to represent Magnum. I know the entire Magnum team has no > experience in UI development, but I have found atleast one volunteer Bradley > Jones

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

How big a work item is this? Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Thai Q Tran/Silicon Valley/IBM@IBMUS To: "OpenStack Development Mailing List \(not for usage questions\)" D

Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting

On 06/04/2015 01:16 PM, Sean Dague wrote: It gets overwritten by the central store. And you are wrong, that gives me what I want, because we can emit a WARNING in the logs if the patch is something crazy. The operators will see it, and be able to fix it later. I'm not trying to prevent people f

[openstack-dev] [nova] allow image/flavor to specify CPU model or CPU feature(s)

Hi, Alex Xu and I had similar specs proposed for Liberty, so we joined forces to try to come up with something that would meet both of our goals while still being as simple as possible. The spec is up for review at https://review.openstack.org/#/c/168982/ The basic goal is to allow end-user

Re: [openstack-dev] [infra][third-party] Common-CI Virtual Sprint

I'm in! -- Spencer Krum n...@spencerkrum.com On Thu, Jun 4, 2015, at 09:22 AM, Asselin, Ramy wrote: > Hi, > > It was nice to meet many of you at the Vancouver Infra Working Session. > Quite a bit of progress was made finding owners for some of the common-ci > refactoring work [1] and puppet

Re: [openstack-dev] [infra][third-party] Common-CI Virtual Sprint

Whenever is, I'll participate. Regards 2015-06-04 21:09 GMT+02:00 Spencer Krum : > I'm in! > > -- > Spencer Krum > n...@spencerkrum.com > > On Thu, Jun 4, 2015, at 09:22 AM, Asselin, Ramy wrote: > > Hi, > > > > It was nice to meet many of you at the Vancouver Infra Working Session. > > Quite

[openstack-dev] [kolla] Kolla Manfiesto Definition

Kolla devs, First off, the Kolla development team did a fantastic job of getting their various thoughts into the Kolla Manfesto etherpad. It was really something magical to watch and participate in and was a new experience for me :). I have detected a pattern between different missions that so

Re: [openstack-dev] [all]Big Tent Mode within respective projects

On 06/04/2015 07:46 AM, Boris Pavlovic wrote: Jay, At this time, Neutron is the only project that has done any splitting out of driver and advanced services repos. Other projects have discussed doing this, but, at least in Nova, that discussion was put on hold for the time being

[openstack-dev] [all][api] API working group proposed guideline merge process

hi all, The API working group has put together a more comprehensive process for merging guidelines. This process is currently under review[1], and we would like to invite all PTLs and CPLs to take a look and tell us if we are missing something. This review will most likely stay open until ou

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

I'm happy to provide reviews from the Horizon standpoint. David On Thu, Jun 4, 2015 at 12:55 PM, Jason Rist wrote: > On 06/04/2015 11:58 AM, Steven Dake (stdake) wrote: > > Hey folks, > > > > I think it is critical for self-service needs that we have a Horizon > dashboard to represent Magnum.

Re: [openstack-dev] [cinder] Rebranded Volume Drivers

On 06/03/2015 02:53 PM, Eric Harney wrote: On 06/03/2015 01:59 PM, John Griffith wrote: On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez wrote: There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting

Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources

Amrith, Thanks for spearheading that work. In the Octavia project we are interested in the shadow tenant to solve some of the scalability issues we have encountered with one service tenant: * There is probably a limit how many Vms a tenant can have * We have been running out of ipsec rules in our

Re: [openstack-dev] [puppet] Change abandonment policy

I vote #2, with a smaller N. We can always adjust this policy in the future if find we have to manually abandon too many old reviews. From: Colleen Murphy Reply-To: "puppet-openst...@puppetlabs.com" Date: Tuesday, June 2, 2015 at 12:39 PM To: "OpenStack

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

It’s difficult to put a quantifiable figure on how big a work item this is but I can try to give an overview of the steps required. The first step will be to extend the Horizon API to include CRUD operations that we need to perform with Magnum. Assuming that there are no issues here and API cha

Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources

With my op hat on, we're really interested in Service VM's working like normal VM's when it comes to nova (quota's, flavor access), cinder, etc. its greatly simplifies billing if you don't have to treat these types of advanced services any differently. We also let users launch on dedicated hardw

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

In previous conversations, my understanding was the UI implementation had to be very scheduler dependent to be very effective. Is my understanding accurate? If so, the complexity grows with the number supported. David On Thu, Jun 4, 2015 at 1:59 PM, Bradley Jones (bradjone) wrote: > It’s diffi

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Could we have a new group magnum-ui-core and include magnum-core as a subgroup, like the heat-coe-tempalte-core group. Thanks, Hongbin From: Steven Dake (stdake) [mailto:std...@cisco.com] Sent: June-04-15 1:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstac

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On Wed, Jun 03, 2015 at 04:30:17PM -0400, Sean Dague wrote: > The closer we can get logic about what a service should look like on > disk back into that service itself, the less work duplicated by any of > the installers, and the more common OpenStack envs would be. The fact > that every installer

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Hongbin, I hadn’t thought of that, even though it seems obvious ;) We can absolutely do that. I almost like this option better then #1 but I don’t want the ui folks to feel like second class citizens. This goes back to the trust the ui developers to not review things they know not about :)

Re: [openstack-dev] [cinder] Rebranded Volume Drivers

Sounds like the community would like CI's regardless, and I agree. Just because the driver code works for one backend solution, doesn't mean it's going to work with some other. Lets continue with code reviews with these patches only if they have a CI reporting, unless someone has a compelling rea

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

Problem! In writing a spec for this ( https://review.openstack.org/#/c/188564/ ), I remembered that groups are domain-specific entities, which complicates the problem of providing X-Group-Names via middleware. The problem is that we can't simply expose X-Group-Names to underlying services without

Re: [openstack-dev] [cinder] Rebranded Volume Drivers

Agreed, I'd also like to mention that rebranded arrays may differ slightly in functionality as well so the CIs would need to run against a physical rebranded device. These differences also justify the need for letting rebranded drivers in. -Alex On Thu, Jun 4, 2015 at 4:41 PM, Mike Perez wrote:

[openstack-dev] [all][api] 3 new guidelines entering freeze period

The API working group has three new guidelines that are entering the 1 week freeze period. We would like to ask all PTLs and CPLs, and other interested parties, to take a look at these reviews. We will use lazy consensus at the end of the freeze to merge them if there are no objections. Rememb

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Thanks for the details Brad! I would also be interested in helping out with the work. From: "Bradley Jones (bradjone)" mailto:bradj...@cisco.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, June 4, 2015 at

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Steve, Thanks for raising this. I am definitely looking forward to a UI effort for Magnum, and will be happy to decide based on community input about how best to organize this. I’d also like direct input from those contributors who plan to work on this to take those individual preferences into

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Jason, I will definitely weigh all feedback on this. I’m interested in guidance from anyone taking an interest in this subject. Thanks, Adrian > On Jun 4, 2015, at 1:55 PM, Jason Rist wrote: > > On 06/04/2015 11:58 AM, Steven Dake (stdake) wrote: >> Hey folks, >> >> I think it is critical f

[openstack-dev] [Fuel] Hard Code Freeze status update - Just 4th 2PM PDT

Hello everyone, The Keystone patch passed staging tests, we are now building the ISO with this patch and other merged fixes. Test results for this ISO will be available tonight/early morning tomorrow PDT. If they are good, this will be our RC. So, our plan to declare HCF tomorrow morning/after

[openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page. Meeting Minutes: http://eavesdrop.openstack.org/meetings/service_chaini

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I set the report_interval to 1 second on the agent and added a logging statement and I see a report every 1 second even when sync_routers is taki

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

On Thu, Jun 4, 2015 at 3:20 PM, Kevin Benton wrote: > After trying to reproduce this, I'm suspecting that the issue is actually on > the server side from failing to drain the agent report state queue in time. > > I set the report_interval to 1 second on the agent and added a logging > statement an

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

>From a quick look around there doesn’t seem to be a consensus on how to deal >with UI teams, some projects seem to use just the main projects core team >(group based policy ui), others use a mix of the project core team and the >Horizon core team (monasca-ui) and in the case of tuskar-ui they u

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Team, I have published a top level blueprint for a magnum-horizon-plugin: https://blueprints.launchpad.net/magnum/+spec/magnum-horizon-plugin My suggestion is that any contributor interested in contributing to this feature should subscribe to that blueprint, and record their intent to contribu

Re: [openstack-dev] [Ironic] When to bump the microversion?

On Jun 4, 2015 11:11 AM, "Chris Friesen" wrote: > > On 06/04/2015 10:14 AM, Devananda van der Veen wrote: >> >> >> On Jun 4, 2015 8:57 AM, "Monty Taylor" > >> > So, seriously - let's grow up and start telling people that they do not >> > get to pick and choose user-visible feature sets. If they

Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting

Hi Everyone! I've been reading through this thread and have had some conversations along the side and wanted to jump in to distill out what I think are the key points we are trying to address here. I'm going to outline about 4 items that seem to make sense to me regarding the evolution of policy.

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

Hi Clint, Thanks for your contribution to this thread. On 06/04/2015 10:35 PM, Clint Adams wrote: > On Wed, Jun 03, 2015 at 04:30:17PM -0400, Sean Dague wrote: >> The closer we can get logic about what a service should look like on >> disk back into that service itself, the less work duplicated b

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

I will get a spec out for review by end of day tomorrow. Thanks, Brad Jones On 4 Jun 2015, at 22:30, Adrian Otto mailto:adrian.o...@rackspace.com>> wrote: Team, I have published a top level blueprint for a magnum-horizon-plugin: https://blueprints.launchpad.net/magnum/+spec/magnum-horizon-plu

[openstack-dev] [Neutron] Missing "allowed address pairs"?

You have better chances of getting an answer if you asked the -dev list and add [Neutron] to the subject (done here). That said, can you tell us a bit more about your deployment? You can also hop on #openstack-neutron on Freenode to look for neutron developers who can help you more interactively.

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

In Juno I tried adding a user in Domain A to group in Domain B. That currently is not supported. Would be very handy though. We're getting a ways from the original part of the thread, so I may have lost some context, but I think the original question was, if barbarian can add group names to the

[openstack-dev] [openstack-operators][openstack][chef] Pre-release of knife-openstack is out (1.2.0.rc1)

Hey everyone! I have cut a new release of the knife-openstack[1] gem today. We have a couple new features[2] which has been asked for a while. If you would like to give it a shot and report back any issues you might find[3]. gem install knife-openstack --pre I’m hoping to give this a week or

[openstack-dev] Standard way to indicate a partial blueprint implementation?

Ever since we established[1] a format for including metadata about bugs in Git commit messages that included a 'Partial-Bug' tag, people have been looking for a way to do the equivalent for partial blueprint implementations. A non-exhaustive search of a small number of projects reveals at least

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

Hi, > After trying to reproduce this, I'm suspecting that the issue is actually > on the server side from failing to drain the agent report state queue in > time. I have seen before. I thought the senario at that time as follows. * a lot of create/update resource API issued * "rpc_conn_pool_size

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

I doubt it's a server side issue. Usually there are plenty of rpc workers to drain much higher amount of rpc messages going from agents. So the issue could be in 'fairness' on L3 agent side. But from my observations it was more an issue of DHCP agent than L3 agent due to difference in resource proc

Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

On 4 June 2015 at 14:17, Cathy Zhang wrote: > Thanks for joining the service chaining meeting today! Sorry for the > time confusion. We will correct the weekly meeting time to 1700UTC (10am > pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting > page. > > > Cathy, thanks for dr

Re: [openstack-dev] [nova] [glance] How to deal with aborted image read?

Perhaps someone needs to use (or forgot to use) contextlib.closing? https://docs.python.org/2/library/contextlib.html#contextlib.closing Or contextlib2 also may be useful: http://contextlib2.readthedocs.org/en/latest/#contextlib2.ExitStack -Josh Chris Friesen wrote: On 06/04/2015 03:01 AM, F

Re: [openstack-dev] [all] IRC meetings agenda is now driven from Gerrit !

As we could generate data dynamically, it is possible to develop a web UI for it which shows real-time and readable scheduler table, provides download link of custom meetings group, etc. On Sat, May 30, 2015 at 2:51 PM yatin kumbhare wrote: > Thank you, Thierry & Tony > > --Daniel > So could we

Re: [openstack-dev] [all] IRC meetings agenda is now driven from Gerrit !

On Fri, Jun 05, 2015 at 01:18:57AM +, Gareth wrote: > As we could generate data dynamically, it is possible to develop a web UI > for it which shows real-time and readable scheduler table, provides > download link of custom meetings group, etc. Sure I'm working on the second part (albeit slow

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Same here, I’m interested in helping out with reviews from Horizon standpoint. Regards Zhenguo Niu From: David Lyle [mailto:dkly...@gmail.com] Sent: Friday, June 05, 2015 3:42 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][horizon] Making

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

I have filed a bp for this https://blueprints.launchpad.net/magnum/+spec/auto-generate-name Thanks 2015-06-04 14:14 GMT+08:00 Jay Lau : > Thanks Adrian, I see. Clear now. > > 2015-06-04 11:17 GMT+08:00 Adrian Otto : > >> Jay, >> >> On Jun 3, 2015, at 6:42 PM, Jay Lau wrote: >> >> Thanks Adria

[openstack-dev] What's Up, Doc? 5 June 2015

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, With our Kilo branch now cut, we're running headlong into the Liberty development cycle! And don't forget to have your say on what the M release should be called: https://wiki.openstack.org/wiki/Release_Naming/M_Proposals If you have con

Re: [openstack-dev] novnc console connection timetout

Thanks folks, Its fixed via https://bugs.launchpad.net/mos/+bug/1409661 :-0 2015-06-04 20:29 GMT+08:00 张扬 : > Hi Guys, > > I am a newbie on openstack, I deployed my first openstack env via Fuel > 6.0, but unfortunately I always could not access the vm's vnc console, it > hints the connection time

Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

Hi Cathy, Thanks for heading up this meeting. No worries about the timing, time zones are really difficult to handle ;) I do agree with Armando that finalization of the API is important and must be done at the earliest. As discussed over the last meeting I will start working on this and hope by t

Re: [openstack-dev] [Keystone] Domain and Project naming

On Wed, Jun 3, 2015 at 11:25 PM, Adam Young wrote: > With Hierarchical Multitenantcy, we have the issue that a project is > currentl restricted in its naming further than it should be. The domain > entity enforces that all project namess under the domain domain be unique, > but really what we sh

Re: [openstack-dev] [Keystone] Domain and Project naming

- Original Message - > From: "Adam Young" > To: "OpenStack Development Mailing List" > Sent: Thursday, 4 June, 2015 2:25:52 PM > Subject: [openstack-dev] [Keystone] Domain and Project naming > > With Hierarchical Multitenantcy, we have the issue that a project is > currentl restricted

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

Hello folks, Regarding option C, if group IDs are unique within a given cloud/context, and these are discoverable by clients that can then set the ACL on a secret in Barbican, then that seems like a viable option to me. As it is now, the user information provided to the ACL is the user ID infor

Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

On 4 June 2015 at 19:32, Vikram Choudhary wrote: > Hi Cathy, > > Thanks for heading up this meeting. No worries about the timing, time > zones are really difficult to handle ;) > > I do agree with Armando that finalization of the API is important and must > be done at the earliest. As discussed o

Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting

On 06/04/2015 05:49 PM, Morgan Fainberg wrote: Hi Everyone! I've been reading through this thread and have had some conversations along the side and wanted to jump in to distill out what I think are the key points we are trying to address here. I'm going to outline about 4 items that seem to

Re: [openstack-dev] [nova] [glance] How to deal with aborted image read?

On 06/04/2015 07:16 PM, Joshua Harlow wrote: Perhaps someone needs to use (or forgot to use) contextlib.closing? https://docs.python.org/2/library/contextlib.html#contextlib.closing Or contextlib2 also may be useful: http://contextlib2.readthedocs.org/en/latest/#contextlib2.ExitStack The com

Re: [openstack-dev] Standard way to indicate a partial blueprint implementation?

On 06/04/2015 05:23 PM, Zane Bitter wrote: Ever since we established[1] a format for including metadata about bugs in Git commit messages that included a 'Partial-Bug' tag, people have been looking for a way to do the equivalent for partial blueprint implementations. > I have personally been

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

Thanks Jay. I have approved the direction for this, and have marked it as under discussion. I also added it to our next team meeting agenda so we can consider any alternate viewpoints before approving the specification as worded. Adrian On Jun 4, 2015, at 9:12 PM, Jay Lau mailto:jay.lau@gm

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On Jun 4, 2015, at 11:03 AM, Devananda van der Veen mailto:devananda@gmail.com>> wrote: On Jun 4, 2015 12:00 AM, "Xu, Hejie" mailto:hejie...@intel.com>> wrote: > > Hi, guys, > > I’m working on adding Microversion into the API-WG’s guideline which make > sure we have consistent Microversio

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

> > >>I think this is perfectly fine, as long as it's reasonably large and >> the algorithm is sufficiently intelligent. The UUID algorithm is good at >> this, for instance, although it fails at readability. Docker's is not >> terribly great and could be limiting if you were looking to run seve

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

Thanks Eric, I see. Yes, this can make sure the user would not need to contact the server using bay-show/baymode-show to get UUID of bay/baymodel, but Magnum need to be updated to make the bay/baymodel uuid generate logic. 2015-06-05 13:42 GMT+08:00 Eric Windisch : > >>>I think this is perfec

Re: [openstack-dev] [Ironic] ENROLL state and changing node driver

On 06/04/2015 06:18 PM, Devananda van der Veen wrote: On Jun 4, 2015 5:53 AM, "Dmitry Tantsur" mailto:dtant...@redhat.com>> wrote: > > Hi! > > While working on the enroll spec [1], I got a thinking: within the new state machine, when should we allow to change a node driver? > > My initial

<    1   2