17:00:09 <jroll> #startmeeting ironic
17:00:09 <openstack> Meeting started Mon May 16 17:00:09 2016 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:12 <openstack> The meeting name has been set to 'ironic'
17:00:12 <jroll> hai everyone
17:00:20 <mariojv> o/
17:00:24 <jlvillal> o/
17:00:25 <mat128> o/
17:00:30 <rama_y> o/
17:00:36 <NobodyCam> 0/
17:00:39 <NobodyCam> :p
17:00:42 <yuriyz|2> o/
17:00:42 <vdrok> o/
17:00:44 <rloo> o/
17:00:45 <devananda> o/
17:00:50 <mgould> o/7
17:00:52 <jroll> #chair devananda NobodyCam
17:00:53 <openstack> Current chairs: NobodyCam devananda jroll
17:00:59 <jroll> #topic announcements and reminders
17:01:01 <dtantsur> o/
17:01:03 <blakec> o/
17:01:07 <lucasagomes> o/
17:01:11 <jroll> so, people have been chugging along on grenade work
17:01:25 <jroll> it seems to be going well, lots of fun there
17:01:30 <vsaienko1> o/
17:01:48 <NobodyCam> great work every one!
17:02:05 <jroll> I also have a chain of patches up for all the deprecated stuff we need to drop, if people want to get that done https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:deprecations
17:02:48 <milan> o/
17:03:10 <sambetts> o/
17:03:16 <jroll> last, looks like the virtual vs physical midcycle doodle is overwhelmingly in support of virtual: http://doodle.com/poll/4vm5ea28t3qyn7bp
17:03:47 <krtaylor> o/
17:03:50 <jroll> I'll send out a more official email about that later[
17:03:56 <jroll> any other announcements or reminders?
17:04:06 <rloo> jroll: which means it will be virtual?
17:04:09 <jroll> rloo: yes
17:04:22 <rloo> jroll: thx. I wanted that yes recorded :D
17:04:27 <lucasagomes> heh
17:04:31 <jroll> hah
17:05:32 <rloo> possible date will be another poll?
17:05:40 <jroll> maybe!
17:06:06 <rloo> :)
17:06:19 <jroll> #topic subteam status updates
17:06:36 <jroll> as always:
17:06:38 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:06:42 <pas-ha> o/
17:06:45 <jroll> starts at line 80 this week
17:08:00 <rloo> dtantsur: wrt spring bug clean up, would it be good for folks to help you. maybe *after* the grenade effort?
17:08:46 <jroll> ++
17:09:04 <jlvillal> jroll: Back-tracking. On the virtual midcycle, are there date-ranges when think it will happen? Can I assume that will be in the follow-up email :)
17:09:22 <jroll> jlvillal: I haven't thought much about it, sorry
17:09:31 * jlvillal would vote for not conflicting with Nova mid-cycle. Especially since he is on vacation that week :)
17:09:44 <jroll> jlvillal: it won't, I'll be busy at nova midcycle that week :P
17:10:01 <dtantsur> rloo, yeah
17:11:28 <jroll> anything else on subteam updates?
17:11:29 <rloo> lots of great work done on grenade and gate stuff. i hope you have been chugging beer too.
17:11:58 <sivaramakrishna> vsaienko1: there?
17:12:10 <vsaienko1> sivaramakrishna yes
17:12:45 <sivaramakrishna> I've rebased the devstack related patches https://review.openstack.org/#/c/256364/ etc
17:13:06 <jroll> can this be taken outside of the meeting? :)
17:13:12 <jroll> (unless it's a topic for the group
17:13:13 <jroll> )
17:13:21 <jlvillal> +1
17:13:30 <sivaramakrishna> sure, jroll
17:13:33 <jroll> thanks
17:13:35 <jroll> moving on
17:13:44 <jroll> #topic Active Node Creation/adopt
17:13:50 <jroll> #link https://review.openstack.org/#/c/275766
17:13:55 * jroll hands rloo the mic
17:14:35 <rloo> so i just want to know if we want to have adopt be changed to deploy
17:14:40 <rloo> if the microversion is older
17:14:46 <rloo> https://review.openstack.org/#/c/275766/17/ironic/api/controllers/v1/node.py
17:14:53 <rloo> line 133
17:15:18 <rloo> there are a few +2 for that patch
17:15:32 <rloo> i don't think there should be.
17:15:33 <devananda> rloo: that seems to me to be a good shim for backwards compatibility, eg. with Nova
17:15:37 <jroll> yeah, I don't recall a group chat about this
17:15:44 <devananda> rloo: could you explain what risk or negative impact you think it will have?
17:15:48 <mat128> rloo: I vaguely remember an against against: old API microversion cannot act on "adopt" the same way we can act on "deploy"
17:15:50 <jlvillal> What would it report then? I assume this is just to report the state to an old client.
17:15:53 <rloo> devananda: well, we don't do anything for eg inspector
17:15:58 <NobodyCam> I see the point, but I personally don't see a issue with it
17:16:09 <devananda> jlvillal: that is my understanding as well
17:16:17 <rloo> we aren't consistent with it. and does it make sense that 'adopt' is 'deploy'?
17:16:20 <devananda> make a node in the ADOPTING transition appear to older clients in a way that they understand it
17:16:22 <dtantsur> jlvillal, the truth like we always do?
17:16:42 <jroll> so julia said: "I think we shouldn't be exposing new node states to older clients, and that is represented in the specification, that we conceal to older clients. IMO, it is a breaking change because the state is leveraged for programatic decisions by API clients."
17:16:43 <NobodyCam> devananda: jlvillal: that is my understanding too
17:16:45 <dtantsur> devananda, the clients have to be ready for unknown states. otherwise any additions breaks them
17:16:46 <rloo> what about 'clean'. what should we do there?
17:17:00 <jroll> if "the state is leveraged for programatic decisions by API clients", we shouldn't lie about the state
17:17:00 <dtantsur> e.g. you can't replace ENROLL with anything. Nor CLEANING.
17:17:11 <devananda> rloo: inspecting isn't a state within the AVAILABLE->ACTIVE->AVAILABLE cycle, ie, that Nova cares about
17:17:33 <dtantsur> devananda, neither is ADOPTING, it does not start with AVAILABLE
17:17:45 <rloo> i don't want to focus on nova specifically. just want to know how we want to handle this and all states we've added
17:17:58 <jroll> fwiw, this won't break nova
17:18:01 <rloo> devananda: are you saying that this is actually needed for nova?
17:18:08 <jroll> nova only cares if a thing is available or not
17:18:14 <jroll> https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L179
17:18:21 <dtantsur> yeah, I don't get the nova argument here too. we introduce new states constantly, it never broke them
17:18:23 * jlvillal wonders if we should have an "UNKNOWN" state to report to older clients?
17:18:30 <jroll> there *is* this: https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L72
17:18:38 <jlvillal> You don't know about this state, go away...
17:18:44 <jroll> but you can't unprovision from adopting or deploying, so it's irrelevant
17:18:53 <rloo> so I understand what julia meant wrt not showing new states etc. but the truth is that we haven't been hiding new states. so why start now. or do we want to hide new states?
17:18:55 <devananda> jroll: right
17:18:56 <jroll> apparently you can from deploying? wat?
17:18:59 <dtantsur> jlvillal, how will it help anyone?
17:19:13 <dtantsur> except for our love to microversion everything?
17:19:14 <jroll> which shows me even more we shouldn't pretend this is deploying
17:19:25 <rloo> adopting is NOT deploying
17:19:54 <lucasagomes> I'm a bit out of context (I haven't reviewed the patch) but I tend to agree with rloo re inconsistencies
17:20:04 <lucasagomes> since it hasn't been the case for other states
17:20:05 <jroll> so I agree with rloo here, and have commented as such on the patch
17:20:15 <jroll> if someone can convince me this is necessary for some reason, I'm happy to listen
17:20:43 <jlvillal> Does that also imply that clients should not break if they see a state they don't know about?
17:20:56 <mat128> jlvillal: thought that was already the case
17:21:11 <jlvillal> It makes sense to me to have it that way.
17:21:27 <devananda> jroll: an older client can not reasonably act on a node in a state that didn't exist in the version which that client was designed for
17:21:53 <jroll> devananda: do we assert that an older client should be able to reasonably act on a node that is in the ADOPTING state?
17:22:01 <mat128> devananda: how did we introduce inspecting?
17:22:02 <jroll> devananda: especially when we lie about that state?
17:22:21 <dtantsur> mat128, and enroll. and cleaning (actually cleaning was a troublesome one, it did break nova iirc)
17:22:22 <devananda> jroll: fair point. nope.
17:22:26 <jroll> :)
17:22:39 <jroll> if we lie about the state, bad decisions will be made
17:24:08 <NobodyCam> would it be better to  obj.provision_state = ir_states.AVAILABLE
17:24:12 <jroll> so does anyone still agree that we should munge this state in the api response?
17:24:25 <dtantsur> NobodyCam, oh no, nova will try to use it
17:24:28 <jroll> NobodyCam: huh?
17:24:30 <jroll> yeah that
17:24:30 <devananda> jroll: and if we return the state to older clients, are we certain they'll ignore it?
17:24:43 <NobodyCam> gah ... Active!!!
17:24:50 <NobodyCam> :p
17:24:54 <lucasagomes> NobodyCam, I think no, cause then the client could potentially act against AVAIALBLE
17:24:56 <mat128> NobodyCam: ACTIVE would be closer to the truth, considering a node will transition into active when it's done
17:24:57 <mat128> but still lying
17:25:09 <lucasagomes> but since it's not really AVAILABLE, things can happen (bad ones)
17:25:19 <dtantsur> NobodyCam, we do support a couple of actions on ACTIVE, which we can't support on ADOPTING
17:25:20 <rloo> NobodyCam: active won't work either, cuz it is adopting. after adopting, if it succeeds, it will be active.
17:25:26 <devananda> mat128: I believe that's the point of the current patch. returning DEPLOYING because the node will transition to ACTIVE when adoption finishes
17:25:26 <jroll> devananda: ignore it in terms of... not do something with it or?
17:25:31 <devananda> jroll: right
17:25:46 <jroll> devananda: I mean, I would hope so, but I can't speak for code I don't know
17:25:52 <NobodyCam> AVAILABLE was bad typing ... ACTIVE was what I was thinking
17:26:02 <devananda> jroll: as opposed to, say, tyring to do things it can't do (which, you have a valid point, would also happen if we return DEPLOYING and the client tries to DELETE)
17:26:11 <mat128> NobodyCam: ACTIVE should have instance_uuid, this one wont
17:26:13 <vdrok> if we want to substitute, deploying is the best fit I think, actions are the same. but it seems we don't
17:26:36 <jroll> devananda: "if state is something I've never coded for, do something destructive" sounds crazy, if someone writes that code that's their own gun pointed at their feet imo
17:26:43 <lucasagomes> mat128, not necessarily if used in stand-alone mode
17:26:53 <mat128> lucasagomes: true..
17:27:06 <dtantsur> ACTIVE is a stable state, I don't think we should consider it..
17:27:10 <lucasagomes> mat128, but ACTIVE does allow user to delete the instance (which can turn out bad)
17:27:19 <devananda> jroll: I've seen code assume things like "if state in LIST_OF_STATES: do this; else: do that;"
17:27:28 <lucasagomes> yeah I think the best fit is actually DEPLOYING, but not sure it's _required_
17:27:38 <devananda> jroll: so it is code like that I am concerned about
17:27:40 <mat128> lucasagomes: what happens if we just return ADOPTING? Can we confirm it won't break a node-list on older client?
17:27:44 <vdrok> and btw, nova won't manage adopted nodes right?
17:27:46 <jroll> devananda: yeah, but 'that' being something destructive? idk
17:27:51 <devananda> lucasagomes: fwiw, ADOPTING does not allow delete
17:27:56 <devananda> https://review.openstack.org/#/c/275766/17/ironic/common/states.py
17:28:03 <rloo> look, we have a lot of new states since 'adopting' (sorry) the new state machine: http://docs-draft.openstack.org/66/275766/17/check/gate-ironic-docs/52915ef//doc/build/html/_images/states.svg
17:28:13 <dtantsur> devananda, then here's the question: are we ready to do it every time now? even when we don't have a good candidate? like imagine we would have to introduce ENROLL.
17:28:19 <lucasagomes> devananda, yup yeah that's reinforce the idea of not using ACTIVE to mask it
17:28:19 <rloo> we do not (yet) handle masking new states from older versions.
17:28:32 <lucasagomes> mat128, we can totally test that, it should not off the top of my head
17:28:32 <dtantsur> (apparently we broken all that people when we did it already, so now they're ready :D )
17:28:49 <devananda> dtantsur: yea, we've had similar discussions (and difficulties) every time we've introduced new states
17:29:19 * jroll pulls the pin and asks "is our state machine part of our api contract?"
17:29:25 <devananda> jroll: yes
17:29:29 <rloo> it seems like we introduced microversions when we introduced enroll. the versioning was meant to handle these new states.
17:29:48 <dtantsur> rloo, we introduced microversions on NOSTATE->AVAILABLE change
17:29:55 <dtantsur> which was breaking for nearly everyone starting with Nova
17:30:07 <devananda> jroll: the list of "verbs" that an API accepts is part of that contract
17:30:12 <jlvillal> hmmm NOSTATE...
17:30:17 <dtantsur> it's unclear to me whether introducing ADOPTING breaks anyone, who already recovered from ENROLL and CLEANING
17:30:30 <jroll> devananda: yes, but that isn't strictly the state machine
17:30:32 <rloo> ++ dtantsur
17:30:48 <devananda> jroll: it is how one interacts with the state machine
17:30:50 <dtantsur> but NOSTATE is different, it IS a synonym for AVAILABLE
17:30:53 <jroll> devananda: I'm asking e.g. is the list of possible states part of the api contract?
17:30:55 <mgould> ISTM the real problem is that we have no way of saying "your client must be at least this recent to talk to me"
17:31:04 <jroll> devananda: are transient states part of the contract?
17:31:06 <jroll> etc
17:31:08 <mat128> state machine changed when new nodes started in "enroll" instead of "available"
17:31:20 <devananda> jroll: ok. that's slightly different than the acceptable verbs, but I also believe that's part of the contract
17:31:50 <devananda> jroll: think of a programming API. if a function introduces a different return code, is that a change in the contract?
17:31:56 <jlvillal> I said this before, but can the contract also be if you see a state you don't know about don't crash and don't try to do things on that node.
17:32:01 <rloo> it seems to me that if someone does something to ironic using version X, we shouldn't have to guarantee that everything will work loverly if they then use version X-i.
17:32:42 <mat128> rloo: but staying on version X and not hiding ADOPT means I will see ADOPT at some point
17:32:50 <mat128> just because Ironic was upgraded, but api version stayed the same
17:33:01 <jroll> devananda: well, it depends, right? do the docs for that function say "returns an integer" or "returns an integer, one of [0, 1, 2, 3]"
17:33:13 <rloo> mat128: i mean microversion. you mean v1/v2 of the URL?
17:33:13 <dtantsur> mat128, meaning someone in your cloud started using X+i and new features...
17:33:23 <devananda> jroll: indeed
17:33:54 * mgould thinks we're doing this backwards
17:34:03 <mgould> client sets the API version, server tries to handle it
17:34:16 <mgould> it should be the server that sets the version, and the client that has to adjust
17:34:22 <jroll> devananda: and here is our doc on the Node object in an api response http://docs.openstack.org/developer/ironic/webapi/v1.html#ironic.api.controllers.v1.node.Node.provision_state
17:34:30 <dtantsur> mgould, well, that's not the intention of API versioning in our case :)
17:34:38 <jroll> devananda: which is "Represent the current (not transition) provision state of the node"
17:34:39 <rloo> mgould: that won't work; it'd really break clients.
17:34:42 <mat128> why not hide anything that doesnt exist for a microversion under an "UNKNOWN" state?
17:34:47 <devananda> mgould: we have a mechanism in place for the server to indicate the minimum version the client must support to interact with it
17:35:08 <dtantsur> mat128, how is it different? people start seeing UNKNOWN nodes at random stages of their lifecycle
17:35:09 <devananda> mgould: are you suggesting that we should raise that minimum version?
17:35:17 <mgould> devananda, yes
17:35:26 <dtantsur> hmmmmmm
17:35:27 <devananda> that's interesting
17:35:29 <mat128> dtantsur: yes, but at least it keeps working. If we require a new-enough client, that means I can't even upgrade Ironic
17:35:37 <mgould> but IIRC the last time we had this discussion we concluded that we could never ever raise it
17:35:57 <mat128> dtantsur: If you want to know what the UNKNOWN means, you can always use a newer API version
17:36:00 <dtantsur> mat128, we don't require anything. you just should not make assumptions about things we explicitly don't guarantee. like that we'll never add more states.
17:36:01 <mgould> because by definition that would break clients
17:36:05 <devananda> we could, in a response that includes nodes with ADOPTING state, include the X-OpenStack-ironic-API-Min-Version: 1.xx header
17:36:07 <devananda> just for that response
17:36:10 <pas-ha> never ever is too heavy brick to carry
17:36:17 <jroll> ...
17:36:20 <mgould> pas-ha, exactly
17:36:25 <jroll> devananda: pls no
17:36:26 <rloo> i think raising the minimum version is a different discussion. unless you thinkwe should raise it whenever we have something that isn't 'backwards compatible'
17:36:26 <devananda> I haven't thought this through yet - just tossing the idea out
17:36:41 <mgould> rloo, YES! :-)
17:36:43 <dtantsur> devananda, I already imaging getting bugzillas like "ironicclient crashes on my deployment"...
17:36:54 <dtantsur> I mean, I like your idea, but only in an ideal world :)
17:36:55 <devananda> jroll: I don't mean "raise it all the time" - just raise it for the response that includes incompatible things
17:37:01 <devananda> dtantsur: hehe
17:37:08 <jroll> rloo: mgould: that completely defeats the purpose of versioning at all
17:37:11 <rloo> mgould: that is totally against the idea behind microversions
17:37:16 <jroll> yeah
17:37:21 <jroll> might as well just not version
17:37:33 * dtantsur feels like the discussion goes a bit too far
17:37:38 * lucasagomes feels the same
17:37:40 <jroll> devananda: right, I think a minimum that changes based on the endpoint or response is HOLY COW
17:37:43 <rloo> jroll: right, and i have to say, i like that idea. not versioning and not caring about breaking people's stuff.
17:37:46 <devananda> so, I believe this is actually exactly what version negotiation is for
17:37:51 <devananda> rather than the client to behave unexpectedly when it gets a result it does'nt understand
17:38:03 <dtantsur> rloo++
17:38:06 <mgould> jroll, oh right, I don't like the idea of min-version being a function of endpoint either
17:38:07 <devananda> it would fail early with a message such as "unable to talk to this endpoint, required version XX"
17:38:46 <devananda> also, yea, we're pretty far off track now ...
17:38:47 <jroll> real talk: do we expect a deployment that is using this feature to ever use a version lower than the one that introduces this feature?
17:39:02 <dtantsur> I hope not, but I'm afraid yes
17:39:02 <vdrok> can we just state somewhere - don't do anything with a node in a state you don't know about? Is it enough?
17:39:03 <sambetts> wouldn't that lead to the client failing transiently? e.g. if I did a node-list it would work sometimes but not others
17:39:10 <NobodyCam> dtantsur: ++
17:39:15 <dtantsur> e.g. imagine people using 3rd party tooling for Ironic
17:39:22 <jroll> great :|
17:39:33 <jroll> ok, so this comes down to two sides:
17:39:36 <devananda> jroll: absolutely
17:39:39 <jroll> 1) lie about the actual state of the node
17:39:56 <jroll> 2) pass an unknown state to clients
17:40:02 <mgould> jroll: 1.1) lie in different ways about the actual state of the node to different clients
17:40:11 <mat128> we have 3rd party tooling for Ironic here, and from checking: it wont crash for an unknown state (thankfully), but if we raise min-version is breaks :(
17:40:12 <rloo> 3) return the actual state
17:40:23 <jroll> rloo: 2 == 3
17:40:24 <dtantsur> I think 3==2
17:40:27 <lucasagomes> rloo, I think that's 2
17:40:29 <lucasagomes> yeah
17:40:32 <rloo> oh, sorry.
17:40:35 <jlvillal> I vote for 2   https://en.wikipedia.org/wiki/Robustness_principle
17:40:38 <wajdi> report the correct state, but indicate to the client that the version does not allow for manipulating that state?
17:40:40 <jroll> 2) pass a new unknown state to clients
17:40:58 <jlvillal> As in the clients should be robust in accepting unknown states.
17:41:04 * rloo thought 2 was a new "unknown" state.
17:41:16 <mat128> "UNKNOWN" or actual state should be no different if clients are coded correctly
17:41:17 <jroll> 2) pass a new unknown state (adopting) to clients
17:41:24 <jroll> :)
17:41:27 <mat128> I'm afraid they might not, so "UNKNOWN" might help us in the future
17:41:36 <rloo> 2) is consistent with what we are doing currently
17:41:42 <vdrok> wajdi: but then older clients won't understand this indication? :)
17:42:08 <dtantsur> mat128, if they care about adopting UNKNOWN, they might as well care about avoiding hardcoding the whole list of states
17:42:10 <jroll> do we need some sort of formal meeting/ML vote on this, or can we be adults and handle it in gerrit?
17:42:16 <jroll> (and is there more to discuss?)
17:42:41 <thiagop> jroll: I think you shoud do a "vote" to clarify options due to the confusion in 2
17:42:42 <rloo> why can't we vote now?
17:42:50 <mat128> dtantsur: thats why I said "if they are coded properly", fwiw the only 3rd party client I know of would accept either
17:42:53 <jlvillal> Does: pass a new unknown state to clients in this particular case mean "ADOPTING".  Assuming it doesn't mean a state "UNKNOWN"
17:43:17 <devananda> jroll: fwiw, after discussing this, I agree with (2)
17:43:31 <lucasagomes> I think 2 is consistent to what've done in the past. Plus, adopting is a rare (for lack of better word) state? Since it's used to migrate existing workloads to ironic and should not happen often
17:43:38 <NobodyCam> just pointing out that the author is not here for this.
17:43:55 <rloo> NobodyCam: the author was fine with a vote on it. see her comments.
17:44:21 <devananda> I had thought that (1) would allow it to be compatible with existing clients (eg, Nova), but it clearly won't be
17:44:27 <devananda> lucasagomes: in some environments, it may not be all that rare
17:44:56 <rloo> NobodyCam: line 136, https://review.openstack.org/#/c/275766/12/ironic/api/controllers/v1/node.py
17:44:58 <lucasagomes> devananda, fair, but it's like a operator driving action. It's not like CLEANING which is actually part of the "main loop"
17:45:05 <devananda> lucasagomes: true
17:45:09 <dtantsur> devananda, out of curiosity: do you envision using both Nova and ADOPT in one deployment? ADOPT does not play with nova at all, right?
17:45:15 <jroll> okay are folks ready to vote on this then?
17:45:18 <dtantsur> (feel free to answer in channel)
17:45:27 <devananda> dtantsur: absolutely
17:45:40 <devananda> imagine a phased migration of a very large existing bare metal deployment -- as existing DCs are connected to the nova+ironic management layer ,they get "adopted"
17:45:58 <mariojv> ready to vote
17:46:09 <jroll> #startvote should we (1) change the provision_state in the api response to deploying or (2) return the actual (adopting) provision_state in the api response? 1, 2
17:46:10 <openstack> Begin voting on: should we (1) change the provision_state in the api response to deploying or (2) return the actual (adopting) provision_state in the api response? Valid vote options are 1, 2.
17:46:12 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:46:12 <mat128> devananda: then there's the issue of "how do I get instances without deploying anything?" :)
17:46:15 <devananda> jroll: ++
17:46:21 <jroll> #vote 2
17:46:22 <dtantsur> #vote 2
17:46:23 <lucasagomes> #vote 2
17:46:23 <mariojv> #vote 2
17:46:26 <jlvillal> #vote 2
17:46:28 <mgould> #vote 2
17:46:28 <mat128> #vote 2
17:46:29 <devananda> #vote 2
17:46:36 <NobodyCam> #vote 2
17:46:39 <vdrok> #vote 2
17:46:41 <thiagop> #vote 2
17:46:41 <sambetts> #vote 2
17:46:44 <wajdi> #vote 2
17:46:47 <devananda> mat128: you mean eg. boot from volume?
17:47:01 <jroll> and somehow we're still talking about this? :)
17:47:02 <rloo> #vote 2
17:47:10 <mat128> devananda: like I have a thousand machines to "import" into the OpenStack world, they come from an old world system
17:47:13 * jroll gives it another 2 minutes or so
17:47:24 <mat128> I want instances and nodes, but must not touch power state or data
17:47:26 <devananda> jroll: good job getting everyone to a concensus :)
17:47:30 <jroll> heh
17:47:43 <mat128> devananda: This bp helps me getting the nodes in, but instances are something else that has to be taken care of
17:48:12 <devananda> mat128: ah - I see. you mean how to create the corresponding Nova instances?
17:48:14 <rloo> mat128: yes, it doesn't address how to hook it in with nova.
17:48:20 <mat128> devananda: exactly
17:48:29 <jroll> mat128: insert into instances ...; "D
17:48:30 <mat128> rloo: yup, that's future work
17:48:32 <jroll> s/"D/:D
17:48:36 <mat128> Haha
17:48:38 <devananda> jroll: :)
17:48:46 <mat128> we were aiming more for nova boot with nodes on the fake driver, but whatever works
17:48:50 <mat128> you have to deal with Neutron and stuff
17:48:53 <mat128> #offtopic
17:48:59 <mat128> next?
17:49:02 <jroll> ya
17:49:04 <jroll> #endvote
17:49:05 <openstack> Voted on "should we (1) change the provision_state in the api response to deploying or (2) return the actual (adopting) provision_state in the api response?" Results are
17:49:06 <openstack> 2 (14): lucasagomes, devananda, rloo, jlvillal, mariojv, mgould, mat128, dtantsur, jroll, NobodyCam, wajdi, sambetts, vdrok, thiagop
17:49:07 <jroll> now
17:49:13 <jroll> please go apply those votes in gerrit :)
17:49:30 <jroll> #topic open discussion
17:49:50 * jroll welcomes people to throw random dates at him for midcycle-ing
17:50:17 <jroll> the week of june 27 and july 18 are out
17:50:25 <lucasagomes> jroll, I would end of june ?
17:50:33 <lucasagomes> I will, *
17:50:37 <rloo> jroll: would it be useful before or after nova or doesn't matter?
17:50:47 <jroll> rloo: not sure it matters
17:50:49 <lucasagomes> jroll, btw, how many days? 3 days?
17:50:50 <dtantsur> I'm out July 22-29
17:50:52 <thiagop> rloo: good question
17:51:01 <jroll> fwiw, I'd like to do it earlier and maybe have a second one late in the cycle :)
17:51:09 <jroll> lucasagomes: yeah, I think 3 days works
17:51:16 <jroll> but whatever y'all think is good
17:51:29 <jlvillal> June looks good for me. and early July.
17:51:39 <vdrok> same for me
17:51:39 <mariojv> ++ end of june
17:51:47 <jroll> btw, here's newton schedule http://releases.openstack.org/newton/schedule.html
17:51:47 <lucasagomes> 27-29 June
17:52:05 <jroll> lucasagomes: I won't be around that week :/
17:52:08 <rloo> didn't jroll mention that the week of june 27 is out?
17:52:10 <jlvillal> And I like the idea of trying to get in two of them. One soon and one later.
17:52:26 <rloo> is june 20 too soon?
17:52:27 <jroll> I guess we could do it that week, you all don't need me there :)
17:52:29 <lucasagomes> jroll, right, 20-22 maybe?
17:52:39 <jroll> yeah I'm good with the week of the 20th
17:52:40 <vdrok> and when is nova's midcycle?
17:52:41 <jlvillal> Maybe only two days for 2nd one.  Third day was sort of quiet last time.
17:52:43 <mariojv> 20th wfm too
17:52:52 <NobodyCam> I'll be out 21st as its my birthday
17:52:55 <jroll> vdrok: july 19-21
17:53:21 <rloo> july 11?
17:53:36 <mariojv> maybe a doodle would be good for this
17:53:37 <NobodyCam> 7/11 wfm
17:53:42 <mat128> mariojv: +1 for doodle
17:53:43 <jroll> yeah, planning on a doodle
17:53:49 <jroll> just wanted to hear initial ideas
17:54:11 <rloo> i think those two weeks are the candidates. june 20 & july 11. cuz i said so :D
17:54:17 <vdrok> jroll: just wondering as there is this generic resource pools, we might want to sync on this somehow with nova?
17:54:48 <rloo> vdrok: ++. but jroll will be at nova mid-cycle.
17:54:50 <jroll> vdrok: totally, I'll try to get jaypipes at our midcycle, I'll also be at nova's
17:55:10 <vdrok> cool, thanks :)
17:55:32 <rloo> it might almost be worth having a separate meeting *just* to discuss resource pools/etc.
17:55:36 <jroll> yeah
17:56:15 <rloo> like soon. in next 2 weeks or so. cuz i am guessing we will procrastinate and not look/think about it until we have to.
17:56:24 <jroll> yeah
17:56:32 <rloo> err. I mean, like after we get grenade working.
17:56:34 <jroll> to be clear I don't think there's even the nova spec up for that
17:56:43 <vdrok> jroll: there is
17:56:46 <jroll> but we should figure it out and get started on the ironic side
17:56:54 <rloo> you mean jay pipe's spec? there is.
17:57:06 <jroll> kinda, it's wip
17:57:08 <jroll> https://review.openstack.org/#/c/312696/
17:57:23 <jroll> oh, y'all are already reviewing, good
17:57:29 <rloo> yeah, that one.
17:58:01 <vdrok> also this one, knid of related - https://review.openstack.org/#/c/300176/
17:58:36 <rloo> vdrok: OH. I wondered if generic resource pools was already a thing or not.
17:58:39 <NobodyCam> *two minutes left*
17:58:47 <jroll> yeah, that's the earlier step in the chain
17:58:51 <vdrok> rloo: not yet :)
17:59:14 <rloo> vdrok: i didn't see anything in the first spec that mentions the second spec.
17:59:29 <rloo> this ain't going to be done in Newton.
17:59:49 <vdrok> rloo: there is only a name of bp somewhere in the spec itself
17:59:53 <jroll> probably not, but if we can all agree on the path, we can get whatever we need done on the ironic side
18:00:01 <rloo> jroll: exactly.
18:00:12 <vdrok> we can do search api anyway
18:00:25 <rloo> yup, i think search and claims API can still be done.
18:00:27 <jroll> well, it's unclear if we need a search api
18:00:29 <flwang1> hi guys
18:00:35 <jroll> oh, out of time
18:00:40 <rloo> search API is useful regardless, don't you htink?
18:00:44 <Eva-i> hello
18:00:45 <jroll> flwang1: we'll be in #openstack-ironic if you're looking for us
18:00:46 <jlvillal> time!
18:00:46 <rloo> although maybe not a high priority any more.
18:00:47 <jroll> #endmeeting