17:00:05 #startmeeting Ironic 17:00:05 #chair devananda 17:00:06 Meeting started Mon Jul 27 17:00:05 2015 UTC and is due to finish in 60 minutes. The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:07 Welcome everyone to the Ironic meeting. 17:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:10 The meeting name has been set to 'ironic' 17:00:11 Current chairs: NobodyCam devananda 17:00:20 Of course the agenda can be found at: 17:00:20 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 17:00:23 \o 17:00:27 hi 17:00:29 g'morning / afternoon / evening, everyone :) 17:00:33 #topic Greetings, roll-call and announcements 17:00:33 Roll-call: Who's here for the Ironic Meeting? 17:00:33 mornign folks 17:00:41 good morning everyone 17:00:48 Morning 17:00:52 o/ 17:01:08 moning 17:01:10 great to see everyone here 17:01:10 I just added an open discussion thing btw, so whoever is leading pls refresh agenda :) 17:01:14 #topic announcements: 17:01:15 Ironic Mid-cycle is August 12th thru 15th in Seattle 17:01:32 we currently have 23 sign-ups for the midcycle 17:01:45 FYI: I believe the address on the eventbright ticket is incorrect: 701 Pike St vs 701 East Pike street 17:02:01 if you haven't already, please jot your name down on the etherpad (https://etherpad.openstack.org/p/ironic-liberty-midcycle) and "buy" a ticket (link is at the top) 17:02:12 NobodyCam: eek! 17:02:25 * devananda checks 17:02:56 devananda: I'll be walking 10 extra blocks thanks to that :P 17:03:17 https://www.google.com/maps/dir/701+Pike+St,+Seattle,+WA+98101/Edge+of+the+Circle+Books,+701+E+Pike+St,+Seattle,+WA+98122,+United+States/@47.6125878,-122.3319583,16z/data=!3m1!4b1!4m13!4m12!1m5!1m1!1s0x54906ab5024ab26f:0xd7c85864845c80c1!2m2!1d-122.3327557!2d47.6114473!1m5!1m1!1s0x54906acb9d4dd5d7:0x22368ac5213de5ea!2m2!1d-122.3232484!2d47.61395 17:03:23 form to give input on food-y related things for mid-cycle is: http://goo.gl/forms/MTCOHedcYi 17:03:32 I only have 15 responses so far 17:03:33 NobodyCam: you are correct ... 17:04:06 #info Address for the midcycle is WA State Convention Center, 701 Pike St. ** Not East Pike ** 17:04:18 any have the midcycle etherpad link handy?? 17:04:25 s/any/anyone/ 17:04:37 #link https://etherpad.openstack.org/p/ironic-liberty-midcycle 17:04:38 #link https://etherpad.openstack.org/p/ironic-liberty-midcycle 17:04:41 :| 17:04:47 :_ ty both 17:05:17 any other announcements 17:05:33 so I just realized all but one item on the "what do folks want to hack on" list are from me 17:05:42 NobodyCam: yes - the meeting times 17:05:51 so folks if there's things you want to get done, please add them 17:06:02 oh devananda ++ 17:06:42 I sent out a follow-up email to the ML about two weeks ago now (in response to the last meeting we had at this time) 17:06:45 #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/069363.html 17:06:49 jroll, I'm looking forward you all fixing driver composition spec for me :) 17:06:52 that got only one response on the ML (thanks, jroll ) 17:06:59 dtantsur: :) 17:07:04 tldr; the alternating meeting times aren't working for us 17:07:22 yeah I haven't replied cause I've never attended the other meeting 17:07:25 heh 17:07:40 but if people that attends thinks it's not productive I'm +1 to remove it 17:07:43 for me the night time meeting is hard to attend as I fall asleep before it starts 17:07:48 given that, in two weeks, no one has said "please don't cancel them" I'm going to, well, cancel them 17:08:00 presumably all/most people in this meeting are fine with changing to have it now. maybe bring this up at the other date/time? 17:08:08 #info alternate meeting times are going to stop after the midcycle 17:08:21 I don;t attend the late night meetings at all 17:08:27 thank you devananda for hte # info 17:08:45 rloo: there wasn't even a meeting last week -- I cancelled it via the mailing list, with a reminder to discuss it if it was a problem, and no one did 17:09:09 I, for one, am looking forward to having a meeting with all of you every week, instead of every other week 17:09:16 ++ 17:09:18 NobodyCam: that's all for my announcements :) 17:09:46 +1 17:09:59 anyone else? 17:10:08 if not moving on. 17:10:20 #topic SubTeam: status report 17:10:20 Posted on Whiteboard 17:10:21 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:10:44 thank you for the updates.. not a whole lot new there 17:10:55 anything to go over? 17:11:07 please have a look at "testing" updates 17:11:07 ^^ re: the updates 17:11:09 yay for neutron/ironic specs landing! 17:11:37 awesome work on that everyone! 17:11:40 so, can we talk about the soft power / nmi interrupt thing that's currently under irmc? 17:11:55 that's something that all drivers should be able to support, and there's a spec underway to do so 17:11:58 jroll, Sukhdev: thank you (&others) for the work on the neutron ML2 spec. I'm really happy with where it is at now (approved, that is :) ) 17:12:12 jroll: yes pls 17:12:13 I'm of the opinion that we shouldn't land a vendor passthru from something actively being worked on with a proper api 17:12:45 will pxe_ipmitool support soft power? 17:13:02 dtantsur: why not? ipmi supports it 17:13:02 dtantsur: in principle, it could 17:13:13 * dtantsur just does not know :) 17:13:22 ipmitool [...] power soft # iirc 17:13:39 there are challenges inherent in supporting it, but those are the same regardless of driver 17:13:39 jroll, hmm not sure what would be the problem on landing those vendor passthru, yeah it would be good to have the vendors to work together on a proper implementation 17:13:44 but can't force on it 17:13:45 SNMP may not be able to (I'm not sure) 17:13:48 jroll: what's the spec you are mentioning? 17:13:54 lucasagomes: it's *already being worked on* 17:14:03 devananda: I beleieve you are correct 17:14:03 but any modern device with a BMC should be able to support it 17:14:07 then I'd rather make it a proper API 17:14:15 rloo: https://review.openstack.org//#/c/186700/ 17:14:23 lucasagomes: ^^ 17:14:33 +1 for proper api 17:14:43 jroll, right, but still we don't offer any guarantees for vendor passthru 17:14:45 it's being worked on via vendor passthru to support a customer request sooner 17:14:49 meaning that we don't have to keep backward compat 17:14:58 once the proper api lands we can just delete the vendor passthru ones 17:15:02 lucasagomes: sure, but do we want to land 1000 lines of code only to remove it shortly after? 17:15:08 fwiw, I believe AMT also supports it 17:15:18 given the time it takes to approve a spec and get it working, and that naohiro is the author of the spec AND the irmc code, I'm fine with his code. who knows when that code will get approved. 17:15:21 jroll, sure yeah I agree, I just don't think it's a big deal 17:15:34 I'm also concerned that the same person is working on the passthru api AND the official API, and incentive to do it properly drops if the passthru code lands 17:15:54 also, most of the code in the passthru is things that will need to be done in the general case (poll for power state etc) 17:16:12 ++ 17:16:14 I'm fine in principle for vendors to do new and challenging things in /vendor_passthru/ 17:16:20 we've already seen that with raid and vlan things 17:16:29 lucasagomes: I've already spent a lot of time reviewing the passthru implementation and it hasn't gotten very far. I'm not inclined to spend that much time on both implementations 17:16:34 yeah the same person working on both is def odd 17:16:48 however, this is really a common feature of almost all hardware 17:17:20 The stated reason is that their customers want it *now*. I'm not sure it's a compelling reason for us... 17:17:20 eg, it's not a matter of only one or two vendors' hardware supporting it 17:17:33 dtantsur: right, implement out of tree in that case 17:17:33 so it's odd for only one driver to support it 17:17:39 dtantsur, ++ 17:18:00 remind me again, what's the process for drivers proposing vendor-passthrus? do they have to write a spec or bug, or just propose code? 17:18:10 just code afaik, rloo 17:18:11 last time it was "just propose" 17:18:11 rloo, just propose the code 17:18:15 rloo: just code in general 17:18:32 do we want to like, vote on this or something? 17:19:28 on the one hand, I'm of the mind that we shouldn't block a vendor who wants to do something that is implemented purely in /vendor_passthru/ -- and really, we can't, because they can just do it downstream 17:19:42 so if naohiro had not proposed a spec, would we be asking this question? 17:19:51 on the other hand, as ya'll already said, it's odd to have the same person writing the same feature in both vendor_passthru/ and in the common API 17:20:01 rloo: I believe it was proposed in response to me asking the question :) 17:20:17 jroll, vote whether we should not land vendor passthru stuff if there's a spec proposed/merged? 17:20:22 others have asked for this feature to be commonly supported in the past, but no one else stepped up to write it yet 17:20:34 lucasagomes: vote on this case, idk abuot 'always' 17:20:41 "they can just do it downstream" is a good reason not to rush with landing something we have doubts in, at least as far as vendor passthru is oncerned 17:20:52 * concerned 17:20:56 right, and I'm concerned we're spending a lot of dev/review cycles on this 17:20:56 i think the "right" thing to do (to save everyone time etc) is for us to decide now that we'll support the spec and review/approve it in a timely fashion, and not review the vendor-passthru solution. 17:21:12 if you look at the patch there's a lot of back-and-forth and at least one full rewrite 17:21:22 but if we cannot give some sort of time frame for the spec, it seems unfair to block the code as is. 17:21:37 rloo, neither can we give some sort of frame for the patch 17:21:52 I suspect more people would care about a generic thingy 17:22:17 ^^ 17:22:23 dtantsur: yeah. that's true, no time frame for the patch. so ahhh, why do we need to vote on it. we could just not review it. personally decide I mean. (Oh, I said it out aloud.) 17:22:46 rloo: I think we need to give the author clear direction rather than just ignoring the patch 17:22:50 rloo, we can (and many do), but this particular approach is not honest IMO 17:23:02 people have ignored that patch enough already :) 17:23:04 rloo: I think jroll and I may be the only ones who have reviewed the patch ... because it's a driver-specific patch to vendor_passthru and, well, like you said .... 17:23:12 I'm ok with landing the VP code as long as it gets updated to the new in a timlly manner 17:23:25 nobody can guarantee 17:23:45 I think it will take about the same amount of time to land the VP and the non-VP, so why not point effort at the more general case? 17:23:49 rloo: so, there is a corresponding question for us as core reviewers -- do we hold /vendor_passthru/ to the same level of quality? do our users expect that of us? 17:23:59 right and this case in particular being the same author 17:24:03 unless we just approve anything that passes tests, which it is right now 17:24:04 I think it makes sense to work on the spec 17:24:07 rloo: if not, then why ignore the patch instead of just rubber stamping it? if so, then, well, we should have a different discussoin 17:24:16 devananda and jroll: in your opinion then, since you've reviewed the patch, do you think it is worth spending core-reviewer time reviewing that, or reviewing the spec/future code? 17:24:19 I'd like to timebox this to 17:30 btw, if devananda is cool with that 17:24:28 TY jroll 17:24:28 jroll: ++ to timeboxing 17:24:37 rloo: I don't think it is worth the time, that's why I brought it up :) 17:24:45 since they have the same author, we would prefer they spend the dev time on the general spec 17:24:54 Madasi, ++ 17:24:59 rloo: if this implementation were not vendor_passthru, it would definitely receive discussion and debate 17:24:59 yeah for this case this is fine ^^ 17:25:00 devananda, we won't do a good service for a person, if we land a patch that has problems 17:25:00 ok, so i trust jroll's opinion. lets go with the spec then. 17:25:32 i wasn't going to review that patch since there seem to be higher priority patches to review anyway. 17:25:37 rloo: whoa, let's not go that far (trusting my opinion) 17:25:40 :P 17:25:42 lol 17:25:57 alright, are we in agreement then? 17:26:01 I can put a note on the patch 17:26:05 do we want a # agreed on htis 17:26:06 ++ 17:26:10 ++ 17:26:12 jroll: trusting your opinion wrt effort to review? I think it is safe to do that :) 17:26:16 +1 for #agreed 17:26:20 rloo: I have applied a level of review to it that is less than I apply to core changes, but still thinking of "will this work for and provide value to the user?" 17:26:32 jroll: what's the vote? 17:26:43 we can vote instead 17:26:49 devananda: is it a problem for the vendor to add this passthru out-of-tree? 17:26:58 devananda, if we should block that VP patch and focus on the spec for this particular change 17:27:11 the vote sounds like > 50% 17:27:48 jroll: don't you have to do some sort of # vote thingy? 17:27:55 #vote should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first? Yes = "allow v_p" No = "require common code" 17:28:00 #startvote should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first? Yes = "allow v_p" No = "require common code" 17:28:01 Begin voting on: should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first? Valid vote options are Yes, allow, v_p, No, require, common, code, . 17:28:02 Vote using '#vote OPTION'. Only your last vote counts. 17:28:08 #undo 17:28:09 Removing item from minutes: 17:28:12 that didn't work, one sec 17:28:18 #startvote should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first? Yes No 17:28:19 Already voting on 'should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first' 17:28:28 um.. 17:28:29 #endvote 17:28:30 Voted on "should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first?" Results are 17:28:34 #startvote should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first? Yes No 17:28:35 Begin voting on: should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first? Valid vote options are Yes, No. 17:28:36 Vote using '#vote OPTION'. Only your last vote counts. 17:28:47 #vote no 17:28:52 yes == "allow vp implementation" 17:28:56 no == "require common change" 17:28:56 #vote no 17:28:58 #vote no 17:28:58 #vote no 17:28:59 #vote no 17:29:14 #vote no 17:29:18 #vote no 17:29:20 #vote no 17:29:21 #vote no 17:29:25 * jroll drafts comment 17:29:27 #vote no 17:29:28 #vote no 17:29:31 thanks everyone 17:29:37 #vote no 17:29:37 TY jroll 17:29:38 * rloo feels like changing vote just to be different 17:29:38 o/ 17:29:50 lol so hipster rloo 17:29:57 * TheJulia seconds this idea that rloo has 17:29:59 giving it 30 seconds more 17:30:02 alright 18:30 17:30:06 #vote no 17:30:39 #endvote 17:30:40 Voted on "should we accept a /vendor_passthru/ change for SOFT_OFF, or require this particular functionality be implemented as a common feature first?" Results are 17:30:41 No (13): TheJulia, Madasi, lucasagomes, rloo, BadCub, jroll, stendulker, dtantsur, Nisha, NobodyCam, JoshNang, natorious, thiagop 17:30:46 all righty then 17:30:52 :) 17:31:02 * jroll updates review 17:31:03 by the way, even though we voted -- it wasn't on the agenda that we'd discuss this, so it makes me a bit uneasy. 17:31:20 good to move on 17:31:21 yeah sounded like an open discussion thing 17:31:35 #topic Let's make a release 17:31:36 but alright, at least it sorted 17:31:36 jroll thats you. 17:31:44 release \o/ 17:31:45 sorry, I saw it on the subteam thing and had to ask 17:31:47 ok so! 17:32:04 we last released a server version at the end of kilo 17:32:08 jroll: agenda was light today so all is good 17:32:11 it's been a few months, we've landed a bunch of code 17:32:14 rloo: agreed. and that highlights that I (and collectively we all) should get better at putting things on the agenda 17:32:23 I'd like to propose we release a new version of the server this week 17:32:32 rloo: I hope that going back to weekly same-time meetings will help .the lack of continuity has been hard ... 17:32:40 this will involve switching to semver, which appears non-trivial but I may be wrong. 17:32:58 there's concerns that the addition of enroll will break users 17:32:59 devananda: here's hopin' :) 17:33:04 jroll: the semver switch got embroiled in a debate about packaging and epochs a few weeks ago -- i need to follow up with dhellmann on that 17:33:11 jroll: unless you have updates to share? 17:33:32 however currently, with the current client, the enroll thing is opt-in only, so I'd not like to wait on that discussion for a release. 17:33:35 please discuss :) 17:33:41 devananda: I don't, I need to investigate more 17:33:50 jroll: also, I have been pretty vocal about my concern with the change to default state == ENROLL, and pushing that into the client's responsibility is not acceptable IMO 17:34:09 devananda: folks have released liberty-1 in other projects, so I believe that may be solved. 17:34:21 I failed to catch this during the spec review and apologize for not bringing it up / noticing it sooner 17:34:25 devananda: right, so. I don't believe that is a breaking change. 17:34:49 we also discussed it on the summit... 17:35:00 devananda: it's opt-in right now, it's a small change to any automated systems that depend on that behavior 17:35:09 dtantsur: I don't understand why there'd be any pushback to an opt-in approach as I mentioned on the ML 17:35:23 devananda: if users choose to use that version of the API, they should be aware of the repercussions 17:35:38 this *is* opt-in, by *choosing that API version* 17:35:42 I don't want people to opt-out our changes in the state machine 17:35:51 jroll, exactly. we have on opt-in already, lets not have more 17:35:57 yeah 17:36:17 I have thought and discussed about it for a while last week with dtantsur and jroll on IRC 17:36:29 IMO in the long run I believe that having the version mandatory would be the best approach 17:36:39 for the next reelase I think we should still PIN at a specific version prior to ENROLL 17:36:40 why didn't you guys summarize in that email thread? 17:36:51 it's not opt-in if the client ever changes the version it defaults to 17:36:52 if we're going to spend this time debating if 1.11 breaks users, then let's forget about releasing and take this back to the ML 17:36:54 but have a warning message to alert about the behavior change 17:37:10 ok 17:37:24 I'm not going to waste this meeting having this conversation for the tenth time 17:37:26 jroll: for the release, there's going to be a corresponding client release, right? 17:37:33 devananda, it is our approach to versioning that is broken, not enroll patch.. 17:37:41 let's just move on because we're never going to actually release with this discussion ongoing 17:37:43 (me starts his favorite song) 17:37:50 dtantsur: +1 17:37:56 jroll: agreed - let's move on 17:37:57 or our lack of approach 17:37:58 dtantsur: also agreed 17:38:01 ack 17:38:08 yeah alright ML seems better indeed 17:38:14 and midcycle 17:38:16 can we have an action item for jroll + semver? 17:38:19 so 17:38:19 #topic Open Discussion / Food For Thought 17:38:20 wait 17:38:23 wait 17:38:32 https://review.openstack.org/#/c/193439 17:38:35 devananda, we can temporary disable 1.11 for the release. but we'll have to solve this problem in the future anyway 17:38:37 we're going to wait for the midcycle to even consider releasing a thign? 17:38:40 seriosuly? 17:38:46 jroll: not what i meant 17:39:06 jroll: just that the topic of versioning th eAPI is probably something we'll discuss, quite possibly over many drinks, at the midcycle 17:39:16 we tried to change our release model to release faster, now we've found out we don't know wtf versioned APIs mean and so block a release for a month (now) and probably longer 17:39:17 so pity I won't be there :D 17:39:19 but I hit enter too soon and then tpic changed 17:39:38 we can change back 17:39:43 it's fine, go ahead 17:39:49 I just wanted to ask / point that out 17:39:49 let's try to sort it out on the ML 17:39:53 if we were doing liberty-1, wouldn't we just have done it regardless of the enroll stuff/state now? 17:39:58 jroll, mind summarizing the ideas today and sending an email? 17:40:04 rloo, we would 17:40:05 I will try, yes 17:40:09 we can continue from there, I don't think it should take much time 17:40:16 thanks 17:40:28 https://review.openstack.org/#/c/193439 17:40:34 sinval you here 17:40:38 yep 17:40:45 your up 17:40:48 :) 17:41:02 * krotscheck is trying to get bethelwell to the midcycle, because webclient things. 17:41:07 so, a port can be created via a POST /v1/ports, with 'node_uuid' and 'address' specified in the body 17:41:33 this patch should add the possibility to create ports using node_name if the user wants it 17:41:50 sinval_: node_name isn't a property of a PORT, however, and shouldn't be 17:42:02 hum 17:42:08 sinval_, so the advatage it brings is that it's easier to script? node-create ... name=blah && port-create -n blah 17:42:23 lucasagomes: yep 17:42:28 anything else? 17:42:37 sinval_: the client could easily GET /nodes/ to fetch the UUID and use that in the BODY of POST /v1/ports/ 17:42:39 i don't think so 17:42:43 cause we still can parse the return value from node create and figure the node uuid 17:42:48 well 17:43:01 I see the advantage with the names 17:43:03 so I think 'port-create --node-name blah' should be a thing 17:43:08 what are we discussing? whether to allow the use of node name for port create? 17:43:08 it makes the client a bit nicer 17:43:13 yeah 17:43:20 and we can get_node_by_name() or whatever on the backend 17:43:24 so the thing is node_uuid in the ports is just part of the API object 17:43:31 and set port.node_uuid 17:43:32 it's generated from node_id that is part of the RPC object 17:43:42 well, regardless of how we have coded things now, does the idea of using node name make sense or not? 17:43:43 yes 17:43:43 or port.node_id, I guess 17:43:45 I don't see the problem of having node_name in the ports for the API 17:43:58 we could keep both node_uuid and node_name 17:44:14 lucasagomes: ah right. so the API tier can detect whether the supplied resource is uuid-like, and if not, try to look up the node by its name 17:44:18 we support names for nodes I kinda feel we should be able to ref that name just like we do uuid everywhere uuid would be used.. imho 17:44:22 we need to keep them both, or node_name is unique? 17:44:24 if people likes the idea of having a port created using the name 17:44:29 so there's no need to do anything different in the client either 17:44:34 devananda, yup 17:44:49 devananda, we can do that, so one could create a port either using the uuid or name 17:45:01 I'm good with having both of them 17:45:01 it won't be saved on the db or anything 17:45:04 rloo: from a user POV, yes -- using a Node name to refer to one or more Ports is helpful 17:45:06 so if name changes on the node that's grand 17:45:28 lucasagomes: I like that 17:45:29 #link https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/port.py#L57-L75 17:45:30 i'm a bit lost then, trying to figure out what we're discussing, need to agree with? 17:45:41 on the last patch, Ramakrishnan suggested that we should have two fields in the port object, one that already exists (node_uuid) and a new one (node_name) and both can now be used to create a port 17:45:51 but we shouldn't store the node_name on the Port object, nor return it in the API. and as lucasagomes points out, we don't even need to modify the client or add a new --node-name option 17:46:02 oh, we don't need the port object to save the node name. just the node id. 17:46:11 like devananda said ++ 17:46:11 ++ 17:46:15 sinval_: so, the Port DB object only stores the node_id (NOT uuid) today 17:46:17 is node_name unique? 17:46:24 yes 17:46:30 Madasi, it's but it can be changed 17:46:35 sinval_: the API tier returns the UUID to the user, since ID is internal only. 17:46:38 so it's not a canonical id for the resource 17:46:41 sinval_: i do not see any reason for that to be changed 17:47:00 devananda: ok 17:47:13 if it can be changed, so we have to have the option to use uuid 17:47:16 Madasi: node.name is unique on the nodes table, but it is not used for referential integrity -- the node.id field is the referential key 17:47:33 so did we jsut # agree on lucasagomes idea? 17:47:41 NobodyCam: I support it 17:47:46 devananda: thanks, makes sense 17:47:48 so one thing 17:47:54 I think the problem with passing name there 17:48:03 is the parameter is node_uuid, not node 17:48:10 so node_uuid=my_name is weird 17:48:35 jroll: so update the param to node_id_name? 17:48:38 jroll: didn't we have a similar issue with the node API?, we changed/added 'node' I htink, and still support 'node_uuid'? 17:48:56 jroll: where 'node' can be uuid or name. 17:49:05 in the patch i changed the 'node_uuid' to 'node' 17:49:05 +1 to rloo 's idea 17:49:10 rloo: indeed, I like that here too 17:49:19 rloo: we changed that internally to simplify code paths 17:49:31 the REST API for PUT still accepts both "uuid" and "name" fields -- and both are optional 17:49:38 if not supplied, "uuid" is auto generated 17:50:10 that's not the case for Ports, where the REST API requires a node_uuid parameter 17:50:14 http://docs.openstack.org/developer/ironic/webapi/v1.html#Port 17:50:16 we have another item I do want to get to 17:50:27 * lucasagomes has an item as well 17:50:28 devananda: yeah, that's for node-create. i was thinking of other node operations, where we had specified uuid before, but can specify uuid or name now. 17:50:31 so jroll is correct about the REST API changes 17:50:44 rloo: right - but the question here is for Port create 17:51:05 let's come back to this on the review so we can move on now 17:51:19 ack 17:51:27 so then: Scheduling things 17:51:27 should we build a filtering API or a scheduler or both? Would be really useful both for nova and standalone installations. 17:51:37 jroll: thats you again :) 17:51:55 ohai 17:51:56 #link https://review.openstack.org/#/c/204641 17:51:57 oh ... this is much more than a 9 minute discussion 17:52:05 #link https://review.openstack.org/#/c/194453/ 17:52:08 uuu yeah that will take some time 17:52:22 also, I'm very strongly of the opinion that a placement / reservation / proper scheduler implementation inside ironic is absolyutely crazypants 17:52:25 so table to ML or next meeting? 17:52:39 devananda: so every standalone installation should build their own scheduler? 17:52:43 I left some suggestion on the spec, didn't catch up with the answers yet 17:53:14 jroll: ironic should expose enough data to integrate with other schedulers. and in the absence of that, perhaps we integrate with *A* scheduler by default 17:53:17 so what this came from was the nova midcycle 17:53:18