17:00:20 <jroll> #startmeeting ironic
17:00:20 <openstack> Meeting started Mon Feb 22 17:00:20 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:22 <TheJulia> o/
17:00:23 <openstack> The meeting name has been set to 'ironic'
17:00:25 <devananda> o/
17:00:26 <jroll> hello everyone
17:00:27 <vdrok> o/
17:00:30 <mkovacik> o/
17:00:34 <yuriyz> o/
17:00:37 <lucasagomes> hi there
17:00:40 <jlvillal> o/
17:00:53 <rpioso> o/
17:00:55 <sambetts> Hi all
17:01:35 <jroll> as always, agenda:
17:01:39 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:01:42 <davidlenwell> o/
17:01:48 <stendulker> o/
17:01:50 <jroll> looks halfway full today
17:01:50 <NobodyCam> o/
17:01:54 <jroll> #topic announcements and reminders
17:02:11 <mgould> o/
17:02:20 <jroll> we had our midcycle last week, it went very well. thank you to all who participated!
17:02:42 <jroll> etherpad from the midcycle is here:
17:02:45 <jroll> #link https://etherpad.openstack.org/p/ironic-mitaka-midcycle
17:02:50 <jlvillal> Thank you for organizing it :)
17:02:51 <dtantsur> o/
17:02:56 <jroll> I also sent a summary email of each block, and will be writing a larger summary later
17:02:58 <NobodyCam> was great to *hear all who where there
17:03:11 <jroll> other than that... dtantsur can you cover gate announcements?
17:03:12 <jlvillal> I also thought it went well.
17:03:17 <dtantsur> jroll, sure
17:03:23 <jroll> thanks
17:03:27 <dtantsur> as agreed there we did a couple of changes to our gate:
17:03:50 <dtantsur> 1. postgres job is no longer voting, we maintain it as much as we can (unless someone appears who's really interested in it)
17:04:18 <dtantsur> 2. a separate iPXE job was merged into a regular pxe_ipa job, meaning agent_ssh covers PXE, pxe_ipa covers iPXE
17:04:32 <dtantsur> 3. most of ironic jobs (except for inspector) are moved to iPXE
17:04:55 <dtantsur> 4. I've fixed stable/liberty today that got broken by tempest-lib transition :)
17:05:01 <dtantsur> I think that's it
17:05:11 <NobodyCam> dtantsur: thank you for that :)
17:05:21 <NobodyCam> (34)
17:05:25 <NobodyCam> (#4)
17:05:34 <dtantsur> now, I would really love to rename our jobs, so that their names actually make sense
17:05:36 <sambetts> 5. ram and vm count have been made configurable per job, and the tinyipa job is passing with 512mb of memory
17:05:40 <jroll> dtantsur: thanks! that's all merged I assume?
17:05:44 <dtantsur> jroll, yep
17:05:48 <jroll> awesome
17:05:58 <dtantsur> except for renames: anyone is free to do that
17:06:15 <dtantsur> personally I feel like we have less transient failure now
17:06:38 <jroll> yeah, it seems so
17:06:53 <dtantsur> I also have a topic to discuss, it's on agenda, so we'll probably get to it
17:07:03 <jroll> cool
17:07:06 <jroll> any other announcements?
17:07:18 * jlvillal would like names that make sense :)
17:08:04 <jroll> alright, moving on
17:08:09 <jroll> #topic subteam status reports
17:08:24 <jroll> as always, these are on the whiteboard:
17:08:27 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:08:38 <jroll> line 187
17:09:40 <dtantsur> jroll and others: can we move the last gate issues from the main etherpad to the gate-problems-tracking one?
17:09:49 <dtantsur> so that it doesn't grow indefinitely
17:10:04 <jroll> dtantsur: yes please :)
17:10:09 * dtantsur is doing
17:11:20 <devananda> dtantsur: +1
17:12:31 <devananda> jroll: did we reach a conclusion re: no-db api work last week?
17:12:54 <devananda> I feel like we left that open and needed to dig in further
17:13:01 <jroll> devananda: we agreed not to separate api and db until/unless we decided it was necessary
17:13:10 <jroll> we really can't find out without grenade and grenade-partial
17:13:14 * dtantsur has finished moving text around
17:13:38 <devananda> jroll: ah, that's the piece I forgot (dep on grenade). thanks
17:17:19 <jlvillal> Did something happen?
17:17:26 * jlvillal wonders why it got quiet
17:17:34 <sambetts> jlvillal: much typing on the etherpad
17:17:36 <jroll> we're all looking at the etherpad
17:17:37 <dtantsur> boom!!   <-- now something happened
17:17:38 <jlvillal> Ah :)
17:18:22 * jlvillal thinks for his very first time he had typed 90% of his stuff before the meeting actually started.
17:18:31 <jlvillal> By about five minutes
17:18:42 * NobodyCam replaces everone coffee with sanka
17:19:18 <lucasagomes> NobodyCam, oh noes, I need caffeine
17:19:18 * TheJulia looks at NobodyCam like he is crazy
17:19:25 <NobodyCam> lol
17:19:35 <NobodyCam> heheee
17:19:40 <TheJulia> Anyway, seems like it is time to move on
17:19:46 <NobodyCam> ,,
17:19:48 <NobodyCam> ++
17:19:53 <jroll> TheJulia: I'm curious about the bifrost thing
17:20:04 <jroll> shouldn't ironic pick up the old config okay?
17:20:17 <jroll> oh bottom of file
17:20:19 <TheJulia> jroll: the ansible module for doing the config injection was placing it at the bottom of the file in a different config section
17:20:20 <jroll> :x
17:20:21 * jroll +A
17:20:22 <TheJulia> yeah
17:20:36 <TheJulia> yeah :(
17:20:41 <jroll> alright, is approved
17:20:47 <TheJulia> Thank you!
17:21:26 <jroll> alright, shall we move on?
17:21:31 <dtantsur> yep
17:21:42 <devananda> +1
17:21:45 <NobodyCam> ++
17:21:49 <TheJulia> ++
17:22:09 <jroll> skipping the first topic as we got to it at the midcycle
17:22:19 <jroll> #topic How to deprecate the old ramdisk and its gates
17:22:25 <jroll> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086738.html
17:22:26 <dtantsur> oh yeah
17:22:27 <jroll> dtantsur: such fun!
17:22:46 <dtantsur> please read the link, it's not a long read, but a bit too much to tl;dr
17:23:19 <TheJulia> imho, seems like dib should have some level of stable branches for people who need to use point in time references
17:23:33 <jroll> well, dib does have releases
17:23:34 <dtantsur> tripleo stable branches, yeah.................
17:23:48 <TheJulia> but, sadly, that doesn't seem like a easy thing to be able to go back and make happen :(
17:24:17 <TheJulia> Well, I don't see it as a tripleo tool, I see it as a generally useful tool
17:24:17 <dtantsur> right. we have what we have, and all options are pretty bad
17:24:27 <TheJulia> yeah
17:24:33 <jroll> as someone that doesn't do distros, really
17:24:42 <jroll> does e.g. RDO kilo ship with a specific ramdisk?
17:24:53 <jroll> or would users/support be able to convert an install over to IPA?
17:25:09 <dtantsur> jroll, RDO kilo does not ship IPA at all
17:25:20 <jroll> dtantsur: but could it?
17:25:23 <lucasagomes> jroll, Kilo depends on the bash ramdisk
17:25:34 <dtantsur> it's not entirely impossible, although it's a big effort
17:25:40 <jroll> sorry, I should say liberty
17:25:42 <devananda> does DIB want to remove the old element?
17:25:48 <jroll> since liberty supports IPA + iscsi
17:26:00 <dtantsur> jroll, RDO liberty has IPA
17:26:05 <lucasagomes> jroll, liberty would be possible to use IPA yes
17:26:08 <dtantsur> and TripleO liberty defaults to it nowadays
17:26:24 <lucasagomes> devananda, we want to remove the support for the old ramdisk
17:26:30 * NobodyCam votes #2
17:26:37 <devananda> lucasagomes: we == tripleo / rdo ?
17:26:42 <jroll> devananda: we == ironic
17:26:42 <lucasagomes> devananda, we Ironic
17:26:44 <dtantsur> we == ironic :)
17:26:55 <dtantsur> neither of the other parties does not care enough
17:26:59 <mgould> sanity check: is there no way of running different gate jobs on different branches?
17:27:05 <lucasagomes> devananda, otherwise we have to keep supporting more than 1 ramdisk (bug fixes, features and so on)
17:27:06 <devananda> mgould: DIB does'nt have branches
17:27:10 <dtantsur> actually I had fun time convincing people to switch to IPA for liberty in tripleo....
17:27:26 <devananda> lucasagomes, dtantsur: does DIB want to remove this element from their tree?
17:27:27 <TheJulia> I think #2 is also the right thing to do.  #4 should be the fallback, and possibly the right thing to do, even though it would force stable branches for dib down the road
17:27:41 <dtantsur> devananda, I think they don't care.
17:27:47 <devananda> lucasagomes: if they do not want to remove the element, how will that project continue to test it if we do not support it?
17:27:49 <lucasagomes> devananda, I believe they may keep it for a while (it's already marked as deprecated)
17:28:06 <lucasagomes> devananda, they can use DIB to generate an IPA ramdisk
17:28:07 <sambetts> this was my suggestion -> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086742.html
17:28:15 <jroll> I believe I agree with TheJulia, I'd support #2
17:28:21 <lucasagomes> devananda, so the idea is to change the bash ramdisk with an IPA (also built with DIB)
17:28:27 <jroll> with a big fat warning for mitaka+
17:28:31 <TheJulia> ++
17:28:48 <NobodyCam> ++
17:29:16 <dtantsur> jroll, we can create an option to explicitly enable support for the old ramdisk, and switch it off for, say, Newton (but still use it in our gate)
17:29:22 <jroll> I don't love the idea of #4, just because we can't bugfix DIB for those branches
17:29:38 <jroll> dtantsur: yeah, that isn't a bad idea, --no-srsly-i-like-old-software
17:29:52 <jroll> I'd add it default false in mitaka though
17:30:02 <dtantsur> hehe, that remind me of "tripleo --thrash-my-machine" or something like that
17:30:07 <jroll> as we said we'd remove bash ramdisk support in mitaka
17:30:13 <devananda> yea, I dont think #4 is viable because we are supporting the bash ramdisk in Liberty -- and that would preclude bug fixes
17:31:02 <dtantsur> do we need a format vote?
17:31:09 <devananda> I do not understand why #2 says "will be supported in mitaka and newton"
17:31:28 <dtantsur> devananda, de facto it will be there, so potentially people may slack on upgrading
17:31:32 <dtantsur> it = code
17:31:32 <JayF> two cycles for deprecation, right?
17:31:43 <devananda> JayF: right
17:31:45 <TheJulia> JayF: cycle + 3 months I thoguht, so effectively 2
17:31:49 <NobodyCam> JayF: yep
17:31:55 <jroll> no
17:32:00 <devananda> JayF: the calculation is actually more complex than that now
17:32:02 <jroll> max(cycle boundary, 3 months) is the rule
17:32:37 <dtantsur> I think we're switching topics. I thought we're in agreement that Mitaka is an official EOL for the bash ramdisk, no?
17:32:39 <jroll> or rather, it must be across a cycle boundary, and at least 3 months
17:32:49 <dtantsur> and now we only figure out how to remove it without breaking innocent kittens
17:32:49 <jroll> dtantsur: yes, I agree that we had agreed on that
17:33:09 <jroll> yep
17:33:10 <TheJulia> dtantsur: ++
17:33:15 <devananda> dtantsur, jroll: I agree with that statement
17:33:22 <devananda> I believe the discussion is how we carry that out
17:33:26 <jroll> yes
17:33:38 <devananda> it sounds like we could drop it from ironic/master as soon as newton opens
17:33:44 <devananda> as long as we can keep it on stable branches
17:33:54 <jroll> so I agree #2 is the right thing to do, with either a large warning or a config flag
17:34:06 <dtantsur> option #2 is the safest, we just have to be REALLY good at convincing people to switch to IPA NOW
17:34:12 <devananda> which would mean moving DIB's testing of that ramdisk to ironic/stable/liberty -- or dropping the test from DIB whn Newton opens
17:34:17 <NobodyCam> Large warning and config flag
17:34:38 <devananda> jroll: is there currently a warning logged when using the bash ramdisk?
17:34:44 <jroll> I'm unsure
17:34:47 <dtantsur> I think so
17:35:20 <lucasagomes> I think the endpoints that the bash ramdisk uses may log something
17:35:26 <lucasagomes> pass_deploy_info etc
17:35:45 <jroll> yeah that sounds right
17:35:45 <sambetts> L902 ironic/drivers/modules/iscsi_deploy.py
17:35:46 <devananda> NobodyCam: I do not see the need for a CONF option here
17:35:52 <lucasagomes> yeah it does
17:35:56 <devananda> great
17:36:11 <jroll> so I like the idea of making DIB gate on stable/liberty for the bash ramdisk
17:36:36 <dtantsur> I wonder if infra would hate us for trying that...
17:36:38 <jroll> (assuming that is reasonably possible)
17:36:41 <jroll> heh, yeah.
17:37:01 <jroll> but if we can do that, then we can remove the support for it now, right?
17:37:04 <NobodyCam> I was thinking it would / could help with stable testing in the gate!
17:37:34 <sambetts> jroll: that was my suggestion
17:37:35 <TheJulia> it would
17:37:50 <dtantsur> jroll, modulo figuring out situation with requirements in this gate
17:38:12 <dtantsur> cause DIB will be pulling in mitaka reqs, while we'll be pulling in liberty reqs
17:38:17 <jroll> dtantsur: requirements?
17:38:20 <jroll> ooo
17:38:33 <jroll> so yeah, maybe an action item to investigate that and re-evaluate after?
17:38:34 <devananda> this sentence from #2 still doesn't make sense to me: "This means that the old ramdisk will essentially be supported in Mitaka and Newton"
17:38:57 <dtantsur> devananda, it means: if will work with these version of ironic
17:39:03 <jroll> devananda: if we cannot use liberty ironic with master DIB in the gate, we'll need old ramdisk support in ironic master
17:39:07 <dtantsur> cause we won't be removing code actually
17:39:16 <devananda> the deprecation warning was introduced in 8f62743c on 2015-08-04
17:40:10 <devananda> jroll: even though we are well past the required deprecation window already
17:40:19 <jroll> devananda: currently DIB+ironic gate uses ironic master, meaning we would need to keep old ramdisk support to keep that gate working
17:40:31 <jroll> and as DIB does not have stable branches, we need to keep that gate working on master DIB
17:40:45 <devananda> jroll: right. but why do we need to keep that gate working, if DIB and TripleO do not use that ramdisk any longer?
17:40:50 <jroll> there be dragons with master DIB + liberty ironic gate, it may be possible but it is unclear at this time
17:41:00 <jroll> devananda: because it's supported in kilo and liberty?
17:41:14 <jroll> and DIB/tripleo are presumably not the only users of the ramdisk
17:41:18 <devananda> if that project wants to drop support for the bash ramdisk, they should remove the element from dib/msater
17:41:22 <dtantsur> devananda, our kilo and liberty gate also use DIB master (well, at some point of time, but they don't have stable branches..)
17:42:19 <TheJulia> seems like that is the root of the problem.... and honestly a stable branch could be created.. technically speaking
17:42:48 <jroll> right, we can't drop the element from dib/master without pinning DIB in ironic stable jobs, meaning bug fixes can't land on DIB for stable branches of ironic
17:42:52 <dtantsur> tbh I have no clues why DIB has no stable branches.. I guess because stable branches for tripleo is a relatively new idea
17:43:06 <dtantsur> (and officially it's still part of tripleo iirc)
17:43:24 <dtantsur> jroll, yeah, options #4 and #5
17:43:34 <jroll> right, which I think is bad
17:43:54 <lucasagomes> could we pin the stable/liberty branch on a specific version of DIB ? (e.g 1.10.0 idk)
17:43:59 <jroll> I think #2 is the right thing to do, even if it's annoying for us
17:44:00 <devananda> got it. so we end up carrying deprecated code for 3 cycles instead of 1
17:44:12 <jroll> lucasagomes: yes, but then we can't fix it if stable/liberty breaks due to a dib bug
17:44:19 <dtantsur> lucasagomes, that's options #4 and #5. but it will prevent us from getting any bug fixes from them
17:44:39 <lucasagomes> jroll, right
17:44:46 <dtantsur> that might be an unlikely event, that we get broken by that
17:44:51 <dtantsur> but if we do, we're stuck again
17:45:02 <jroll> yep
17:45:05 <devananda> pinning DIB on our stable branch would impact more than just the gate job using the bash ramdisk -- it would affect all our jobs
17:45:16 <dtantsur> all jobs, not only our
17:45:22 <devananda> dtantsur: right
17:45:22 <dtantsur> unless we bypass g-r
17:45:27 <devananda> so I don't think that's viable
17:45:32 <jroll> right, so yet again I propose we don't do that
17:45:36 <devananda> jroll: agreed
17:45:53 <jroll> so I think #2 is the right thing to do
17:46:06 <lucasagomes> ok so let's just do #2 even tho it may take more time
17:46:10 <jroll> if we can gate master DIB against liberty ironic, we could remove the ironic support in mitaka
17:46:11 <sambetts> can't we remove the deprecated code in Ironic in mitaka without deleting the DIB element?
17:46:19 <lucasagomes> it's slow, but less risky
17:46:22 <jroll> if not, we need to wait longer
17:46:28 <devananda> sambetts: not without a stable/liberty branch of DIB
17:46:42 <jroll> but I do propose adding --i-am-a-dummy config that folks must set to use it, as it is unsupported
17:46:44 <devananda> which, tbh, is what I think should happen
17:46:53 <TheJulia> jroll: ++
17:46:58 <NobodyCam> jroll: +++++
17:47:01 <devananda> though I don't recall any longer why DIB doesn' thave stable branches
17:47:07 <dtantsur> devananda, you can try talking to dprince then
17:47:13 <dtantsur> no idea either
17:47:21 <lucasagomes> jroll, sounds reasonable
17:47:46 <dtantsur> so we've converged to 2 options: option #2 and a new option to make DIB create a stable/liberty branch, right?
17:47:53 <jroll> the bad thing about a config like that is we can only check it at runtime, and that's a bad time to explode a build :/
17:48:01 <jroll> dtantsur: yep
17:48:10 <dtantsur> we can try the latter, and fall back to the former if it does not work
17:48:26 <jroll> I'm good with that
17:48:48 <jroll> maybe a stable/mitaka branch if they object to stable/liberty on the grounds that it was months ago
17:49:01 <TheJulia> jroll: it can still be done from a tag in that period of time...
17:49:01 <NobodyCam> ++
17:49:08 <TheJulia> or a commit id
17:49:15 <dtantsur> TheJulia, yes, but I'm not convinced we won't get broken after that :)
17:49:23 <jroll> TheJulia: right, just throwing it out there that stable/mitaka is better than no stable at all
17:49:26 <dtantsur> nobody remembers if that particular commit worked for us..
17:50:15 <TheJulia> dtantsur: :\  Maybe it is worth just taking the hit of breaking and then fixing..
17:50:23 <dtantsur> totally possible
17:50:43 <jlvillal> 10 minutes remaining
17:50:43 <TheJulia> jroll: totally agree with that :)
17:50:47 <dtantsur> especially since we can start with making DIB gate non-voting first
17:50:49 <jroll> okay, so who's going to talk with dprince?
17:51:06 * dtantsur looks at the ceiling
17:51:18 <dtantsur> jroll, okay, okay, I will :)
17:51:29 <jroll> awesome, thank you
17:51:39 * rloo wonders what dtantsur saw on the ceiling
17:51:39 <NobodyCam> your awesome dtantsur Thank you :)
17:51:52 <TheJulia> dtantsur: thank you
17:51:58 <jroll> #action dtantsur to chat with dprince about a stable branch, proceed with #2 regardless of the outcome, but stable branch will help move faster
17:52:12 <dtantsur> :)
17:52:33 <jroll> thanks
17:52:34 <dtantsur> actually looks like devananda has started while we're chatting here
17:52:45 <jroll> #topic Suggestion to remove stable branches from IPA
17:52:52 <jroll> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086981.html
17:53:05 <NobodyCam> I think this is a bad idea
17:53:08 <TheJulia> Given our previous discussion... I'm not sure it is a good idea.
17:53:10 <jroll> tl;dr should we continue to have stable branches for IPA, and should we remove the existing stable/liberty
17:53:23 <dtantsur> removing existing is probably not something we should ever do..
17:53:31 <jroll> I'm actually okay with the former, not okay with the latter
17:53:31 <dtantsur> but what about creating new ones?
17:53:36 <davidlenwell> ++
17:53:37 <lucasagomes> jroll, removing the existing seems quite strange
17:53:54 <jroll> lucasagomes: yeah, I think it's easy to say no to that, but it was asked int he email so I put it here
17:53:54 <devananda> ++ to having stable branches of IPA
17:54:03 <NobodyCam> for all the reasons we just talked about
17:54:03 <lucasagomes> jroll, gotcha
17:54:11 <dtantsur> devananda, you mean, continue creating them (mitaka, etc)?
17:54:16 <jroll> so, we've never actually tested stable/liberty IPA
17:54:16 <devananda> it's a python service, effectively. it exposes a REST API. it has a contract with the ironic 'agent' drivers of a particular release.
17:54:20 <devananda> dtantsur: yes
17:54:21 <jroll> and never needed the stable branch
17:54:23 <lucasagomes> regarding to the email, I think we should backport LIO support for stable/liberty that will allow RDO to move on
17:54:39 <dtantsur> devananda, just a reminder: ironic stable gates use the latest IPA from master
17:54:45 <jroll> lucasagomes: well, no, backporting features isn't okay
17:54:46 <dtantsur> it's not that we could not fix it..
17:55:01 <NobodyCam> lucasagomes: ++
17:55:07 <devananda> if we wanted to introduce a significant change in the agent's API, right now, it would be challenging, because of ^^
17:55:08 <TheJulia> lucasagomes: I think they might need to do that in a downstream branch
17:55:20 <lucasagomes> TheJulia, yeah that could be the case too
17:55:32 <NobodyCam> jroll: i don't see it a feature
17:55:34 <dtantsur> TheJulia, downstream we've switched to IPA 1.1 already. but RDO is not exactly the same thing
17:55:45 <dtantsur> TheJulia, RDO is really just about packaging.. it can't backport features
17:55:59 <TheJulia> dtantsur: is it just pulling strait from master in cases?
17:56:20 <jroll> NobodyCam: it's near the line but I think I disagree
17:56:24 <dtantsur> TheJulia, from master or from the stable branch
17:56:47 <dtantsur> TheJulia, there may be patches, but only for critical issues or for packaging purposes
17:56:47 * TheJulia hopes any regulated environments are aware of the master branch use
17:57:23 <dtantsur> regulated environments should not use RDO master really :)
17:57:27 <lucasagomes> jroll, yeah we can argue on both sides... casue tgtd is not supported on some distros
17:57:35 <lucasagomes> so it may fit in as a bug
17:57:42 <TheJulia> dtantsur: just another argument to always keep stable branches for IPA as well :)
17:57:44 <lucasagomes> if we say we support those distros (centros 7 rhel 7)
17:57:50 <lucasagomes> but it's another discussion...
17:58:04 <NobodyCam> I agree it is close to the line, but I with some support for ipxe / uefi in some driver I see it as bug fixes for the over all feature
17:59:14 <jroll> so I don't think we'll reach a consensus before the end of the meeting, but I'd like to say "why not stable branches?" and also "let's please test liberty with liberty IPA"
17:59:39 <jroll> we can take it to the list from there
17:59:44 <dtantsur> ++
17:59:45 <NobodyCam> ++
17:59:47 <lucasagomes> sounds good
17:59:49 <TheJulia> ++
17:59:55 <jroll> alright, thanks all for joining today
18:00:00 <jroll> we're out of time
18:00:02 <jroll> #endmeeting