17:00:03 <jroll> #startmeeting ironic
17:00:03 <openstack> Meeting started Mon Jan 16 17:00:03 2017 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:05 <TheJulia> o/
17:00:07 <dtantsur> o/
17:00:07 <openstack> The meeting name has been set to 'ironic'
17:00:08 <mjturek> \o
17:00:10 <vdrok> o/
17:00:10 <jroll> hey y'all
17:00:11 <mariojv> o/
17:00:12 <Michael-zte2> o/
17:00:17 <zhenguo> o/
17:00:18 <jroll> as always, agenda is here:
17:00:20 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:00:22 <rpioso> o/
17:00:31 <lucasagomes> o/
17:00:55 <jroll> #topic announcements and reminders
17:00:59 <rloo> o/
17:01:04 <jroll> #info non-client library freeze is this week
17:01:12 <jroll> #info client library freeze is next week
17:01:27 <jroll> #link https://releases.openstack.org/ocata/schedule.html
17:01:31 <jroll> ^ is ocata schedule
17:02:02 <jroll> anything else here?
17:02:16 <krtaylor> o/
17:02:39 <mgould> o/
17:02:53 <dtantsur> are we done with ironic-lib?
17:03:05 <rloo> jroll: nova 'feature' freeze is ...
17:03:07 <jroll> there's nothing ready to go in the queue
17:03:14 <galyna> o/
17:03:15 <jroll> and I don't think we have anything planned
17:03:16 <rloo> jroll: next week?
17:03:19 <dtantsur> so we are, cool :)
17:03:24 <jroll> rloo: yes, next week
17:03:44 <jroll> sorry, forgot to mention that
17:03:45 <galyna> Sorry. just one question. How about etag spec? :)
17:04:01 <jroll> that means anything that needs nova patches needs to get in asap
17:04:06 <milan> o/
17:04:13 <jroll> galyna: please wait for open discussion :)
17:04:20 <dtantsur> what pressing features do we need landed in nova? do we have a list?
17:04:30 <dtantsur> we can at least provide our reviews/+1s
17:04:33 <rloo> jroll: sorry, one more reminded. when are we targetting ocata release, Jan 30 week?
17:04:49 <jroll> dtantsur: attach/detach, portgroups, soft poweroff/reboot
17:04:57 <dtantsur> k
17:05:01 <galyna> jroll: sorry)
17:05:14 <jroll> rloo: I'm not sure yet, feb13 week is deadline
17:05:31 * rloo prefers week of feb 13 :)
17:05:41 <dtantsur> we have one outstanding review against ironic-inspector-client, which has to go in before next week. <-- bfournie FYI
17:05:49 <rloo> ugh, which is week before ptg...
17:05:53 <vdrok> dtantsur: https://review.openstack.org/364413 https://review.openstack.org/388756 and https://review.openstack.org/#/q/topic:bp/soft-reboot-poweroff
17:05:59 <jroll> rloo: indeed :)
17:06:03 <dtantsur> vdrok, thanks
17:06:27 * rloo was hoping for a break...
17:06:34 <jroll> any other announcements/reminders?
17:06:42 <jroll> rloo: feb27 week :P
17:06:50 <dtantsur> jroll, do we plan on another ironicclient release?
17:06:57 <dtantsur> otherwise we can't land Nova bits of sort power on/off
17:07:04 <jroll> dtantsur: if we have code to release, yes
17:07:06 <rloo> dtantsur: yup, if we can get power on/off
17:07:36 <rloo> dtantsur: lets discuss that in subteams/priorities of the week
17:07:57 <jroll> #topic subteam status reports
17:08:03 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:08:10 <jroll> starts at line 101
17:08:22 <jroll> got lots done last week, it seems \o/
17:09:00 <rloo> sambetts, vdrok: wrt portgroups, there isn't any client release needed still?
17:09:20 <vdrok> rloo: it was done, the attach/detach addition
17:09:33 <dtantsur> line 134 still says it's needed
17:09:34 <rloo> vdrok: that's what i thought. will update...
17:09:34 <vdrok> as it was a prerequisite for portgroups metadata stuff
17:10:32 <jroll> I don't think our priorities change much - wondering if I'm missing anything obvious there
17:10:57 <jroll> would be nice to get rescue stuff done too, on the ironic side, but lots of code
17:11:27 <rloo> TheJulia: wrt boot from volume. if we don't get the client side done in ocata, do we still want to get the REST api done?
17:12:07 <TheJulia> I think we ought to, but I think we can take our time, i.e. not a super high priority at the moment.  Ideally we should want to be ready to merge at the beginning of pike
17:12:09 <rloo> dtantsur, jroll: wrt driver composition. is that updated? it has 'next steps... as of 9 Jan..'
17:12:19 <dtantsur> rloo, the same status, just more patches on review
17:12:25 <jroll> ^
17:12:32 <rloo> dtantsur: ok, so status as of today
17:12:38 <rloo> dtantsur: thx :)
17:12:57 * dtantsur cleaned up it a bit
17:13:21 <rloo> unless we get a lot more folks reviewing, i don't see how we can get rescue + composition + upgrades + ... done in Ocata :-(
17:13:44 * vdrok added a link to nova patches in soft power states section
17:14:00 <rloo> who's the 'lead' for ironic-ui?
17:14:30 <jroll> rloo: right, I'm fine with rescue dropping off, I think we can finish driver composition and upgrades if we go hard on it
17:14:33 <TheJulia> rloo: technically betherly, although she has been focusing on other things as of recent so ppiela  has been largely contirbuting
17:14:53 <TheJulia> rloo: I updated the whiteboard for them since co-ordinating seems difficult :)
17:15:03 <rloo> TheJulia: so should we/I put ppiela down? or you?
17:15:29 <TheJulia> rloo: both most likely
17:15:51 <rloo> TheJulia: ok
17:16:07 <rloo> so wrt priorities (not that we're going to get there, I'd say rolling upgrades is higher priority than boot from volume
17:16:19 <rloo> otherwise, the priorities look good to me.
17:16:27 <jroll> mmm, good point
17:16:36 <vdrok> most of the patches on composition don't look that complex (have not started with api patches yet tho)
17:16:50 <TheJulia> rloo: agreed
17:16:52 <jroll> vdrok: that was my goal :)
17:17:04 <jroll> it's complex to figure out but I tried to make the patches easy to review
17:17:19 <dtantsur> ++ for "complex to figure out"
17:17:48 * TheJulia wonder how to convert ++ into a very large number
17:18:32 * milan suggests inf++ :D
17:18:34 <jroll> '++'*math.inf
17:18:50 <jroll> ok any other questions/comments here?
17:18:50 <mat128> o/
17:19:06 <jroll> welcome mat128 :)
17:19:21 <mat128> (missed it last week, late this week, next week should be on time :)
17:19:28 <jroll> heh
17:19:35 <jroll> no other topics, so....
17:19:38 <jroll> #topic open discussion
17:19:47 <jroll> galyna has a thing
17:20:20 <jroll> anyone else have a thing?
17:20:29 <TheJulia> I have a thing to inquire about
17:20:31 <galyna> Thank, jroll :) I would like to discuss some thing in the spec https://review.openstack.org/#/c/381991/
17:20:38 <Michael-zte2> Is there a way to specify a conductor?
17:20:55 <jroll> galyna: what would you like to discuss?
17:20:59 <lucasagomes> Michael-zte2, what you mean ?
17:21:06 <vdrok> Michael-zte2: like, place this node on this conductor? No
17:21:11 <galyna> The main question is abpout etag storing on ironiclient. sould it be sth like a filecache? There are several ideas
17:21:49 <Michael-zte2> <lucasagomes> : When there are many conductor, can I specify which conductor to use?
17:21:50 <rloo> galyna: remind me, why do we want to store etags in client?
17:22:00 <lucasagomes> Michael-zte2, so Ironic does assign nodes to conductors dynamically using the hash ring, so there's no way to actually force it
17:22:03 <jroll> tis a great question, I've always wondered if this would be useful in a CLI (rather than just in the api)
17:22:04 <lucasagomes> Michael-zte2, unfortunately no
17:22:16 <TheJulia> galyna: in memory perhaps for api client users, but for CLI maybe not?
17:22:23 <galyna> The thing is when a user does update, he needs to have some etag. This was in the first version of Devananda spec, that there should be some cache
17:22:48 <Michael-zte2> <lucasagomes>  :what a pity
17:22:49 <galyna> Another choice is to send GET before update.
17:23:05 <jroll> Michael-zte2: what's the use case?
17:23:22 <jroll> galyna: I don't like that, the eatg we send for an update should be based on what the user saw
17:23:32 <galyna> but this is the thing which I am not sure in. Is it reliable?
17:23:32 <galyna> Or how to pass etag string to pass validation?
17:23:42 <lucasagomes> Michael-zte2, maybe it can be proposed somehow by a spec... but so far, this is part of the "ha model" for conductors to allow nodes to join/leave the cluster dynamically
17:24:04 <vdrok> jroll: if it's client side cache, and etag is in cache, we can assume the user saw that
17:24:06 <galyna> Yes. He should. So a user need to send etag manyally?
17:24:16 <galyna> *manually
17:24:17 <TheJulia> Michael-zte2: or perhaps a geographic awareness model of some sort.
17:24:25 <jroll> vdrok: I mean the GET before update option
17:24:43 <Michael-zte2> <jroll> : We try to specify a specific conductor, to partially solve the problem of different vlan
17:25:09 <lucasagomes> TheJulia, ++ this is actually something that I've seem users wanting in the past (specially for use cases like hadoop)
17:25:11 <vdrok> ah, right
17:25:29 <TheJulia> Michael-zte2: Perhaps you should detail that out in a specification so we can better understand what your use case is and how your using ironic.
17:25:31 <jroll> Michael-zte2: oh, so you have different management VLANs for different groups of servers, yes?
17:25:33 <jroll> TheJulia: ++
17:25:43 <TheJulia> lucasagomes: we've only ben discussing it sporadically for a long time.
17:25:52 <lucasagomes> true
17:25:59 <jroll> galyna: I'm not sure I have a good option for you, I don't know how to make that a good UI
17:26:11 * milan wonders isn't a GET before UPDATE just a sloppy cache? ;)
17:26:29 <galyna> jroll: Thanks anyway)
17:26:35 <TheJulia> milan: well, you need to know the starting state....
17:26:40 <jroll> ^ if anyone does, please comment on the etags spec
17:26:45 <Michael-zte2> <vdrok> : I read the code, as if the code does not provide a way to specify
17:26:59 <jroll> TheJulia: what was your thing?
17:27:16 <Michael-zte2> <jroll> : yes
17:27:23 <galyna> I just want to ensure that I am going in right ways. I will have several choices then.
17:27:37 <TheJulia> So I have a question regarding python-ironicclient.  I noticed an RFE https://bugs.launchpad.net/python-ironicclient/+bug/1627445 to add i18n, but noticed no real traction.  It feels like we should move forward on this, but I dunno.
17:27:37 <openstack> Launchpad bug 1627445 in python-ironicclient "[RFE] i18n support for ironic client" [Wishlist,In progress] - Assigned to jiang wei (timjiang)
17:27:56 <Michael-zte2> <jroll> : We try to solve the problem of multi-vlan
17:28:04 <jroll> Michael-zte2: so for now I would recommend that you connect your conductors to all management VLANs, but if you have ideas how to make that work a spec would be great :)
17:28:20 <rloo> TheJulia: so it has been approved. what are you suggesting?
17:28:23 <Michael-zte2> <jroll> : Has not been successful
17:28:24 <vdrok> Michael-zte2: yes, that's correct. Unless you are able to specify the node hosts in a way nodes get mapped to conductors as you want :)
17:28:28 <TheJulia> I guess from my pov, I wouldn't want to block anything over lacking i18n in the client, but I've seen it on a few reviews now from contributors who are not native english speakers
17:28:43 <jroll> TheJulia: I don't see why we shouldn't, maybe that should be a priority for pike of some sort
17:28:44 <lucasagomes> TheJulia, we should probably leave a comment in the RFE asking the assginee if he/she is working on it
17:28:47 <TheJulia> rloo: we just go-ahead and spend a couple days and get it done at some point in the near future.
17:29:07 <jroll> TheJulia: ++
17:29:13 <rloo> TheJulia: ah, ok. I think that is very doable, but I don't know that it is a high priority for ocata. Is it?
17:29:21 <TheJulia> near future at this point likely being the next cycle :)
17:29:33 <lucasagomes> rloo, for ocata it doesn't seem feasible
17:29:44 <rloo> there's the i18n'able, and then there's actual xlations...
17:29:52 * jroll reiterates, maybe that should be a priority for pike
17:29:57 <TheJulia> ++
17:30:00 <Michael-zte2> <lucasagomes> : yes, thank you for your suggestion
17:30:13 <TheJulia> Okay, I think we seem to have a consensus, just not a now thing
17:30:18 <rloo> agree as a priority for pike. do we have an etherpad for pike besides the ptg stuff?
17:30:24 <jroll> not yet, no
17:30:32 <vdrok> similar question on node tags, these have been up for a while
17:30:43 <vdrok> maybe prioritize them at the end of cycle
17:30:55 <rloo> vdrok: i had thought we could get node tags done in ocata. just too much other stuff to review so far :-(
17:30:59 <lucasagomes> rloo, maybe add it to the PTG etherpad ? So we can talk about prioritizing it there ?
17:31:09 <TheJulia> I'll add it to the ptg etherpad
17:31:15 <sambetts> Michael-zte2: one possiblity to make it work now, might be to have sparate ironics and nova-computes for your different management zones, but I've not tried it before
17:31:19 <rloo> lucasagomes: ++ to ptg etherpad. at least for now so we don't lose it. i can do it after this meeting.
17:31:26 <jroll> yeah, +1
17:31:32 <rloo> oh, just saw TheJulia volunteer, thx!
17:31:49 <vsaienk0> Michael-zte2: what do you mean "We try to solve the problem of multi-vlan"?
17:33:05 <rloo> Seems like it would be good to have Michael-zte2 or someone write a spec with use case etc. Cuz how do we deal with ha and a conductor going down if you specify which conductor. it doesn't seem that simple.
17:33:57 <TheJulia> I suspect there are several use cases that may be solved by the same spec
17:34:06 <Michael-zte2> <jroll> <vsaienk0>: We have a need to deploy BM in different Vlans. We are working on it these days. But we can not find a solution yet
17:34:08 <rloo> TheJulia: even better!
17:34:34 <sambetts> Michael-zte2: have you seem our multitenency support as of Newton?
17:34:47 <sambetts> Michael-zte2: http://docs.openstack.org/developer/ironic/deploy/multitenancy.html
17:34:51 <vsaienk0> Michael-zte2:  so you are looking for ability to specify deploy network per node?
17:35:04 <TheJulia> Michael-zte2: or are your requirements dedicated conductors per vlan deployments?
17:36:05 * rloo wonders whether we should take this discussion outside this meeting
17:36:19 <jroll> I think we should
17:36:20 <TheJulia> ++
17:36:28 <Michael-zte2> <sambetts> : I'm following the ironic-neutron meeting
17:36:29 <TheJulia> Michael-zte2: Lets discuss this in #openstack-ironic
17:36:34 <vsaienk0> rloo: yeah, we need a spec to understand particular use case
17:36:48 <Michael-zte2> <vsaienk0> : something like that
17:36:51 * jroll notes the ironic-neutron meeting is no longer being held
17:37:11 <jroll> ok, anything else for this meeting?
17:37:24 <Michael-zte2> <TheJulia> : ok
17:37:39 * jroll waits a moment
17:37:44 <TheJulia> I have nothing :)
17:37:59 <vdrok> thanks everyone :)
17:38:05 <rloo> crickets chirping...
17:38:07 <Michael-zte2> good Bye
17:38:09 <jroll> cool, 20-odd minutes of extra reviewing
17:38:11 <jroll> #endmeeting