17:00:03 <dtantsur> #startmeeting ironic
17:00:04 <openstack> Meeting started Mon Apr 24 17:00:03 2017 UTC and is due to finish in 60 minutes.  The chair is dtantsur. 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:08 <openstack> The meeting name has been set to 'ironic'
17:00:58 <dtantsur> hi all!
17:01:02 <crushil> \o
17:01:16 <rloo> o/
17:01:17 <rama_y> o/
17:01:18 <jlvillal> o/
17:01:21 <rpioso> o/
17:01:33 <dtantsur> welcome to the most ironic meeting in OpenStack! :)
17:01:47 <dtantsur> our agenda can be found:
17:01:50 <dtantsur> #link https://wiki.openstack.org/wiki/Meetings/Ironic
17:02:16 * dtantsur waits for moar people a bit
17:02:40 <NobodyCam> o/
17:02:56 <dtantsur> #topic Announcements / Reminders
17:02:59 <sambetts> o/
17:03:12 <NobodyCam> small turnout today
17:03:19 <dtantsur> #info Virtual Meetup Tomorrow: https://etherpad.openstack.org/p/ironic-virtual-meetup
17:03:22 <dtantsur> NobodyCam++
17:03:33 <wanyen> o/
17:03:34 <dtantsur> 20 people signed in the meetup, this is great
17:03:50 <dtantsur> please do come :)
17:03:56 <dtantsur> any other announcements?
17:04:19 <NobodyCam> any thing for summit?
17:04:38 <dtantsur> TheJulia may know, I'm not going there (and honestly have not been paying attention too much)
17:04:42 <rloo> dtantsur: wrt the meetup, there is a list of topics. is there an agenda, or decided at the time?
17:04:43 <jlvillal> dtantsur: Is there any new emails about the midcycle?
17:04:53 <jlvillal> I guess reminders :)
17:04:59 <jlvillal> I see the one from 14-April
17:05:03 <dtantsur> rloo, more or less as we go
17:05:25 <dtantsur> jlvillal, that was the most recent. details in the etherpad.
17:05:34 <dtantsur> but good call
17:05:41 <dtantsur> #action dtantsur to send another reminder to the ML
17:06:35 <dtantsur> rloo, I thought about something similar to our PTG discussions: just go through the list of topics; review RFEs if there's time left
17:07:20 <dtantsur> anything else?
17:07:42 <dtantsur> #topic Review subteam status reports (capped at ten minutes)
17:07:54 <dtantsur> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:07:58 <dtantsur> starting with line 86
17:10:14 <rloo> vsaienk0: wrt L139, deploying w apache/wsgi. question there - are we done wirt ironic?
17:11:22 * dtantsur haven't seen Ukrainian folks today
17:11:42 <NobodyCam> holiday there?
17:12:04 <jlvillal> Not according to this: http://www.officeholidays.com/countries/ukraine/
17:12:36 <rloo> L210, routed networks support.
17:12:41 <NobodyCam> humm
17:12:57 <rloo> dtantsur: does that need a spec? or just approval?
17:13:15 <sambetts> rloo, dtantsur: IMO im not sure if it even needs an RFE
17:13:27 <NobodyCam> sambetts: ++
17:13:33 <dtantsur> how is it different from physnet awareness?
17:13:54 <sambetts> rloo, dtantsur: I dug into it further and the only changes *in ironic* we need are comming from the physnet awareness
17:14:02 <sambetts> the rest is neutron drivers
17:14:14 <dtantsur> sambetts, then maybe close as duplicate and roll this section into the previous one?
17:14:33 <mgoddard> sambetts: what about scheduling?
17:14:47 <mgoddard> physnet awareness isn't covering that
17:14:49 <sambetts> mgoddard: its handled by neutron -> nova communicated
17:14:53 <sambetts> mgoddard: its handled by neutron -> nova communication
17:15:21 <rloo> sambetts: is it already handled, or does someone need to add that neutron->nova connection?
17:15:53 <mgoddard> sambetts: really? how does nova avoid scheduling an instance to an ironic node not on a physnet of any of the segments?
17:15:57 <sambetts> rloo: we need to write an agent for neutron to feed it in, but that is going into networking-baremetal so not sure if that RFE shoud cover it
17:16:13 <rloo> sambetts: fair enough.
17:16:32 <rloo> sambetts: +1 to what dtantsur sez; we can sync up with vsaienk0 later to make sure he is in agreement
17:16:32 <dtantsur> well, depends on whether we have RFEs for networking-baremetal ;)
17:16:47 <sambetts> mgoddard: neutron creates magic aggregates in nova for you based on the information we feed in
17:17:19 <mgoddard> sambetts: oh, interesting. I guess that would work
17:17:20 <dtantsur> sambetts, mgoddard, could you please take the fate of this RFE as an action item? or we can move it to the open discussion
17:17:34 <dtantsur> we're a bit out of time for this section
17:17:45 <mgoddard> dtantsur: sure
17:17:48 <dtantsur> thnx!
17:17:51 <sambetts> I'm happy to continue discussion on the physnet awareness and that RFE page
17:17:54 <sambetts> :)
17:18:13 <dtantsur> anything else re statuses?
17:19:00 <dtantsur> #topic Deciding on priorities for the coming week
17:19:22 <dtantsur> we did not land much, did we? :(
17:19:52 <dtantsur> also, given the OSIC situation, I wonder if we should keep rescue on the priority list..
17:20:13 <rloo> dtantsur: we should remove rescue until we know who is going to continue working on it
17:20:53 <rloo> dtantsur: wrt existing 1.1 -- that patch is ready for reviews
17:21:06 <jlvillal> +1  I did a rebase, but not sure on what management will assign as my priorities yet.
17:21:14 <dtantsur> yes, this matches my thoughts
17:21:49 <rloo> dtantsur: given the meetup tomorrow, not sure how important it is to get these priorities 'right' this week
17:21:50 <aNuposic> I can take the tempest patch which Mario was trying to land, but not sure who is going to work on rest of the patches
17:22:30 <dtantsur> aNuposic, thanks!
17:22:42 <rloo> dtantsur: i updated priority 1 if we decide to keep it there
17:22:54 <jlvillal> Without the rest of the rescue patches, the tempest patch isn't much good though.
17:23:03 <dtantsur> rloo, thanks!
17:23:07 <aNuposic> jlvillal, +1
17:23:17 <rloo> i'm good with the existing 4 priorities.
17:23:22 <rloo> we can discuss rescue later
17:23:27 <dtantsur> yeah, or we can pick e.g. https://review.openstack.org/#/c/448661/
17:23:38 <jlvillal> Yeah, priorities look good to me.
17:23:47 <dtantsur> it was discussed to death already, so may be an easy win
17:23:54 <rloo> dtantsur: oh, that reminds me. sambett's ipa spec...
17:24:03 <dtantsur> hmm
17:24:11 <rloo> oh, and then speaking of specs, the etags spec
17:24:25 <dtantsur> etags is there already
17:24:29 <jlvillal> That's #3 ...
17:24:36 <rloo> oh yeah. sorry.
17:24:53 <dtantsur> and the CLI version spec has higher priority than the IPA spec (though I don't disagree with getting it first)
17:25:02 <rloo> dtantsur: maybe hold off on 448661 until we know who is going to shepherd it along?
17:25:20 <dtantsur> rloo, I will
17:25:36 * dtantsur makes a note
17:26:03 <rloo> dtantsur: ok, i'll look at it after you review it (again) then :)
17:26:27 <dtantsur> so, should we take it, assuming that I'll take care of it?
17:26:58 <rloo> dtantsur: we could. honestly, i don't know if i have time for that this week anyway. i mean, it doesn't hurt.
17:27:10 <rloo> dtantsur: lets just keep it to what we have.
17:27:29 <rloo> dtantsur: we didn't get much movement last week, adding another one probably won't help.
17:27:46 <dtantsur> ok, it's not urgent
17:27:53 <dtantsur> we can always take more patches from existing topics
17:28:03 <dtantsur> so, how are these 4 items looking?
17:28:39 * dtantsur will assume "yes"
17:28:45 <dtantsur> s/yes/good/
17:28:47 <rloo> yes :)
17:28:53 <dtantsur> Monday evening, sigh..
17:28:56 <rloo> err, good :)
17:29:02 <dtantsur> #topic Specs that are stuck on contentious items
17:29:07 <dtantsur> rloo, your turn
17:29:20 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1683777
17:29:22 <openstack> Launchpad bug 1683777 in Ironic "[RFE] Deprecate dhcp providers" [Wishlist,Triaged] - Assigned to Vasyl Saienko (vsaienko)
17:29:33 <rloo> just wanted a quick yay or nay on this.
17:29:42 <rloo> vsaienk0 already posted a patch but the rfe wasn't approved
17:29:51 <rloo> are we good with deprecating dhcp providers?
17:29:53 <dtantsur> +1 for rfe-approved, and I see vdrok +1 too
17:30:05 <rloo> and/or should we post email to list to check first?
17:30:12 <rloo> I'm +1 for it.
17:30:54 <rloo> (I'm not sure that anyone has written their own dhcp driver)
17:30:59 <dtantsur> dunno re emails, they usually don't get a lot of attention..
17:31:03 <dtantsur> me neither
17:31:17 <rloo> ok then. lets approve it.
17:31:20 <dtantsur> ++
17:31:26 <rloo> thx :)
17:31:41 <dtantsur> #topic Future of the deploy methods
17:31:52 <dtantsur> food for thoughts mostly, no need to decide right here and now
17:32:03 <dtantsur> 1. Should we deprecate the iSCSI method? E.g. HPE folks do not want to support it in their hardware type.
17:32:28 <sambetts> dtantsur: please no, currently the agent method requires swift
17:32:36 <dtantsur> sambetts, it can use any http, no?
17:32:46 <sambetts> dtantsur: not in openstack with glance
17:32:52 <mgoddard> what sambetts said
17:33:42 <sambetts> unless we start serving http images from the ironic conductor (which I think there is an RFE for) then I don't think we can kill iscsi
17:33:42 <mgoddard> glance won't work without swift due to authentication, right?
17:33:43 <dtantsur> sambetts, it may be a reason to talk to iLO folks then, as they don't plan on adding "iscsi" method to their new hardware type
17:34:09 <dtantsur> generally, I'd prefer drivers to not diverge too much in terms of deploy methods
17:34:39 <wanyen> iscsi-ilo driver has dependency on swit as well.
17:34:43 <sambetts> surely iscsi vs agent deploy shouldn't matter WRT differnt hardware
17:34:48 <wanyen> swit/swift
17:35:02 <rloo> so i think it is hp's decision whether to support iscsi or not.
17:35:25 <dtantsur> rloo, more or less. I'm thinking about the consequences for us.
17:35:37 <rloo> dtantsur: oh, what are the consequences?
17:35:37 <wanyen> for ilo driver, agent-ilo and iscsi-ilo have the same capability and same dpendencies.
17:35:42 <dtantsur> like, currently we have pxe_ilo that does not require swift
17:35:50 <sambetts> plus anyone outside of HP could push for iscsi on HP right? its not locked down to only being contributed to by HP people right?
17:36:01 <sambetts> wanyen: perhaps you can help us understand why that is the case?
17:36:11 <sambetts> wanyen: normal iscsi doesn't have that requirement
17:36:11 <dtantsur> sambetts, it requires 3rdparty CI support, so it needs buy-in from a vendor
17:36:26 <rloo> sambetts: yes, shiv indicated (and there is a comment in the code) that if there were asks, they would be amenible to supporting it.
17:36:38 <wanyen> we upload the vfat file to swift for both iscsi and agent ilo dirvers
17:37:47 <rloo> dtantsur: we're talking about this, L52: https://review.openstack.org/#/c/439404/11/ironic/drivers/ilo.py ?
17:38:13 <wanyen> so for ilo driver agent-ilo and iscsi-ilo are pretty much the same except agent-ilo download image from bare metal and iscsi ilo copy it from conductor.  we have pxe-ilo that has no dependency on swift
17:38:36 <dtantsur> rloo, well, this comment is not correct. iscsi deploy + pxe boot do not require swift..
17:39:24 <rloo> dtantsur: from my perspective, it seems to be up to HP to support it or not, and if their comment isn't correct, it is their customers...
17:39:40 <dtantsur> I agree with the first part, but not with the second part
17:40:03 <dtantsur> ironic is our shared responsibility, so if not swift is a strict dependency of ilo drivers - we have to be clear about it.
17:40:04 <rloo> dtantsur: ok, the second part is easily addressed by updating the comment.
17:40:21 <dtantsur> but this topic is NOT about forcing HPE into supporting iscsi :)
17:40:36 <dtantsur> I was just asking around for use cases for iscsi, and it seems like we have them
17:41:07 <wanyen> we like to know who is using iscsi-ilo?  most the customers we know are either using pxe-ilo or agent-ilo.
17:41:13 <sambetts> if we could support serving images via HTTP from the conductor then I'd be happy to deprecate iscsi
17:41:22 <rloo> dtantsur: i thought you wanted to deprecate iscsi cuz hp wasn't going to support it. so yeah, there are others that want it.
17:41:37 <dtantsur> rloo, no, hp just made me think about it
17:41:44 <rloo> dtantsur: ah, gotcha.
17:42:01 <dtantsur> another thing I was going to bring (again, just a random idea): Instead of iSCSI, maybe bring in the Ansible one? It seems in good shape, has a CI now.
17:42:19 <dtantsur> ofc it has a dependency on ansible :)
17:42:31 <wanyen> by the way, iscsi-ilo will still be there.  It's just that we don't do new hardware type for iscsi for the time being.  If there are demands from users, we will consider adding it.
17:42:37 <rloo> dtantsur: you mean the ansible driver? there was/is a spec for that, right?
17:42:54 <dtantsur> #link http://ironic-staging-drivers.readthedocs.io/en/latest/drivers/ansible.html
17:43:13 <rloo> dtantsur: yeah, so i think the spec is still there. just needs reviews/approval?
17:43:17 <dtantsur> wanyen, we're mostly talking about pxe_ilo, which is not going to be supported by the new iLO hardware type
17:43:33 <sambetts> dtantsur, rloo: https://bugs.launchpad.net/ironic/+bug/1598852 and https://bugs.launchpad.net/ironic/+bug/1526241 would help us towards the possiblity of deprecating iscsi
17:43:35 <openstack> Launchpad bug 1598852 in Ironic "[RFE] Provide Agent HTTP provisioning without swift + tempurls" [Wishlist,Confirmed]
17:43:36 <openstack> Launchpad bug 1526241 in Ironic "[RFE] Support all glance backends in the agent" [Wishlist,Confirmed]
17:44:10 <rloo> sambetts: thx, i thought there were rfe's for that :)
17:44:24 <rloo> sambetts: I think it is a grand idea.
17:44:31 <rloo> sambetts: i think we have a lot on our plate.
17:44:53 <wanyen> dtantsur:  that's news to me that pxe-ilo is not going to be supported by new ilo hardware type.
17:45:28 <dtantsur> oh, I see
17:45:42 <dtantsur> sambetts, I'm more in favor of https://bugs.launchpad.net/ironic/+bug/1598852, seems simpler
17:45:43 <openstack> Launchpad bug 1598852 in Ironic "[RFE] Provide Agent HTTP provisioning without swift + tempurls" [Wishlist,Confirmed]
17:46:30 <sambetts> dtantsur: I agree, its seems like we could implement that relativly quickly, we're already running a HTTP server for iPXE
17:46:50 <dtantsur> sambetts, do we have a spec for that?
17:47:08 <rloo> wanyen: this is the pxe-ilo driver i think: https://github.com/openstack/ironic/blob/485a3315d77d8ee8cb29a8b5d787ba248c969c10/ironic/drivers/pxe.py#L97
17:47:21 <sambetts> dtantsur: not yet, I can put together a straight forward one tomorrow morning
17:47:27 <rloo> wanyen: the patch for ilo hardware type, does not support iscsi_deploy.ISCSIDeploy()
17:47:45 <dtantsur> sambetts, thanks! it's something I'd keep on our backlog
17:47:48 <rloo> wanyen: so how will the new ilo hardware type support it?
17:48:37 * rloo not sure she wants to spend meetup talking about future things that are not high priority, given what we need/want to get done this cycle
17:49:05 <dtantsur> rloo, which item are you referring to?
17:49:05 <sambetts> dtantsur: cool!
17:49:17 <NobodyCam> I hope it won't break existing folks that use it
17:49:19 <wanyen> rloo:  I need to ask teh team.  My intent is to support new hardware type equivalent to pxe-ilo and iscsi-ilo.  The virtual media deploy has dependency on swift but pxe deploy doesn't.
17:49:26 <rloo> dtantsur: what you & sambetts were discussing above
17:49:41 <rloo> wanyen: thx for asking your team
17:49:55 <dtantsur> rloo, I did not suggest it for the meetup, just for future work
17:50:20 <rloo> dtantsur: thx for clarifying; wasn't clear to me.
17:50:31 <dtantsur> np, sorry for confusion
17:50:40 <dtantsur> so, quick poll: wdyt of eventually bringing the ansible deploy method in?
17:51:06 <rloo> i think it is a good idea. would need to look at the details.
17:51:07 <NobodyCam> thats exactly what staging driver was meant for so I am ++
17:51:43 <jlvillal> 'eventually' sounds like it is reasonable.
17:51:55 * rloo would like to eventually get everything in :D
17:51:58 <dtantsur> heh :)
17:52:01 <jlvillal> But I personally haven't dug into the details.
17:52:16 <dtantsur> well, moving an already existing driver is a bit easier than writing one from scratch
17:52:23 <dtantsur> anyway, thanks for feedback! that's all I had
17:52:32 <dtantsur> #topic Open discussion
17:52:39 <dtantsur> 7.5 minutes :)
17:53:28 <dtantsur> any desire to discuss the routed networks vs physnet awareness?
17:53:44 <rloo> i'm concerned about the potential loss of ironic contributors. but maybe this isn't the time/place to discuss.
17:54:05 <wanyen> rloo: I believe that pxe-ilo does have dependency on iscsi so please don't deprecate iscsi deploy.  For ilo virtual media drivers, agent-ilo and iscsi-ilo they both have the same functionalities and same dependencies, so that's why we are thinking just to make new hardware type for agent-ilo equivalent.
17:54:29 <rloo> wanyen: i think we decided that we aren't deprecating iscsi. at least not in the near future.
17:54:31 <dtantsur> rloo, the impact is still unclear, at least to me..
17:54:44 <sambetts> mgoddard: any progress on the physnet awareness?
17:55:13 <rloo> dtantsur: yeah, i know. that's why maybe now isn't a good time to discuss. there's not much we can do. just wondering if we might need to reprioritize or rethink our processes but i guess it'll happen.
17:55:45 <dtantsur> we will most certainly need to reprioritize, yeah
17:55:46 <mgoddard> sambetts: not yet. I've had my head down on a customer deployment for the past few weeks. I should have some time to make a start in the next week or so
17:56:15 <rloo> eg, fewer people == can we be more effective. something we can mull over i guess.
17:56:16 <xavierr> hey, I was trying to deploy a machine using multi-tenancy feature. I saw that there is a bug when changing from provision net to tenant as described in https://bugs.launchpad.net/nova/+bug/1599836
17:56:17 <openstack> Launchpad bug 1599836 in OpenStack Compute (nova) "Booting Ironic instance, neutron port remains in DOWN state" [Medium,Confirmed]
17:56:37 <sambetts> mgoddard: cool, I need that work to start putting together the patches for the routed networks logic
17:56:37 <wanyen> rloo: I believe pxe-ilo has dependency on ISCSIDeploy so please do not deprecate ISCSIDeploy.  For ilo vmedia drivers (agent-ilo & iscsi-ilo), they both have dependnecy on swit and have the same functionalities, so we are support new hardware type for agent-ilo equivalent for now.
17:57:03 <xavierr> do we have any fix for it? ^^^
17:57:30 <xavierr> the message is 'cannot update to ACTIVE because it is not bound'
17:57:33 <mgoddard> sambetts: is there a subset of it that would be useful to you that I should focus on?
17:58:18 <xavierr> vsaienk0 has registered that bug, I tried talk to him but he seems unavailable :(
17:58:24 <sambetts> mgoddard: main thing is the data model, and exposing  the fields in the API so that I can start storing the data and reading it out
17:58:25 <mgoddard> sambetts: perhaps just getting the port objects updated with the new attribute?
17:59:01 <mgoddard> sambetts: sure. I'll focus on that to begin with then. How hard can it be? ;)
17:59:15 <dtantsur> 1 minute alert
17:59:17 <NobodyCam> one minute
17:59:19 <NobodyCam> lol!
17:59:21 <dtantsur> :)
17:59:29 <xavierr> :(
17:59:40 <dtantsur> xavierr, all Ukrainian folks seem out today, maybe try tomorrow?
17:59:53 <dtantsur> and thanks everyone!
17:59:59 <NobodyCam> :)
18:00:00 <dtantsur> #endmeeting ironic