17:00:44 <jroll> #startmeeting ironic
17:00:45 <openstack> Meeting started Mon Aug 29 17:00:44 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:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:46 <jroll> hey everyone
17:00:49 <openstack> The meeting name has been set to 'ironic'
17:00:51 <vdrok> o/
17:00:52 <milan> o/
17:00:53 <lucasagomes> hi o/
17:00:56 <rpioso> o/
17:00:58 <mat128> o/
17:01:04 <mari0jv> o/
17:01:05 * mat128 thought he was late by a few seconds
17:01:09 <rloo> o/
17:01:18 <krtaylor> o/
17:01:32 <jroll> as always, agenda here:
17:01:35 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:01:44 <jlvillal> o/
17:01:47 <xhku> o/
17:01:53 <dtantsur> o/
17:01:56 <jroll> #topic announcements and reminders
17:02:00 <jroll> so a few things here
17:02:29 <jroll> this is the feature freeze week for most of openstack, and where we start to reject large/risky features (we don't block all features always at FF time)
17:02:41 <jroll> it's also client freeze, so we need to finish up ironicclient features
17:03:02 <devananda> o/
17:03:03 <rama_y> o/
17:03:04 <wajdi> o/
17:03:23 <NobodyCam> o/
17:03:25 <rloo> jroll: so we also follow feature freeze schedule?
17:03:41 <jroll> so please review the OSC patches, let's get those in, I'd like to talk more in open discussion about what we want to push to ocata, if we have time
17:03:55 <jroll> rloo: not necessarily, but I've been saying for weeks we should start slowing down this week
17:04:15 <rloo> jroll: ok, just that feature freeze AND client in same week is too much i think
17:04:37 <jroll> rloo: well, that's the normal schedule for openstack :)
17:05:00 <rloo> jroll: right, but i thought we didn't follow it strictly. i need to reread the spec.
17:05:09 <rloo> jroll: anyway, don't mind me :)
17:05:21 <jroll> rloo: we don't, we just arbitrarily choose a date to stop being crazy :)
17:05:51 <rloo> jroll: ok, then let's pick next week for feature freeze. too crazy for both to be this week.
17:06:05 * dtantsur ++ for next week instead
17:06:15 <jroll> rloo: I think we need to start thinking about what to give the boot this week, but okay
17:06:52 <rloo> jroll: i'm fine if you/we want to think about what to punt, but i'm concerned that if feature freeze is this week, there will be too many patches that 'need to be reviewed'
17:07:38 <devananda> I think of it this way: we need to complete the things that are close to completion, and postpone (for a couple weeks) the things that are not.
17:07:58 <devananda> rloo: there has been a very short list of things that jroll has been asking us all to look at, for several weeks now
17:07:59 <devananda> this isn't news
17:08:00 <rloo> devananda: right, but we can complete ironic stuff after this week. we cannot do so for client.
17:08:49 <jroll> let me put it a third way: "let's think about what to freeze" doesn't mean "let's rush everything in", it means "let's decide what won't make it"
17:09:04 <devananda> jroll: ++
17:09:07 <rloo> jroll: I'm good with that!
17:09:17 <mat128> +1
17:09:36 <rloo> jroll: sorry, is that what we are going to discuss in today's meeting? like now?
17:09:52 <jroll> rloo: not now. I'd like to start the conversation in open discussion if we have time
17:10:04 <rloo> jroll: ok, thx for clarifying
17:10:22 <jroll> so one more announcement, next monday is a US holiday
17:10:35 <jroll> so I won't be here for the meeting, does someone else want to run it or do we prefer to skip it?
17:10:57 <rloo> also canadian holiday. i won't be here either
17:11:01 <mat128> it's also a Canadian holiday
17:11:02 <mat128> ^
17:11:09 <devananda> +1 skip
17:11:10 * jlvillal looks at the European folks...
17:11:21 <lucasagomes> I will be around if there's a meeting
17:11:33 <lucasagomes> I can run if there's enough people
17:11:55 <dtantsur> ditto, I'll be here
17:12:00 <jroll> okay, let's plan on having it and lucasagomes can shut it down quickly if there aren't enough people
17:12:25 * lucasagomes adds to his todo
17:12:28 <jroll> any other announcements/reminders?
17:12:32 <devananda> fyi, I'm dealing with a case of conference crud AND moving this week, so I will have limited availability. going to focus on reviews and emails, since those are asynchronous, and resting when I can.
17:13:39 <jroll> good to know, sorry to hear :(
17:14:07 <jroll> #topic subteam status reports
17:14:22 <jroll> those are here, starting with line 93:
17:14:24 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:14:53 <jroll> the nova console patch was -2'd again this morning, the un -2 was by mistake
17:15:15 <rloo> jroll: yes, so much for dashing our hopes
17:15:20 <rloo> dtantsur: what's the critical bug?
17:15:22 <jroll> heh
17:15:26 <JayF> jroll: should we start cleaning up things off that which aren't landing in newton? like rescue?
17:15:42 <dtantsur> rloo, I suspect we haven't close the previous one, lemme check
17:15:57 * thiagop joins late
17:15:58 <jroll> JayF: eh, I don't think it's a big deal to have them and have no updates
17:16:03 <JayF> okie dokie
17:16:05 <jroll> they'll probably jump back on for ocata
17:16:40 <rloo> is there more to be done wrt keystone policy support?
17:16:40 <dtantsur> rloo, I can't find it; maybe my script derped..
17:16:57 <dtantsur> or wait, maybe another project
17:16:59 <jroll> rloo: there was a docs patch, it may have landed last week though. devananda ?
17:17:02 <JayF> rloo: I think so
17:17:04 <rloo> thx mystery person :)
17:17:05 <lucasagomes> rloo, I think there are docs
17:17:05 <JayF> let me find the patch
17:17:15 <dtantsur> rloo, oh, https://bugs.launchpad.net/ironic-python-agent/+bug/1611528
17:17:15 <openstack> Launchpad bug 1611528 in ironic-python-agent "IPA for stable/liberty unit tests fail with AssertionError: InspectionError not raised by extension_manager" [Critical,In progress] - Assigned to John L. Villalovos (happycamp)
17:17:19 <JayF> oh, instance secrets stuff merged \o/
17:17:22 <JayF> and the docs
17:17:26 <dtantsur> jlvillal, we got it fixed, right?
17:17:26 <JayF> I think keystone policy is done!!!
17:17:28 <jroll> oh neat
17:17:30 <jroll> \o/
17:17:35 <JayF> wooo hooo ty gj devananda
17:17:35 <jlvillal> dtantsur: It has been merged
17:17:41 <dtantsur> awesome, closing
17:17:44 <lucasagomes> JayF, yay
17:18:02 <rloo> JayF: there's one more patch for keystone policy support according to mystery person: https://review.openstack.org/#/c/353696/
17:18:18 <mat128> rloo: I think that's deva
17:18:36 <rloo> mat128: yeah, i just looked at the colours/names :)
17:18:44 <jroll> I don't think that's realted to policy
17:18:54 <JayF> It's kinda more related to new agent api
17:18:58 <devananda> rloo: keystone policy docs patch landed. there are two more patches I'd like to land, though
17:19:00 <jroll> right
17:19:12 <devananda> rloo: one for /heartbeat, and one for unit tests, but I'm having trouble getting this one not to break other tests
17:19:32 <JayF> devananda: I'd call the /heartbeat one more related to agent api promotion tbh
17:19:38 <devananda> JayF: fair
17:19:55 <rloo> devananda: ok, good to know. doesn't matter where we categorize /heartbeat one, just make sure it is linked to appropriate bug/rfe
17:19:59 <devananda> in which case, there's only one left re: policy: https://review.openstack.org/350177
17:20:34 <jroll> ++, I'd like to get that one done
17:20:35 <lucasagomes> devananda, added myself to it, will take a look once it's not WIP anymore
17:21:01 <devananda> lucasagomes: if you have time / brain power, please look at it now. I've WIP'd it only because I know it's not safe to land yet
17:21:45 <lucasagomes> devananda, ack, unittests for py3+ is failing tho (I will look afte rthe meeting)
17:22:12 <mat128> I'd like the upper-constraints stuff to land before cutting final tags, so official ramdisks are built correctly (https://review.openstack.org/#/q/topic:bug/1616554+project:openstack/ironic-python-agent)
17:22:34 <mat128> dtantsur mentioned the initial bug (https://bugs.launchpad.net/ironic-python-agent/+bug/1611528)
17:22:34 <openstack> Launchpad bug 1611528 in ironic-python-agent "IPA for stable/liberty unit tests fail with AssertionError: InspectionError not raised by extension_manager" [Critical,Fix released] - Assigned to John L. Villalovos (happycamp)
17:22:48 <jroll> yeah, we need to fix that
17:22:56 <mat128> it's only missing eyes on the master change
17:22:57 <jlvillal> +1
17:22:59 <jroll> rloo: ^ there's your critical bug fix
17:23:10 <jroll> anything else on subteam reports?
17:23:19 <rloo> jroll: thx :)
17:23:21 <jlvillal> mat128: Thanks for doing a pre-backport to mitaka and liberty to show that it works :)
17:23:43 <mat128> :D
17:24:11 <jroll> alright let's keep rolling
17:24:20 <jroll> #topic summit session allocations
17:24:26 <jroll> there's a few session ideas on the pad:
17:24:32 <jroll> #link https://etherpad.openstack.org/p/ironic-ocata-summit
17:24:57 <jroll> last week we talked about 3/4 fishbowl/workroom
17:25:04 <lucasagomes> jroll, how many session we have again ?
17:25:06 <lucasagomes> oh ok
17:25:15 <jroll> we need to decide how many to ask for :)
17:25:32 <jroll> we did 5/5 last time, need to do less this time (less slots, more teams)
17:25:44 <rloo> jlvillal: for the qa/gate stuff, that is ok as a workroom?
17:25:54 <jlvillal> rloo: Yep. Best as a work room.
17:26:19 <jlvillal> Or happy to do it as a find an empty spot somewhere to do it, if we get tight. We did that last time on Grenade stuff.
17:26:26 <rloo> anything involving neutron needs a fishbowl i think :)
17:26:33 <jroll> indeed
17:26:39 <jroll> keep in mind none of these are for sure
17:26:39 <dtantsur> heh
17:26:57 <JayF> Will we need to talk about driver comp or boot from volume? I know both have specs that are very close
17:27:03 <dtantsur> noooooooooooooo
17:27:06 <jroll> LOL
17:27:10 <JayF> but I think all the answers are done already for those?
17:27:12 <JayF> lol
17:27:15 <dtantsur> I man, boot from volume - maybe
17:27:22 <rloo> dtantsur: i think that if we want nova folks wrt deployment steps, it might be a fishbowl too, not sure.
17:27:28 <JayF> dtantsur: I think we properly interpreted your cry of no :P
17:27:37 <dtantsur> JayF, I think so too :D
17:28:03 <dtantsur> rloo, yes, maybe.. actually we have 2 questions there: how we do it (a workroom) and how to interact with nova (fishbowl)
17:28:09 <dtantsur> but we don't have that much space, so....
17:28:12 <devananda> one thing to keep in mind - ocata is going to be a short cycle
17:28:18 <dtantsur> true
17:28:25 * devananda puts his former-TC-hat on
17:28:26 <jroll> yep
17:28:39 <devananda> projects are encouraged to use the short cycle to focus on stabilization and internal / core work
17:28:44 <devananda> rather than major new features that require design efforts
17:28:50 * devananda takes that hat off
17:28:59 <dtantsur> so, no driver comp? :)
17:29:00 <JayF> driver comp sounds like core work
17:29:01 <jroll> devananda: well, nobody has come out and officially encouraged that :)
17:29:09 <JayF> dtantsur: I mean, driver comp sounds like /exactly/ that
17:29:18 <mat128> ^+1
17:29:18 <jlvillal> If anyone has presentations and want to run a session. Please note conflict times.
17:29:22 * jroll has only seen that encouragement in hallway track
17:29:27 <devananda> jroll: i'm surprised to hear that. because I've been seeing folks recommending that for a while.
17:29:28 <dtantsur> heh, ok, ok, I gotta get some work done :)
17:29:30 <jroll> jlvillal: don't worry, I'll take care of those :)
17:29:36 <rloo> driver comp stuff has already started, design has been done, right dtantsur? i think it is good to go
17:29:39 <jlvillal> okay :)
17:29:45 <JayF> devananda: do you have specific stuff in mind when you say that?
17:29:49 <dtantsur> rloo, yes, I'm half-kidding
17:29:50 <devananda> dtantsur: driver comp is internal work, IMO
17:29:58 <JayF> devananda: I'm just curious, I feel like we do a decent job of promoting internal work in all cycles :)
17:30:03 <jroll> devananda: I've seen 1) lots of support for stabilization cycles, and 2) lots of people saying ocata is a good candidate, but not 3) TC folks recommending projects do such a thing
17:30:04 <vdrok> yeah, it's deployment steps that need to wait I think as there is no design yet
17:30:08 <dtantsur> I'm pretty sure I want to finish THAT asap
17:30:31 <dtantsur> deployment steps, yeah... though our RAID approach worries me a lot
17:30:39 <dtantsur> let's at least discuss if we even want such a thing
17:30:41 <jroll> devananda: nor have I seen 4) us discuss whether we should have ocata be a stablization cycle (yet)
17:30:43 <mat128> jroll: I think it's always a good idea to promote internal improvement, otherwise we won't be able to deliver features as quickly down the road
17:30:44 <devananda> jroll: I see. thanks. perhaps its time they say that more loudly, then
17:30:45 <rloo> so there are 5 suggestions here. we don't know if any of these will happen. how many other ideas do we think will be proposed/we want to have at the summit?'
17:30:49 <rloo> is 3/3 enough then?
17:30:56 <jroll> mat128: I'm not disagreeing with the concept :)
17:31:17 * dtantsur rephrases his proposal
17:31:21 <vdrok> looking at the current list 3 fishbowls should be enough
17:31:46 <devananda> JayF: I think we strike a balance between feature work and core work. like every project does.
17:31:49 <jroll> rloo: I suspect we aren't even close to "all proposals in" yet
17:31:59 <jroll> I think I'm okay with 3/3, 3/4 would be nice
17:32:20 * mat128 digs his "write a spec for just-in-time RAID configuration" todo item from the midcycle
17:32:25 <JayF> devananda: I'm just saying; I'm not opposed to an idea of focusing on internal stuff; but I don't see it as being useful unless we have a list of specific internal/stabilization things we want to work on
17:32:29 <rloo> jroll: yeah, i think you're right, but in light of the discussion above wrt new features/design, etc etc... let's try to focus on stuff that is *doable* in ocata
17:32:36 <jroll> rloo: +1
17:33:00 <rloo> jroll: how are we going to decide 3/3 or 3/4 or x/y?
17:33:11 <lucasagomes> rloo, +1 I think the design sessions should be about things that are possible to accompilish in that cycle
17:33:21 <jroll> rloo: like this
17:33:22 <lucasagomes> or at least parts of it
17:33:27 <jroll> is anyone opposed to asking for 3/3 and a friday afternoon meetup?
17:33:28 <jlvillal> Should we add a "discuss project priorities" session?
17:33:54 <rloo> jlvillal: oh yeah. don't we typically have some sort of recap and priorities thing?
17:33:55 <dtantsur> jlvillal++ the most important session
17:34:00 * jroll added it
17:34:01 <jlvillal> heh
17:34:01 <lucasagomes> jroll, it's fine to me
17:34:41 <jroll> is anyone opposed to asking for 3/3 and a friday afternoon meetup?
17:34:49 <jroll> lucasagomes: thanks for answering :)
17:35:07 <dtantsur> do we really need this format meetup?
17:35:10 <dtantsur> * formal
17:35:15 <vdrok> I'm not opposed, but when do we need to decide? Maybe something else will be added
17:35:27 <vdrok> is there some date set for this?
17:35:28 <rloo> dtantsur: last summit, you had an inspector session. do you think you want one for ocata?
17:35:30 <devananda> JayF: my point is, it's a shorter cycle. let's use the design summit for ironing out the details of things we can get done in that time and polishing ironic. I odn't have a specific list yet, but that's what we're talking about now :)
17:35:33 <jroll> dtantsur: if nothing else, for space, I've found them useful
17:35:34 <TheJulia> no opposition here
17:35:43 <dtantsur> rloo, oh, inspector... lemme think
17:35:45 <jroll> vdrok: need to decide now, wednesday is the deadline
17:35:52 <jroll> (as we said last meeting)
17:36:11 <dtantsur> rloo, I'd say no. We'll probably spend the whole Ocata implementing HA as agreed previously. milan?
17:36:28 <milan> dtantsur, yeah
17:36:41 <milan> unless we land the state patch, all is pending
17:36:46 <jroll> I'm going to timebox this 3 minutes from now, so if you oppose 3/3 and half day meetup speak now please :)
17:36:51 <rloo> jroll, any need to discuss with nova, the dynamic <whatever, i forgot what it is called>, resource classes, etc?
17:37:14 <jroll> rloo: I don't think so right now, if there is we can steal a nova session
17:37:20 <JayF> rloo: I think we nailed most of that during the mid-cycle
17:37:28 <jroll> yeah, it's pretty solid
17:37:33 <jroll> just needs effort :)
17:37:33 <lucasagomes> rloo, resource classes?
17:37:48 <rloo> lucasagomes: you know, that new node.resource_class thingy
17:38:01 <rloo> and/or a fishbowl to describe how all that is going to work. but let's just document it.
17:38:23 <milan> dtantsur, rloo but I've just added #6 to see if people +1 and/or add more topics, but cool not having one
17:38:31 <lucasagomes> rloo, yeah, I'd like it to see the spec merged in nova first. Not sure a session on it, I think we should just keep reviewing the spec and making sure it covers our use case
17:38:55 <rloo> milan: just land it :)
17:39:00 <dtantsur> jroll, I'd ask for 3/4 and I don't care about the meetup too much
17:39:12 <dtantsur> but if people are fine with 3/3, I'm fine too
17:39:22 <milan> rloo, roger that :)
17:39:28 <jroll> yeah, trying to be a good citizen for the additional projects and such
17:39:46 <dtantsur> we're already down from 5/5, right? :)
17:39:46 <rloo> +1 (reason for 3/3)
17:39:59 <dtantsur> anyway, they are free to refuse us
17:40:18 <dtantsur> what I'd avoid is to have a big mess of undiscussed stuff on Friday evening
17:40:39 <jroll> sure
17:40:57 * rloo wonders how useful the meeting would be, on a fri aft
17:41:02 <rloo> s/meeting/meet up/
17:41:13 <jroll> okay, I'm going to ask for 3/4 and say we're also fine with 3/3
17:41:20 <jroll> rloo: keep in mind it's only 4 day summit
17:41:39 <jroll> let's move on
17:41:55 <jroll> I'm bumping this up from open discussion, vdrok in the future please use the 'discussion' topic, not open discussino :)
17:42:02 <jroll> #topic client and libraries deprecation policy - is it the same as for ironic itself?
17:42:20 <vdrok> oops, I already forgot about that :)
17:42:28 <vdrok> so it should be pretty short
17:42:33 <rloo> i had assumed that the clients also followed the same deprecation policy
17:42:36 <JayF> Me too
17:42:48 <rloo> and am assuming osc does too
17:42:51 <vdrok> do we need to explicitly list the tag for all our libs/client in the governance?
17:43:00 <jroll> ditto here
17:43:08 <jroll> I'm not sure people care too much about tags on clients
17:43:16 <dtantsur> ++ for a tag, ++ for following the usual policy
17:43:25 <jroll> we also need upgrade testing to put a tag there :)
17:43:45 <jroll> which is odd in a client (I have no clue what that would look like)
17:43:46 <devananda> let me dig for references for a minute, but I believe client and libs follow a different deprecation policy than servers, actually
17:44:29 <devananda> because users / application developers upgrade libraries very differently than how operators upgrade services
17:45:51 <jroll> mmm, yeah, could be
17:45:54 <vdrok> hm ,yeah, It uses an automated test to verify that configuration files are forward-compatible from release to release, it seems like we should not do it for libs
17:46:04 <devananda> also to note, the assert-follows-standard-deprecation tag only applies to services
17:46:07 <devananda> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
17:46:09 <jroll> vdrok: is your question about if we should have the tag or follow the policy?
17:46:30 <vdrok> jroll: my question is, what this policy is
17:46:31 <devananda> we can't tag the client or lib with that tag
17:46:43 <vdrok> the governance was the first place I went to
17:47:03 <jroll> ah
17:47:15 <rloo> i don't think we need to tag the library. whatever uses the library, is the thing that should be tagged i think
17:47:18 <jroll> yeah, we should follow the standard openstack guidelines, whatever those are
17:47:26 <vdrok> and there is troveclient that has the tag for some reason
17:47:57 <devananda> here's a thing to think about, wrt deprecation policy of the client
17:48:03 <jroll> devananda: can I make an action item for you to find out what that is?
17:48:09 <devananda> jroll: sure
17:48:18 <jroll> thanks
17:48:36 <devananda> so, imagine I'm running an old version of hte service, and you download the current client with "pip install python-ironicclient" and it doesn't work
17:49:22 <jroll> right right, we need to support older services, I agree
17:49:28 <devananda> yea. so, I know oslo folks had this discussion a while back
17:49:39 <devananda> I will try to find the docs on that, or an email from the archive
17:49:46 <jroll> yep
17:50:01 <jroll> sounds good, anyone have more questions on this topic?
17:50:10 <dtantsur> so we have two things that we can deprecate: support for API and client features themselves, right?
17:50:19 <dtantsur> the first one is harder to deprecate
17:51:16 <devananda> dtantsur: also, API interfaces in the client or library APIs
17:51:33 <vdrok> it's going to be a lot of deprecated stuff to remove from client in O, so I wondered how long do we wait and what else do we do, like bumping major versions etc
17:51:45 <jroll> vdrok: what is up for removal in O?
17:51:49 <devananda> vdrok: do you have a list of the things to remove?
17:51:56 <mat128> vdrok: you can still talk to an icehouse nova with "pip install python-novaclient"
17:52:14 <vdrok> nope, off the top of my head some options and commands from osc
17:52:22 <vdrok> like baremetal create/delete
17:52:57 <devananda> mat128: indeed. and I will want to be able to continue talking to a Kilo Ironic service with our current client libs.
17:53:04 <rloo> baremetal create (the one that did a baremetal node create), baremetal delete and baremetal list I think
17:53:06 <vdrok> also we can deprecate HTTPClient at some point when we fully switch to keystoneauth sessions
17:53:22 <devananda> vdrok: umm. if we remove things from the osc "baremetal" cli, we're likely to immediately break downstream users who have shell scripts that depend on them
17:53:22 <mat128> devananda: agree, I was just illustrating the point
17:53:39 <devananda> mat128: good illustration :)
17:53:45 <vdrok> devananda: yeah, but there are warnings and stuff
17:53:49 <jroll> command line options/commands/etc are fine to remove with a reasonable deprecation period imo
17:54:01 <mat128> vdrok: didnt see any last time
17:54:07 <rloo> i think it is worth asking osc, since it is a plugin to osc
17:54:15 <rloo> i thought osc just deprecated some commands too
17:54:27 <vdrok> mat128: hm - https://github.com/openstack/python-ironicclient/blob/master/ironicclient/osc/v1/baremetal_create.py
17:54:27 * jroll thought we already asked them about these things
17:54:30 <vdrok> they are there tho
17:55:03 <mat128> vdrok: I thought you said "I get warnings and stuff when talking to icehouse nova using latest-and-greatest novaclient"
17:55:21 <vdrok> mat128: ah, no, was talking about osc :)
17:55:32 <mat128> https://github.com/openstack/python-ironicclient/blob/master/ironicclient/osc/v1/baremetal_create.py#L38
17:55:37 <mat128> so in the P cycle we wont be able to create new nodes?
17:55:41 <mat128> or that simply changed names?
17:55:52 <jroll> it's 'baremetal node create' vs 'baremetal create'
17:55:57 <vdrok> yup
17:55:59 <jroll> s/vs/replaces/
17:56:08 <jroll> I'm going to cut this off because we're getting into details now
17:56:10 <rloo> oh, osc deprecated some stuff and did a major version bump
17:56:14 <jroll> devananda is going to find policies for us
17:56:25 <vdrok> thanks devananda :)
17:56:31 <jroll> #topic open discussion
17:56:37 <jroll> 3.5 minutes, anyone have anything?
17:56:45 <rloo> http://lists.openstack.org/pipermail/openstack-dev/2016-August/102031.html osc release
17:57:15 <vdrok> a request to review the portgroups things when we are done with client :)
17:57:33 <devananda> one quick announcement / request
17:57:40 <rloo> vdrok: will any of the portgroup stuff change as a result of (if) there is a discussion at summit?
17:57:45 <devananda> I did some hacking on a new review dashboard
17:57:57 <devananda> #link http://goo.gl/02QBkA
17:58:16 <devananda> I haven't proposed it to replace the current official dashboard yet, so I'd like feedback on if you think it should
17:58:24 <vdrok> rloo: the one thing that is proposed for the summit about dynamic portgroups is more like an enhancement of what is proposed now
17:58:25 <jroll> nice \o/
17:58:30 * dtantsur found gertty dashboards too
17:58:34 <devananda> also, if you use gertty, I've pasted a couple gertty dashboards that are similar to this one
17:58:35 <jroll> at first glance, looks nice
17:58:46 <devananda> http://paste.openstack.org/show/am3tT9JmEeUu6t81jtrx/
17:58:47 <vdrok> rloo: just adding more stuff, but no big changes on ironic side
17:58:53 * milan wanted to get opinions about landing Inspector state patch before FF https://review.openstack.org/#/c/348943/
17:58:55 <dtantsur> yay, gertty
17:58:56 <rloo> vdrok: thx, good to know
17:58:58 <lucasagomes> looks nice
17:59:09 <jroll> #link http://paste.openstack.org/show/am3tT9JmEeUu6t81jtrx/
17:59:12 <NobodyCam> devananda: nice :)
17:59:19 <TheJulia> devananda: I like :)
17:59:22 <jlvillal> dtantsur: You can do some of that in gertty too. Custom searches. Not sure about the 'foreach' thing
17:59:31 <devananda> gertty doesn't support some of the queries in that new dashboard yet
17:59:41 <devananda> but I realy like having a gertty page for "stable backports" for all ironic projects
17:59:45 <rloo> devananda: nice. could you maybe indicate what 'Recently' Proposed is? x days?
17:59:59 <devananda> rloo: 1 week.
18:00:08 <jlvillal> +1 on looks good at first glance
18:00:10 <rloo> devananda: and what's a 'small thing'?
18:00:14 <devananda> rloo: < 25 LOC
18:00:23 <jroll> okay, we're at time
18:00:26 <jroll> back to channel!
18:00:28 <jroll> #endmeeting