17:00:03 <jroll> #startmeeting ironic
17:00:05 <openstack> Meeting started Mon Oct  3 17:00:03 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:07 <jroll> hi folks :)
17:00:09 <openstack> The meeting name has been set to 'ironic'
17:00:10 <mariojv> o/
17:00:11 <dtantsur> o/
17:00:14 <xek> o/
17:00:20 <mgould> o/
17:00:21 <JayF> o/
17:00:21 <rloo> howdy
17:00:23 <NobodyCam> o/
17:00:30 <gcb> o/
17:00:31 <hshiina> o/
17:00:34 <jlvillal> oi/
17:00:37 <cdearborn> o/
17:00:40 <lucasagomes> o/
17:01:02 <vdrok> o/
17:01:07 <devananda> o/
17:01:09 <jroll> #topic announcements and reminders
17:01:14 <milan> o/
17:01:19 <jroll> so newton is done
17:01:24 <mgould> \o/
17:01:25 <jroll> the summit is fast approaching
17:01:27 <bfournie> o/
17:01:29 <TheJulia> o/
17:01:46 <jroll> there's a topic later on summit sessions
17:02:08 <jroll> I don't think I have any other announcements or reminders, does anyone else?
17:02:16 <jroll> oh! TC voting is this week, please do that :P
17:02:25 <dtantsur> the gate has been broken for some time, but seems fixed now
17:02:44 <jroll> ah yes, that too. last week was rough but we should be good to review things now
17:03:09 <rloo> jroll: anything you want us to focus on these next few weeks before the summit?
17:03:18 <krtaylor> o/
17:03:20 * dtantsur whispers: specssssss
17:03:23 <jroll> ^^
17:03:24 <rloo> and install guide got backported to newton!
17:03:31 <rama_y> o/
17:03:32 <devananda> woot!
17:03:32 <jroll> yes it did!
17:03:40 <lucasagomes> rloo, oh cool, didn't know that !
17:03:52 <jroll> thanks to JayF, mat128, and all the reviewers for helping with that
17:04:13 <rloo> lucasagomes: it was done by stealth. and maybe also allowed cuz a docs person asked us to backport it :D
17:04:28 <JayF> fwiw the policy for docs backporting is: you can backport docs
17:04:38 <JayF> so I don't think it was any stable policy violation or anything to do it
17:04:40 <lucasagomes> :D right
17:04:41 <rloo> JayF: sweet. anything related to docs?
17:04:48 <JayF> rloo: aiui, yes
17:05:06 <jroll> well, assuming they're correct :)
17:05:23 <rloo> JayF: that is something we should be careful with cuz we could always improve on the docs...
17:05:28 <jroll> anything else before subteam reports?
17:05:31 <rloo> http://docs.openstack.org/project-install-guide/baremetal/newton/
17:05:47 <jroll> rloo: that's the stable policy, the stable reviewers can always say "stop this is annoying" :P
17:05:58 <JayF> quick question about subteams: I think it could be useful to list docs as a subteam
17:06:07 <JayF> especially since I want to spend some time this cycle testing and improving our docs
17:06:13 <rloo> jroll: :)
17:06:16 <jroll> JayF: there is the cross-project things down at the bottom no?
17:06:32 <JayF> jroll: yeah; but like, this isn't "docs project" things, it's about improving ironic's docs
17:06:45 <JayF> jroll: I don't view that as cross-project, not like docs team is telling us "do X or else!"
17:07:09 <rloo> wrt subteams, jroll mentioned last week that he had some thought about subteams. also, we tend to update that after the summit/priorities are clearer, so maybe let's defer that til later?
17:07:20 <jroll> JayF: I guess, I don't mind putting it there, though I think I'd prefer for those to be priorities
17:07:23 <jroll> yeah what rloo said
17:07:37 * jroll tries to remember the thoughts he had
17:08:18 * rloo turning blue waiting for jroll to remember !
17:08:34 <jroll> let's move on for now :D
17:09:06 <jroll> #topic subteam status reports
17:09:14 <jroll> #link
17:09:17 <jroll> oops.
17:09:21 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:09:22 <pas-ha> o/
17:09:23 <jroll> as always
17:09:33 <jroll> around line 83 this time
17:09:42 * jroll reviews and waits for questions
17:09:49 <rloo> dtantsur: is the 'high' nova bug a very high bug?
17:10:01 <dtantsur> rloo, dunno, haven't had a chance to look
17:10:08 * dtantsur finds it
17:10:08 <rloo> cuz, you know, we don't want to annoy the nova folks :D
17:10:09 <jroll> I see 10 new bugs, hopefully from people testing newton :D
17:10:32 <dtantsur> https://bugs.launchpad.net/nova/+bug/1599836
17:10:33 <openstack> Launchpad bug 1599836 in OpenStack Compute (nova) "Booting Ironic instance, neutron port remains in DOWN state" [High,In progress] - Assigned to Vasyl Saienko (vsaienko)
17:10:54 <dtantsur> at least it's in progress
17:11:09 <rloo> thx dtantsur. vasyl is looking at it so that is good.
17:11:15 <dtantsur> jroll, various stuff, newton included iirc
17:11:25 <jroll> cool
17:11:39 * jroll can also bug johnthetubaguy about picking that fix back up
17:12:05 <dtantsur> this might be high as well: https://bugs.launchpad.net/ironic/+bug/1629133
17:12:06 <openstack> Launchpad bug 1629133 in devstack "New neutron subnet pool support breaks multinode testing." [Critical,In progress] - Assigned to Dr. Jens Rosenboom (j-rosenboom-j)
17:12:09 <rloo> jroll: can we do an ironic-lib release to unblock the root device hints?
17:12:11 <dtantsur> just haven't got to it yet
17:12:25 <dtantsur> rloo++ and to unblock the whole disk job
17:12:26 <jroll> rloo: release team told me to wait for this week - I'll bug them today
17:12:29 <jroll> it's already proposed
17:12:42 <rloo> jroll: thx
17:12:44 <lucasagomes> jroll, thanks for that
17:14:24 <jroll> anything else on this topic?
17:15:49 <jroll> lucasagomes: rloo: now I'm told after final release, so next week
17:15:52 <lucasagomes> we can move on I think
17:16:00 <lucasagomes> jroll, cool
17:16:01 <rloo> jroll: boo :-(
17:16:32 <jroll> ok next up
17:16:37 <jroll> #topic summit session proposals
17:16:41 <jroll> #link https://etherpad.openstack.org/p/ironic-ocata-summit
17:16:52 <jroll> so I wanted us to kind of go over this and see if we can get a rough list
17:16:57 <jroll> and finalize during the next meeting if needed
17:18:12 <jroll> down at the bottom I added some sessions about work for ocata that didn't have a session proposed - does I kind of feel like we should bias toward that, otherwise we'll just talk about future work that we aren't doing any time soon
17:18:17 <mat128> o/
17:18:22 <jroll> do folks agree/disagree?
17:18:42 <rloo> jroll: any constraints to this? eg, do we want to focus on stuff that we want to land in ocata, or that need to be discussed in order to land in ocata+P (eg nova-related ones)?
17:18:49 <mgould> jroll: sounds like a good idea
17:19:09 <gabriel-bezerra> should we place votes for interest in the proposed sessions on the etherpad?
17:19:23 <jroll> rloo: I mean, if we need to make significant progress in ocata, that fits in my mind
17:19:26 <gabriel-bezerra> it seems like the nicks there are for proposers only
17:19:36 <jroll> even if it isn't done until pike because nova
17:19:44 <rloo> jroll: gotcha
17:19:45 <dtantsur> jroll, leaving comments there
17:20:05 <dtantsur> gabriel-bezerra, before we vote, we need to figure out what actually requires a session
17:20:18 <gabriel-bezerra> got it
17:20:18 <dtantsur> some things there are like "please review my spec"
17:20:40 <dtantsur> and anyway, ocata will probably not have too many new features, in addition to what jroll put there...
17:20:48 <jroll> indeed
17:20:51 <rloo> jroll: wrt your list at the bottom, are we looking at one session per item?
17:20:52 <jroll> short cycle, don't forget :)
17:20:55 <jroll> rloo: yes
17:21:22 <rloo> jroll: eg rolling upgrades, i don't think we need a session for it. unless it is to eg approve the spec. we have already talked about it in previous summit
17:21:53 <vdrok> jroll: by portgroups, you mean number 3?
17:21:57 <dtantsur> let's use the contributor meetup for "approve the spec" work, maybe?
17:22:04 <jroll> rloo: okay - fwiw I'm fine with a session (for most features) to get a spec in an approvble state
17:22:09 <jroll> contributor meetup is also okay
17:22:10 <vdrok> under the 1. networking
17:22:18 <rloo> dtantsur: the contributor meetup is fri afternoon? i am not sure.
17:22:23 <jroll> vdrok: no, the portgroups functionality being worked on now
17:22:25 <jroll> rloo: it is
17:22:33 <rloo> dtantsur: i'd rather have a session devoted to spec approvals/discussions
17:22:47 <vdrok> jroll: but it's mostly done right? only configdrive missing?
17:22:56 <dtantsur> rloo, this will end up with very few people talking, I'm afraid. unless we split into working groups.
17:23:12 <rloo> dtantsur: what do we need, wrt getting specs approved?
17:23:20 <rloo> dtantsur: the few people that are opinionated ;)
17:23:25 <jroll> vdrok: right, it isn't merged, so I included it in that list. I think it's important to figure out the plans for networking
17:23:35 <jroll> vdrok: so maybe "merge portgroups now" is part of that plan
17:23:45 <dtantsur> rloo, so, we have two cases: 1. needs discussion/arguing - a case for a session, 2. needs fixing small issues and careful reading - a case for the contributor meetup IMO
17:24:13 <rloo> dtantsur: we should be able to do 2 offline, i mean, like our current process of reviewing etc.
17:24:54 <rloo> dtantsur: or a spec review session. or maybe we should think about holding those once every week or two. i think that has been suggested in the past.
17:25:30 <yuriyz|2> +1
17:25:31 <dtantsur> I'm all for having a monthly call for things like specs, urgent discussions, etc
17:25:39 <milan> rloo +1 for periodic spec reviews
17:25:42 <jroll> yeah, ditto
17:25:43 <rloo> dtantsur: quite frankly, when i look/review a spec, it isn't a one-hour affair. it could take days. wrt notification, i ended up looking at nova. so i can't just review 'at the time' and +/- anything.
17:25:48 <TheJulia> I would <3 a monthly call
17:25:54 <JayF> I'd love a periodic spec review thing
17:26:00 <mat128> +1
17:26:08 <JayF> there are a lot of times when just context from other folks can help remove concern or allow for clarification of the spec
17:26:19 <milan> JayF, exactly
17:26:24 * rloo thinks we might be discussing retrospective/ etc, not summit sessions :)
17:26:39 <jroll> hehe
17:26:48 <jroll> yeah so back on track a bit
17:26:49 <rloo> ok, focus, focus on design sessions :)
17:26:56 <jroll> I think we can eliminate some of these now
17:27:08 <rloo> jroll: wrt notifications, i think we're good.
17:27:20 <jroll> e.g. 13-15 I think are out, I don't see anything really to do there
17:27:38 <rloo> jroll: i mean, i didn't look at latest revisions, but i think things are moving along. i am hoping the crud spec gets approved this week. (if yuriy agrees with me, ha ha.)
17:28:15 <jroll> rloo: got it, wrote it down, thanks
17:28:28 <rloo> jroll: i think it would be good to have one session to go over whatever high priority items, to get the status and address whatever might be blocking them.
17:28:33 <dtantsur> ++ for removing 13-15 right away
17:28:57 <jroll> rloo: okay, I'm cool with that
17:29:01 <lucasagomes> jroll, yeah
17:29:13 <jroll> does anyone disagree with removing 13-15
17:29:16 <lucasagomes> #9 == #5 as well (apart from luks)
17:29:20 * jroll waits 30s and then just does it
17:29:27 <mat128> jroll: +1 to removing 13-15
17:29:51 <rloo> wrt 13, i think someone should just reach out to bruno, looks like he is looking for guidance. and i think he sent out email about it.
17:29:52 <dtantsur> lucasagomes++ we can scope it to "how to pass advanced information from nova"
17:30:08 <lucasagomes> dtantsur, yup
17:30:23 <rloo> honestly, i don't think we should actually DELETE the stuff from that etherpad. just indicate that they will not be considered.
17:30:31 <dtantsur> because it's the only hard point, everything else is solveable (not in ocata, I guess)
17:30:33 <jroll> rloo: +1, I've also been in contact with some people about redfish offline
17:30:37 <mat128> rloo: it was changed to strikethrough
17:30:42 <jroll> rloo: +1, when I say delete I mean strike through
17:30:43 <mat128> rloo: soft-delete if you want :)
17:30:51 <rloo> mat128: strikethrough is OK :)
17:31:09 <yuriyz|2> rloo i revorked the spec based on your proposal totally agree with you :)
17:31:17 <rloo> we had a session on redfish 2, 3? summits ago
17:31:42 <rloo> yuriyz|2: thx, will look today :)
17:31:45 <jroll> so #10, CUPS thing, I don't really care to talk about that specific case but rather talk about some sort of task framework that could include that case
17:31:48 <mat128> rloo: I remember that in Vancouver
17:32:05 <xek> jroll, +1
17:32:09 <rloo> wrt redfish -- if we think that is something we'd like to have soon, and there has been more work on redfish, would be worth having a session
17:32:25 <rloo> jroll: ++
17:32:35 <rloo> jroll: I mean ++ wrt the task framework
17:33:10 <jroll> rloo: cool
17:33:21 <mgould> ah, Compute Usage Per Second, not Common Unix Printing System :-)
17:33:25 <mgould> thank goodness for that
17:33:37 <devananda> rloo: I believe there's a lot more interest in redfish now than a year+ ago. but we still need someone to lead the actual implementation of it
17:33:37 <dtantsur> lol, I also liked that
17:33:44 <rloo> mgould: ironic is going into the printing business
17:33:47 <jroll> devananda: do you think the redfish stuff is in any sort of state to have a summit session or just needs work for now?
17:33:54 <jroll> work/people/etc
17:34:00 <dtantsur> devananda, yeah, I wonder if we actually have something to discuss, or do we need to get on a spec first...
17:34:00 <mgould> rloo: NOOOOooooOOOOOoooOOOO....
17:34:04 <lucasagomes> mgould, ++ yeah that what came to mind when I first read that
17:34:18 <devananda> jroll: bcornec has a presentation on it, and I've asked the interested parties at several companies to meet after that
17:34:24 <jroll> we're only deploying printers, not managing them, don't worry
17:34:30 * jroll imagines literal cleaning steps
17:34:30 <mgould> whew
17:34:37 <jroll> devananda: so, probably not?
17:34:41 <mat128> jroll: self-clean much? :)
17:34:42 <JayF> I don't know why anyone could hate software that includes something called "foomatic"
17:34:45 <devananda> without someone leading the work (and I don't expect to have time) I don't think it's worth a dedicated session on it
17:34:53 <devananda> and there's not much to do _in_ ironic
17:35:18 <jroll> devananda: thanks, I believe you're the most educated on this subject (in this meeting) so deferring to you and striking that out
17:35:30 <devananda> it'll be another power driver. that's NBD. but we need someone to write the python things, the tests, etc, before it's really possible to accept that driver in-tree
17:35:42 <JayF> I mean another argument for striking it out would be that we'd never have a session like that for a vendor driver :)
17:35:51 <dtantsur> 3rd party CI...
17:35:58 <dtantsur> or something like virtualbmc
17:36:01 <devananda> dtantsur: right. or in-tree CI.
17:36:03 <rloo> JayF: we did have a session for eg ansible driver
17:36:11 <mat128> dtantsur: oh please, virtualbmc for redfish!
17:36:12 <cdearborn> I'm interested in participating in redfish related discussions
17:36:18 <devananda> JayF: fair, however, it should be open source and cross-vendor, so because of that, I can see us holding space for it
17:36:23 <JayF> rloo: I guess that's true; but it mostly started out as a controversial spec, no?
17:36:40 <jroll> dtantsur: mat128: people are talking about a redfish server reference implementation, I think CI will happen that way :)
17:36:49 <devananda> what jroll said ^
17:36:54 <mat128> jroll: thats perfect then :)
17:36:59 <jroll> anyway I don't think a session is useful for redfish, let's move on :P
17:37:00 <dtantsur> good, but it should happen at the same time as the driver
17:37:08 <devananda> dtantsur: or before :)
17:37:12 <lucasagomes> mat128, yeah, it's ReST so should be easy to add it to vbmc
17:37:16 <dtantsur> even better :)
17:37:34 <rloo> btw, does anyone have a link to the email wrt the number of rooms we have? i forgot. is it 4 + 4?
17:37:42 <jroll> vdrok: dynamic portgroups is about specifying portgroup (or not) and such in nova, right?
17:37:51 <jroll> rloo: I think 4+4, yeah, I'll double check
17:38:14 <vdrok> jroll: yep, allowing to specify these things in nova and ironic will be creating portgroups on the fly
17:38:17 <jroll> Ironic: 4fb 4wr cm
17:38:22 <jroll> vdrok: okay
17:38:31 <rloo> jroll: thx.
17:39:51 <rloo> jroll: wrt #3. why do you think it is a bit early to discuss dynamic portgroups?
17:40:15 <jroll> rloo: we need portgroups at all, first, and I think the other networking features like vlan aware instances are much more important
17:40:19 <dtantsur> because we don't have regular portgroups yet? /me is guessing
17:40:29 <devananda> ++ vlan aware instances
17:40:40 <jroll> I don't see a huge use case for specifying whether or not an instance has portgroups
17:40:58 <rloo> jroll: oh. i thought the regular portgroups was 'almost' done, ie patches to be reviewed. (but i haven't looked)
17:41:08 <TheJulia> There is a use case if your using ironic to manage more than just "instances" for "guests"
17:41:14 <rloo> definitely vlan aware instances
17:41:16 <jroll> rloo: but it isn't done.
17:41:37 <devananda> jroll: what about a session on provisioning other types of devices, eg. TOR switches?
17:41:39 <rloo> jroll: i know. but if that dynamic portgroups involves nova, shouldn't we discuss sooner rather than later?
17:41:41 <jroll> so I want to cap this topic pretty soon, lucasagomes also has a thing on the agenda
17:41:52 <lucasagomes> jroll, mine's quick I think
17:42:05 <dtantsur> we get discuss lucasagomes' topic, then get back to sessions
17:42:06 <jroll> devananda: nobody has proposed a session about that, there is an RFE and a spec in progress though.
17:42:19 <rloo> dtantsur: so you don't need a session for inspector?
17:42:25 <rloo> dtantsur: #6
17:42:26 <dtantsur> rloo, I don't think so
17:42:33 <jroll> rloo: maybe - it's unclear if there's major changes to make to nova though
17:42:37 <dtantsur> we have a lot of pretty well defined work to finish...
17:42:43 <jroll> TheJulia: I'm curious on that use case but I'll ask later
17:43:08 <rloo> jroll: ok. let's identify what stuff (that we want to land in ocata, early pike) touches nova or neutron
17:43:18 <TheJulia> jroll: later ++
17:43:21 <jroll> rloo: +1
17:43:25 <dtantsur> and the work we're planning requires pretty good knowledge of inspector, so it would be boring for most of folks
17:43:51 <rloo> dtantsur: so we can strikethrough #6?
17:44:01 <dtantsur> rloo, done
17:44:04 <rloo> thx!
17:44:08 <milan> we can always have a hallway sync-up on the status ;)
17:44:11 <jroll> okay, so this was super useful (for me at least). should we have folks vote on the remaining sessions and go from there?
17:44:21 <jroll> rloo: and can you add one in the list for "unblock high prio things"?
17:44:23 <dtantsur> milan, I think we'll do
17:44:30 <rloo> jroll: will do
17:44:37 <jroll> thanks
17:45:03 <jroll> folks, please vote on the topics this week when you get a chance, I hope to finalize the list next week
17:45:08 <dtantsur> wait a second
17:45:09 * jroll moves to lucas
17:45:12 <jroll> ?
17:45:19 <dtantsur> ah, ok, let's give the mic to lucas
17:45:22 <jroll> heh
17:45:24 <lucasagomes> :D
17:45:28 <jroll> #topic Whole disk image inconsistency between pxe_* and agent_* drivers. Which approach to take ?
17:45:35 <jroll> #link https://review.openstack.org/#/c/375481/
17:45:38 <jroll> all yours lucasagomes
17:45:53 <lucasagomes> thanks, so mine should be quick... it's just an inconsistency that we have between the agent_* and pxe_* drivers
17:46:10 <vdrok> I'd vote for local boot for all drivers :)
17:46:15 <lucasagomes> when deploying a whole disk image wihtout explicit setting the boot_option, both drivers will differ
17:46:27 <vdrok> as default of course
17:46:30 <lucasagomes> agent_* will assume we want to boot from the HD and will set the boot device to do it so at the end of the deployment
17:46:48 <lucasagomes> and pxe_* will first PXE boot and chainload it to the local disk bootloader
17:47:10 <lucasagomes> I think we should fix that because apart from the name both drivers uses the same boot interface
17:47:12 <mat128> lucasagomes: does agent_* support *always* netbooting?
17:47:17 <lucasagomes> I just don't know which approach is the "correct" one
17:47:20 <devananda> I think the majority of our users today expect local boot, based on conversations I have had
17:47:24 <mat128> and does pxe_* support local disk boot?
17:47:30 <vdrok> yep
17:47:31 <lucasagomes> mat128, not that I'm aware of, it could do
17:47:39 <JayF> There is already an RFE bug open to change the default to localboot, iirc
17:47:40 <devananda> lucasagomes: have you spoken with the tripleo team about this?
17:47:43 <lucasagomes> mat128, pxe)* yes
17:47:45 <mat128> lucasagomes: then standardizing on the common denominator seems like the way to go
17:47:57 <JayF> -1
17:48:07 <lucasagomes> devananda, I have not, but dtantsur has some work to have local boot to be the default in Ironic
17:48:12 <jroll> devananda: other than compatibility, is there a reason to speak with the tripleo team about that default changing?
17:48:16 <JayF> If we change the agent driver to do pxe boot by default, we're changing behavior that a user has started relying on
17:48:24 <JayF> in fact, that kinda goes both ways
17:48:25 <mat128> JayF: I was suggesting the other way around
17:48:34 <JayF> so no matter what we do, we'll have to do a deprecation period, right?
17:48:38 <jroll> JayF: right, that's the hard part about fixing this is compat
17:48:39 <devananda> jroll: last I heard (which was quite a while ago) some of their tools expected the default (net boot) behavior
17:48:39 <mat128> JayF: local boot everything, network boot only if requested
17:48:53 <JayF> mat128: I'm +1 to that, but we still ahve to do a deprecation period
17:48:54 <devananda> so if we change the default AND they don't explicitly set it, we may break some things
17:48:59 <mat128> JayF: as usual
17:48:59 <lucasagomes> honestly I prefer the agent_* way, because the whole disk image independent of being first booted by PXE still needs to have a bootloader
17:49:03 <JayF> maybe make the default behavior changable via config option?
17:49:05 <lucasagomes> so it seems to be a waste to PXE boot first
17:49:06 <mat128> always netbooting has scalability impacts
17:49:23 <jroll> devananda: right, so again proper deprecation needs to happen
17:49:24 <devananda> JayF: let's not introduce a default for setting defaults :)
17:49:33 <jroll> heh
17:49:34 <devananda> jroll: well, it's not a deprecation question, AIUI.
17:49:49 <devananda> we're just proposing to change the default of an exiting setting, right?
17:49:58 <jroll> devananda: the question is which direction to fix the inconsistency
17:50:07 <JayF> devananda: that's what I'm saying; I don't believe that behavior is configurable today
17:50:21 <mat128> JayF: if it was, would that be per-driver?
17:50:26 <JayF> devananda: not in a global-ironic.conf way (vs being set for the deployment)
17:50:30 <dtantsur> devananda, tripleo requires local boot
17:50:36 <dtantsur> (sorry, got distracted)
17:50:53 <JayF> mat128: *shrug* idk
17:51:04 <jroll> so, if most users (including tripleo) use localboot, I suggest local boot be the default
17:51:04 * dtantsur is not entirely sure why, probably to reduce dependency on the undercloud
17:51:13 <mat128> JayF: if it's per driver, everyone can have their default, if it's global then we have to converge
17:51:15 <devananda> dtantsur: ah. in that case, great
17:51:33 <JayF> mat128: "per driver" in a cycle when we're trying to change how drivers work gets /really/ sticky, hehe
17:51:44 <mat128> JayF: yeeah :S lol
17:51:51 <mat128> jroll: ++
17:51:54 <jroll> does anyone *disagree* with local boot being the default here?
17:51:59 <devananda> ++ localboot
17:52:06 <lucasagomes> also, we don't need to remove the "always pxe boot" case, we can make it valid when boot_option=netboot is explict set, as long both drivers behaves the same way
17:52:37 <jroll> right
17:52:43 <rloo> so shiv isn't here, but it seems like he disagrees
17:53:00 <mat128> lucasagomes: drivers that dont support it should crash early
17:53:12 <jroll> rloo: I wish he was here, so I could ask "if the driver was named iscsi_* would you still disagree"
17:53:18 <lucasagomes> mat128, right
17:53:43 * jroll asks in review
17:53:45 <rloo> jroll: yeah. my bad for not looking at this patch before the meeting...
17:54:03 <jroll> rloo: it's okay.
17:54:08 <jroll> also, not everybody needs to agree
17:54:20 <lucasagomes> +1 for localboot from /me
17:54:24 <jroll> I would like to understand the disagreement, but majority tends to rule
17:54:54 <rloo> jroll: but we're a nice big happy family. i want everyone to agree :) kidding aside, i think localboot makes sense.
17:55:03 <jroll> okay, once more, does anyone *disagree* with local boot being the default here?
17:55:09 <jroll> it sounds like no
17:56:03 <jroll> alright, let's do it
17:56:07 <jroll> with deprecation and such
17:56:12 <lucasagomes> cool, thank you all!
17:56:21 <jroll> #topic open discussion
17:56:44 <jroll> anyone have a thing?
17:57:03 <JayF> I'm going to be starting up a project this week to walk through the install guide, test it, find and bug or fix deficiencies
17:57:12 <dtantsur> JayF++
17:57:12 <JayF> if anyone has any interest in working with me on this, lmk offline
17:58:23 <jroll> ++
17:58:27 <jroll> alright, good meeting today, thank you all :)
17:58:31 <mariojv> o/
17:58:32 <lucasagomes> JayF, that's cool, there are many permutations on the way to setup things are planning to test it all ? Or pick some approaches ?
17:58:32 <jroll> #endmeeting