17:00:00 <dtantsur> #startmeeting ironic
17:00:01 <openstack> Meeting started Mon Apr  3 17:00:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:03 <NobodyCam> o/
17:00:05 <openstack> The meeting name has been set to 'ironic'
17:00:06 <aarefiev> o/
17:00:07 <mariojv> o/
17:00:10 <stendulker> o/
17:00:11 <TheJulia> o/
17:00:18 <vdrok> o/
17:00:19 <rpioso> o/
17:00:28 <crushil> \o
17:00:31 <jroll> \o
17:00:36 <rama_y> o/
17:00:41 <soliosg> o/
17:00:55 <dtantsur> hi everyone, thanks for joining :)
17:01:07 <dtantsur> as usual, our agenda (relatively light today), can be found at:
17:01:09 <rloo> o/
17:01:10 <vgadiraj_> o/
17:01:12 <alezil> o/
17:01:14 <joanna> o/
17:01:15 <dtantsur> #link https://wiki.openstack.org/wiki/Meetings/Ironic
17:01:21 <mgoddard> o/
17:01:39 <dtantsur> #topic Announcements / Reminders
17:01:52 <dtantsur> #info dtantsur had some good time in Barcelona during his PTO :)
17:01:59 <dtantsur> nothing else from me, really :)
17:02:17 <mgoddard> A couple of quick announcements from me.
17:02:20 <mgoddard> 1. We've just open sourced a project based on kolla for deployment of OpenStack with a focus on baremetal for the scientific computing use case. https://github.com/stackhpc/kayobe. Please get in touch if you're interested in finding out more.
17:02:36 <mgoddard> 2. In the above project we're doing some interesting things with ironic inspector with the aim of reaching 'zero touch' commissioning of a bare metal cloud. Blog post about it here: https://www.stackhpc.com/ironic-idrac-ztp.html.
17:02:43 <dtantsur> #link https://github.com/stackhpc/kayobe a project based on kolla for deployment of OpenStack with a focus on baremetal for the scientific computing use case
17:02:49 <yuriyz|2> o/
17:03:04 <Nisha_Agarwal> o/
17:03:11 <rloo> we did a few releases last week
17:03:18 <dtantsur> #link https://www.stackhpc.com/ironic-idrac-ztp.html Zero-Touch Provisioning using Ironic Inspector and Dell iDRAC by mgoddard
17:03:23 <dtantsur> rloo, indeed!
17:03:25 <TheJulia> One announcement from me: I'll be at the leadership training event next week, and on vacation the following week, so I'll be somewhat unavailable.  I'll likely need someone to volunteer to run the UI and BFV meetings, or otherwise cancel them.
17:03:31 <dtantsur> #info first round of Pike releases done last week
17:04:26 <dtantsur> TheJulia, the UI one is 8pm for me, but I can run the BFV. it does conflict with the api-wg meeting though..
17:04:59 <joanna> I can run BFV, I'm there anyway
17:05:08 <dtantsur> joanna, thanks!
17:05:21 <joanna> :)
17:05:22 <dtantsur> #action joanna to run the next BFV subteam meeting
17:05:22 * jroll notes that he has a bunch of downstream things going on this week, and also at leadership training next week, so mostly out for two weeks but I'll be around irc if people need a thing
17:05:40 <dtantsur> do we have someone to run the UI meeting?
17:05:59 <TheJulia> I can just cancel the UI meeting, I think it will be fine for a week.
17:06:00 <jroll> additional info on releases: everything else is done, but the ironic release is waiting on a couple of patches: https://review.openstack.org/#/c/452806/ https://review.openstack.org/#/c/452787/
17:06:04 <crushil> I don't have much experience, but I can try because I am going to be there anyways
17:06:14 <rajinir> o/
17:06:25 <TheJulia> crushil: it is easy, I can give you a run down this week :)
17:06:33 <crushil> TheJulia, Thanks
17:06:37 <dtantsur> thanks crushil!
17:06:41 <crushil> np
17:06:44 <TheJulia> crushil: thank you!
17:06:46 <dtantsur> #action crushil to run the next UI subteam meeting
17:07:00 <dtantsur> oh, I guess it's not "the next"..
17:07:18 * dtantsur wonders if he should #undo that actions, or it's clear enough..
17:07:19 <TheJulia> Week after, I'm sure I'll be on some next week.
17:07:45 * TheJulia thinks undo and then note it again
17:07:52 <dtantsur> #undo
17:07:53 <openstack> Removing item from minutes: #action crushil to run the next UI subteam meeting
17:07:56 <dtantsur> #undo
17:07:57 <openstack> Removing item from minutes: #action joanna to run the next BFV subteam meeting
17:08:13 <dtantsur> #action joanna to run the BFV meeting next week
17:08:15 <dtantsur> better?
17:08:27 <jroll> ++
17:08:37 <dtantsur> #action crushil to run the UI subteam meeting next week
17:08:39 <TheJulia> Yeah I guess
17:08:52 <dtantsur> cool :) anything else from folks?
17:09:25 <dtantsur> #topic Review subteam status reports
17:09:29 <xavierr> o/
17:09:38 <dtantsur> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:09:42 <dtantsur> starting with line 87
17:11:20 <rloo> dtantsur: as a side note, did you decide wrt trello?
17:11:34 <rloo> dtantsur: thinking we should delete the trello links
17:11:53 <dtantsur> rloo, nope, we can have a voting later :) /me knows folks like voting
17:12:09 * rloo likes votes, reminder of how democracy could work
17:12:22 <rloo> so the physical network stuff, that spec merged last week, didn't it?
17:12:27 <rloo> L196
17:13:07 <rloo> JayF, TheJulia: wrt documentation reorg, it is April. L207.
17:13:08 <dtantsur> #link http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/physical-network-awareness.html
17:13:11 <jroll> rloo: it did
17:13:37 <TheJulia> rloo: Good point, I've been waiting on a spec, but I've not seen it yet.
17:13:47 <rloo> folks, please remember to update the status's :)
17:14:34 <mgoddard> rloo: my bad
17:14:34 * rloo updates status' with guesses :)
17:14:50 <TheJulia> heh
17:14:54 * TheJulia liked the ORLY
17:15:03 <jroll> :D
17:15:38 <dtantsur> rpioso, hey! do you plan on creating a new-style hardware type for Drac or should one of us (one of me?) write it?
17:16:47 <rloo> wrt the oslo note (L276). anyone want to volunteer to look into any impact on ironic?
17:17:14 * rloo wonders how many dtantsurs there are
17:17:35 <rpioso> dtantur: Welcome back!
17:17:38 <dtantsur> rloo, I am qualitative, not quantitative! :)
17:17:41 <dtantsur> rpioso, thanks!
17:17:45 <jroll> the oslo thing should be easy, just stare at logs for warnings :)
17:18:01 <rloo> jroll: we need a starer!
17:18:13 <dtantsur> or we can proactively switch that flag to true
17:18:14 <jroll> I'd rather not take that task but can if we get no volunteers
17:18:15 <TheJulia> Why not automate that?
17:18:16 * TheJulia ducsk
17:18:18 <TheJulia> ducks
17:18:44 <jroll> curl $logfile | grep 'the warning'
17:18:44 <TheJulia> It actually should be easy, pull down the library, merge, manually install with pip, restart
17:18:46 <rloo> jroll: would be nice if a noncore takes that on.
17:18:52 <jroll> rloo: indeed
17:18:52 <rpioso> dtantsur: Please elaborate.
17:19:07 <rloo> jroll: we could file a bug, 'low hanging fruit'?
17:19:13 <TheJulia> +1 to bug
17:19:30 <rloo> ok, /me files a bug then :)
17:19:32 <jroll> TheJulia: even easier, we only use it in unit tests
17:19:33 <rpioso> dtantsur: We could discuss outside of this meeting.
17:19:34 * jroll may jfdi
17:19:44 <dtantsur> rpioso, yep, let's do it. not really urgent.
17:20:02 <rpioso> dtantsur: Cool!  ty
17:22:04 <dtantsur> we're past 10 minutes cap for the review. are folks still reviewing?
17:22:08 <vdrok> seems like time to move on :)
17:22:32 <dtantsur> #topic Deciding on priorities for the coming week
17:22:44 <rloo> i'm done with subteam reports. but leading to next stuff. there are some deadlines coming up, next week: glance, manila, nova spec freeze
17:22:56 <rloo> does that impact us, are there things we ought to look at soon?
17:23:11 <jroll> I can check on our nova work this week
17:23:12 <dtantsur> do we need nova specs for any priorities? BFV?
17:23:25 <dtantsur> #action jroll to check on our nova work this week
17:23:30 <TheJulia> last I looked we only needed a blueprint for BFV with nova
17:23:32 <jroll> afaik we have approved BPs for everything we want to do, but I'll double check
17:23:36 <dtantsur> thanks!
17:23:43 <jroll> np
17:23:51 <dtantsur> as to priorities, I applied only minimal changes to the list from last week
17:24:21 <dtantsur> well, I'd prefer to bump redfish priority for reasons already known to the core team :-/
17:24:40 <dtantsur> (sorry for secrecy here)
17:25:01 <rloo> dtantsur: true, but I don't think we should.
17:25:28 <dtantsur> rloo, why?
17:25:34 <rloo> dtantsur: can discuss later
17:25:42 * mariojv is lost here
17:25:50 * TheJulia thinks she groks it
17:25:53 <rloo> it isn't a high priority
17:26:12 <rloo> i think if the community wants it, they'll review, regardless if it is on our list of priorities or not
17:26:35 <dtantsur> well, it's going to be on my personal high priority list anyway
17:26:42 <dtantsur> but ok
17:26:45 <rloo> dtantsur: which is perfectly fine!
17:26:48 <jroll> rloo: I think you and dtantsur agree, don't have it on this weeks priorities
17:26:52 <jroll> right?
17:26:58 * TheJulia agrees
17:27:00 * jroll not sure if bump means bump up or bump off here
17:27:16 <mariojv> i agree with bumping for this week
17:27:19 * TheJulia wonders if we should be using more specific words
17:27:32 <mariojv> it can stay on the spec priority list imo
17:27:38 <dtantsur> yeah, my English lets me down sometimes. I meant to raise its priority.
17:27:38 <jroll> spec is merged :)
17:27:42 <jroll> ah
17:27:44 <mariojv> and we can update and have gerrit votes on that, if that has to change, im
17:27:45 <mariojv> *imo
17:27:46 <rloo> redfish driver isn't on this week's list of priorities
17:27:56 <rloo> see L75+
17:28:23 <TheJulia> I think organically through community reviews would be best, if the community wants to see it sooner rather than later, it will get reviews
17:28:23 <dtantsur> sorry for confusion, everyone. what I suggested (and what rloo correctly understood, I think) is adding redfish to the prio list
17:28:31 <dtantsur> it seems like we're in agreement that we should not.
17:29:01 <TheJulia> seems like it
17:29:11 <jroll> yeah, I'm fine leaving it off
17:29:22 <jroll> actually I'm fine either way :P
17:29:30 <dtantsur> so, does the list look ok now?
17:29:32 <jroll> would be nice to just get it done, but it isn't a high priority
17:29:45 <jroll> yep, fine with me
17:29:53 * dtantsur blames daylight saving change for his condition >_<
17:29:59 <rloo> the osc default API version change. is there an urgency with that, or we just have to do it anyttime in pike?
17:30:20 <mariojv> i think it's fine as long as it gets in 3 months before queens
17:30:27 <TheJulia> what mariojv just said
17:30:33 <dtantsur> ++
17:30:34 <rloo> mariojv: ok, remind us if we get close and it ain't
17:30:38 <mariojv> will do
17:30:44 <jroll> if it doesn't, we just need to drop it later in queens, is that a problem? :)
17:31:01 <TheJulia> I don't see it as a problem personally, just revise the spec
17:31:01 <mariojv> i still need to get ironic CLI patch up and have it log when using client library
17:31:03 <rloo> jroll: i'd like it to be done, sooner rather than later
17:31:08 <mariojv> but spec and openstack CLI patches are up
17:31:13 <TheJulia> +1 on just getting it done.
17:31:30 <mariojv> jroll: not a problem, but no reason to not do it soon :)
17:31:31 <rloo> i think i'm good with priorities for this week. will maybe ask aout network ones next week :)
17:31:39 <jroll> yep
17:31:40 <mariojv> +1 priorities look fine to me
17:31:41 <jroll> they LGTM
17:31:45 <TheJulia> same
17:31:50 <vdrok> +1
17:31:53 <dtantsur> awesome
17:32:18 <dtantsur> #topic RFE review
17:32:26 <dtantsur> we have some this time!
17:32:32 <mariojv> \o/
17:32:33 * jroll gets ready to yell
17:32:38 <vdrok> this time I added a couple
17:32:40 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1669243 - Support for zmq in ironic
17:32:40 <openstack> Launchpad bug 1669243 in Ironic "[RFE] Ironic doesn't support zmq with oslo.messaging" [Wishlist,In progress] - Assigned to Galyna Zholtkevych (gzholtkevych)
17:33:00 <vdrok> first one seems to be pretty easy, do we want to support zeromq?
17:33:17 <jroll> this one shouldn't be an RFE, IMO - we claim to support any oslo.messaging-supported backend, feels like a bug if zmg is broken
17:33:24 <jroll> s/zmg/zmq/
17:33:33 <mariojv> +1 to what jroll said
17:33:39 <vdrok> yup, I'm fine with that too
17:33:43 <TheJulia> +1
17:33:45 <mariojv> if there's not a huge technical reason not to support it, we should, imo
17:33:56 <rloo> +1, seems like a bug
17:34:06 <dtantsur> any objections to treating it as a bug?
17:34:14 <TheJulia> none
17:34:25 <dtantsur> #agreed treat broken zmq support as a bug, not RFE
17:34:26 <rloo> but pleeeeeze, if it needs an rpc bump, can it wait til after rolling upgrades? :) me adds comment
17:34:34 <jroll> ++
17:34:36 <dtantsur> hah, ++
17:35:06 <dtantsur> next
17:35:26 <dtantsur> #link https://bugs.launchpad.net/ironic-inspector/+bug/1678134 - plugin for setting local link connection switch info from LLDP system name
17:35:26 <openstack> Launchpad bug 1678134 in Ironic Inspector "[RFE] plugin for setting local link connection switch info from LLDP system name" [Wishlist,In progress] - Assigned to Mark Goddard (mgoddard)
17:35:33 <vdrok> the second one is a bit harder, it seems like there is a confusion among the ml2 drivers maintainers
17:35:57 <vdrok> it seems like cisco and oneview ml2 drivers implemented the switch_info as dictionaries
17:36:27 <jroll> I thought switch_info was intended to be a dict
17:36:43 <vdrok> and in case of oneview, they want to make switch_info required i suppose, at least from this change https://review.openstack.org/#/c/377106/9
17:36:46 <vsaienk0> jroll: according to the spec it was designed as a string
17:36:55 <mgoddard> the ironic-neutron ml2 spec didn't specify what format it should take, but gave the suggestion that it could be switch system anem, which is a string
17:37:09 <mgoddard> s/anem/name
17:37:19 <vsaienk0> mgoddard: it is specified in the spec both port_id switch_id and switch_info are string fields
17:37:27 <jroll> oh right, it does say it's a string
17:37:33 * jroll scratches his head
17:37:41 <vdrok> well, it explicitly stated strings :) but, we have to deal with it somehow at this point
17:37:53 <mgoddard> right you are vsaienko
17:38:01 <dtantsur> can't we fix the plugins to (also?) allow strings there?
17:38:15 * jroll bets it's a string that looks like a dict
17:38:22 <vsaienk0> https://review.openstack.org/#/c/188528/7/specs/liberty/ironic-ml2-integration.rst@94
17:38:50 <jroll> regardless, the switch_info field is meant to be optional, and vendor-specific. so a plugin layer for inspector seems sane enough there
17:39:20 <dtantsur> I'm also fine with putting a name there, and allowing plugins to overwrite, but dunno..
17:39:41 <jroll> kinda sucks that we have to do it, but it's explicitly vendor specific, so what can you do
17:39:52 <ricardoas> thats right, jroll... we've been using switch_info as a string that looks like a dict
17:40:01 <mgoddard> sambetts made the point that the plugin may need to be aware of the switch that the node is connected to in order to determine the correct thing to put there
17:40:14 <dtantsur> I'm pretty sure I don't like the base class approach though
17:40:16 <ricardoas> jroll in fact, more like a json object
17:40:44 <jroll> ricardoas: which I don't quite like, but alas
17:40:47 <dtantsur> we need separate plugins layered on top of the generic one, not inheriting from it
17:40:56 <vsaienk0> it is better to use a new key switch_capabilities to define a switch capabilities as LLDP field is capabilities not info
17:41:21 <jroll> the confusion around this makes it sound spec-able
17:41:30 <jroll> lots of ideas here
17:41:36 <jroll> should be a quick spec to write
17:41:36 <mgoddard> dtantsur: it is layered in my proposal, as the generic plugin now inherits from the base
17:41:37 <TheJulia> spec-able, and also it feels like all of the information needs to be presented
17:41:42 <jroll> TheJulia: ++
17:41:49 <TheJulia> because it seems like there are several vectors that can and should be addressed
17:42:04 <dtantsur> mgoddard, well, I'm probably using the wrong word, but I'd like inheriting to disappear for the picture
17:42:17 <TheJulia> including possibly changing the ml2 drivers to be more consistent or possibly small architectural changes to improve the overall experience.
17:42:32 <dtantsur> mgoddard, in favor of just having another small plugin running after the generic one and adding the name. dunno how easily doable it is
17:42:58 <dtantsur> mgoddard, I suspect we need to plug bfournie's LLDP work in
17:43:12 <dtantsur> also ++ for a spec
17:43:49 <dtantsur> objections?
17:43:58 <mgoddard> dtantsur: it's doable, would just require a refactor
17:43:59 <vdrok> nope, makes sense to me
17:44:05 <jroll> dtantsur: +1
17:44:09 <mgoddard> seems reasonable
17:44:29 <dtantsur> #agreed https://bugs.launchpad.net/ironic-inspector/+bug/1678134 will need a spec to clarify all the details
17:44:29 <openstack> Launchpad bug 1678134 in Ironic Inspector "[RFE] plugin for setting local link connection switch info from LLDP system name" [Wishlist,In progress] - Assigned to Mark Goddard (mgoddard)
17:44:36 <dtantsur> anything else here before we move on?
17:45:01 <dtantsur> #topic What about having the first mid(not really mid)cycle soon?
17:45:14 <TheJulia> +1
17:45:15 <dtantsur> I remember we talked about having more virtual meet-ups
17:45:26 <rloo> why do we want it?
17:45:42 <dtantsur> rloo, high throughput, especially around RFE/spec reviews and agreeing on contentions points
17:45:50 <TheJulia> I think it would be really good to get on the same page, even if it just for a couple hours talking on a call prior to the summit.
17:46:11 <jroll> I'd almost prefer having a discrete list of things to work through, but syncing up is always helpful too
17:46:25 <TheJulia> I agree with jroll
17:46:27 <dtantsur> I remember we had 8 4-hour slot on the last virtual midcycle, right? we can have only 2 slots now, one in each time
17:46:42 <dtantsur> s/8/6/ maybe, it was 3 days
17:46:42 <rloo> oh. i don't mind a meeting to sync up. guess i'm not sure i want it to be called a midcycle meetup.
17:46:45 <jroll> I think it was 6 slots, but yeah
17:46:51 <rpioso> Do we plan to meet at the Summit Forum?
17:46:52 <TheJulia> It was 6
17:46:55 <mariojv> i'd be fine with that ^ i think later in the cycle might be better for a real midcycle
17:47:02 <dtantsur> rloo, I used word "midcycle" to give folks a quick idea what I mean
17:47:02 <TheJulia> do we have a curated list of items to discuss dtantsur ?
17:47:03 <mariojv> by "that" i mean the 2 slots
17:47:05 <rloo> i mean, several short syncs during a cycle are great. we should have them when we 'need' them.
17:47:27 <jroll> rpioso: afaik we only have 2-3 devs going, so while they will probably meet up it won't be a team meetup
17:47:30 <dtantsur> TheJulia, not now, but I do have a few things in mind. e.g. ongoing nova work and what to do about capabilities..
17:47:33 <rloo> eg, if we have say 2 features that are ready, then lets just meet to *do* them.
17:48:00 <dtantsur> rloo, e.g. rolling upgrades, I guess, could use more eyes and discussion
17:48:05 <dtantsur> this is really just a guess though
17:48:09 <rpioso> jroll: ty
17:48:54 <dtantsur> anyway, what I wanted today is to suggest it and let you think if you have something for a high-throughput discussion
17:48:56 <TheJulia> dtantsur: It might also be prudent to spend a little time discussing stand-alone usage related items, but that is just a thought
17:49:13 <rloo> dtantsur: so TheJulia and jroll are away next week, and TheJulia is away the week after. Shall we tentatively schedule something the week TheJulia is back?
17:49:14 <dtantsur> TheJulia, yep, especially if you'll have a list of rough edges by then
17:49:28 <dtantsur> rloo, ++
17:49:36 <TheJulia> dtantsur: already mostly typed out :)
17:49:40 <wanyen> dtantsur, will virtual meetup logistics be published so non-core can participate?
17:49:47 <dtantsur> wanyen, definitely!
17:49:48 <vdrok> wanyen: sure
17:49:51 <rloo> and then the/a big problem is time...
17:49:54 <wanyen> thanks
17:49:54 <dtantsur> this is one of the big goals
17:50:14 <dtantsur> wanyen, it will probably be something like SIP, but other FOSS-friendly options will be considered too
17:50:34 <dtantsur> TheJulia, which dates are you free? I'm confused with "next" here..
17:51:07 <TheJulia> dtantsur: Starting back the week of the 24th
17:51:16 <dtantsur> ack
17:51:32 <rloo> that's the week just before summit
17:51:45 <dtantsur> which is good, I guess
17:51:48 <rloo> oh no. there is another week after that.
17:52:03 <rloo> that woudl be a good week then.
17:52:07 <dtantsur> #agreed Let's think if we find value in a virtual meetup (similar to previous virtual midcycle) e.g. on the week of Apr 24th
17:52:09 <dtantsur> right?
17:52:20 <TheJulia> Yup
17:52:30 <rloo> yup. i guess we shoudl have an etherpad for people to suggest things.
17:52:42 <rloo> and possible days/times.
17:52:55 <dtantsur> #action dtantsur to announce this idea on the mailing list and create an etherpad for potential topics
17:52:58 <rloo> i hope it is just one day, one block of time. but i guess it depends on what we talk about.
17:53:23 <dtantsur> rloo, probably 2 blocks on one day because of timezones...
17:53:40 <dtantsur> but ok, let's think about it for some more time
17:53:53 <rloo> dtantsur: i really would like to see more focused things, to get concrete stuff done, but yeah, let's see.
17:53:59 <dtantsur> rloo++
17:54:01 <dtantsur> any more comments before I open the floor?
17:54:15 <dtantsur> #topic Open discussion
17:54:19 <mariojv> i have a small thing about rescue mode i'd like to bring up, proxying for JayF
17:54:23 <mariojv> basically, in nova, they allow a user to specify which image will be used when rescuing an instance - so the image will specify info about which user is created for SSH access when rescue finishes
17:54:29 <mariojv> with ironic, we're not letting the user specify the rescue image, since that doesn't really make sense in our case
17:54:33 <mariojv> so this brings up the question of what to call our rescue user
17:54:37 <mariojv> current behavior is to create a user called "rescue" that has passwordless sudo: https://review.openstack.org/#/c/423521/15/imagebuild/coreos/oem/finalize_rescue.sh (L6)
17:54:42 <mariojv> i prefer this over having the user just login as root immediately with the password given from nova
17:54:47 <mariojv> but it's still a decision we didn't really spell out explicitly in the spec, so i wanted to get community opinion on this
17:55:20 <dtantsur> so, these are two questions, right? whether to allow user images and what user to use?
17:55:32 <jroll> maybe make the user configurable?
17:55:44 <mariojv> i mainly wanted to focus on which user, for this discussion
17:55:48 <dtantsur> tbh, I'm fine with having root, if 'sudo -i' is going to be the first thing for people to do..
17:55:49 <rloo> mariojv: dumb question cuz i am not familar with rescue. shouldn't it work with nova's rescue?
17:56:06 <TheJulia> The person maintaining the volume connection API patch would like to get some reviews in order to head off nitpicking when it finally comes time to land the patch.  https://review.openstack.org/#/c/214586/  It has a few pep8 errors which I'll try to fix today.
17:56:19 <mariojv> rloo: yes - but in the nova case, they have user images when rescuing, so that's where they specify it
17:56:34 <mariojv> i think i'd be fine with having it root by default, in that case, dtantsur
17:56:37 <dtantsur> in other words: do we have a use case for non-root access to the rescue image?
17:56:59 <dtantsur> #link https://review.openstack.org/#/c/214586/ - volume connection API patch that could use early reviews
17:57:05 <mariojv> and maybe just have some docs for how to change it when building IPA if they want to (make it configurable in that way like jroll suggested)
17:57:17 <jroll> I'm okay with just root
17:57:29 <mariojv> dtantsur: i guess i was just a bit worried about giving a user something that they can do damage with, by default
17:57:31 <jroll> it doesn't really increase security to use a non-root user, if they have sudo
17:57:34 <mariojv> but maybe that's ok, since it's a ramdisk
17:57:49 <TheJulia> 3 minutes
17:57:49 <mariojv> yeah, not security, more prevent you from accidentally doing bad things
17:57:54 <dtantsur> mariojv, without root they won't even be able to mount disks (neither to access them)
17:58:07 <mariojv> ah that's a good point
17:58:16 <mariojv> ok, let's keep it as root then
17:58:20 <wanyen> so why it doesn't make sense for user to pick what rescue image?
17:58:31 <mariojv> that seems to be the default in a lot of nova docs for rescue mode anyway
17:58:34 <TheJulia> 2 minute warning
17:58:39 <mariojv> wanyen: that's a longer discussion than we have time for here
17:58:54 <jroll> tl;dr because pxe boot
17:59:06 <dtantsur> oh that Pixie :D
17:59:07 <mariojv> wanyen: but basically it opens up a huge amount of security risk, allowing someone to boot an arbitrary ramdisk
17:59:08 <vdrok> I'm not sure if anyone seen this spec from yuriyz -- https://review.openstack.org/452182, while it was intended for 1st april, it seems like whis will work for ipa authentication, if someone has a bit of time to read through
17:59:19 <mariojv> and it'd be a big pain implementation wise
18:00:01 <dtantsur> we're running out of time. thanks everyone!
18:00:04 <mariojv> thanks!
18:00:07 <vdrok> thanks
18:00:07 <TheJulia> Thanks!
18:00:12 <NobodyCam> :)
18:00:14 <dtantsur> #endmeeting ironic