17:00:04 <NobodyCam> #startmeeting Ironic
17:00:04 <NobodyCam> #chair devananda
17:00:04 <NobodyCam> Welcome everyone to the Ironic meeting.
17:00:04 <openstack> Meeting started Mon Jun  1 17:00:04 2015 UTC and is due to finish in 60 minutes.  The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:07 <openstack> The meeting name has been set to 'ironic'
17:00:08 <openstack> Current chairs: NobodyCam devananda
17:00:14 <devananda> o/
17:00:14 <NobodyCam> Of course the agenda can be found at:
17:00:15 <NobodyCam> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:00:22 <NobodyCam> #topic Greetings, roll-call and announcements
17:00:22 <NobodyCam> Roll-call: Who's here for the Ironic Meeting?
17:00:30 <NobodyCam> \o/
17:00:46 <TheJulia> o/
17:00:56 <dtantsur> o/
17:00:58 <thiagop> o/
17:01:03 <NobodyCam> we may have folk joining late as there is a neutron / ironic meeting just ending in OS-meeting-4
17:01:09 <cinerama> hi
17:01:15 <gabriel-bezerra> o/
17:01:15 <jroll> \o hello hello
17:01:16 <NobodyCam> welcome all
17:01:21 <jlvillal> o/
17:01:36 <NobodyCam> #topic announcements:
17:01:39 <NobodyCam> Devananda is in Las Vegas at HP Discover promoting Ironic
17:01:53 <NobodyCam> we all survived the summit
17:01:56 * dtantsur fixes to "HP Inspect" automatically
17:02:23 <jroll> lol!
17:02:23 <krtaylor> o/
17:02:28 <clif_h> o/
17:02:30 <devananda> dtantsur: LOL!
17:02:38 <_lintan> o/
17:02:41 <rloo> o/
17:02:55 <Nisha> o/
17:02:55 <devananda> and yes, I'm in the belly of the beast
17:03:08 <NobodyCam> welcome back everyone. :)
17:03:11 <devananda> and let me tell you, it smells
17:03:20 <krtaylor> hehheh
17:03:46 <NobodyCam> any announcements before we start the ball rolling?
17:04:13 <devananda> there were a few large discussion threads started last week relating to ironic. I dont have all the links prepared - but I hope everyone is watching the -dev mailing list and saw them
17:04:34 * devananda has no announcements
17:04:37 <NobodyCam> #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/065072.html
17:04:56 <NobodyCam> that is a link to the summit recap email devananda sent out last week
17:05:03 <NobodyCam> Thank you devananda :)
17:05:51 <NobodyCam> #topic SubTeam: status report are posted on the Whiteboard
17:05:52 <NobodyCam> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:06:03 <NobodyCam> thank you all for the updates
17:06:33 <NobodyCam> looks like 3rd party ci is almost ready for the iLo drivers ... awesome news
17:06:46 <rloo> irmc seems to be the only new update for this week?
17:06:50 <jroll> NobodyCam: that looks old
17:06:57 <devananda> dtantsur: looks like the bug section is overdue for an update
17:06:58 <jroll> "hopefully will be done before summit"
17:07:05 <NobodyCam> "doh"
17:07:30 <dtantsur> devananda, yeah sorry, it was a busy aftersummit week
17:07:35 <devananda> dtantsur: indeed :)
17:07:42 <dtantsur> devananda, I did triage a couple of bugs, but I forgot to update the stats
17:08:00 <devananda> on the topic of third party CI, we are going to need some central place to consolidate periodic CI job runs
17:08:19 <devananda> feedback that I've gotten is that many of hte vendors wont be able ot keep up with the patch rate -- iow, they cant test every patch
17:08:33 <jroll> :(
17:08:50 <devananda> and so we need to create a "place" where periodic 3rd party CI jobs can post results AND where we'll all see it
17:08:55 <devananda> so we can, you know, spot failures
17:09:03 <devananda> if not proactively, at least reactively
17:09:07 * dtantsur updated whiteboard
17:09:11 <krtaylor> there was a session on that at summit
17:09:11 <rloo> can they test *only* gate/merges? or is that even too many?
17:09:11 <devananda> dtantsur: ty
17:09:14 <NobodyCam> dtantsur: TY
17:09:15 <krtaylor> https://etherpad.openstack.org/p/YVR-QA-testing-beyond-the-gate
17:09:38 <devananda> rloo: some might be able to, yes
17:09:45 <NobodyCam> #link https://etherpad.openstack.org/p/YVR-QA-testing-beyond-the-gate
17:09:56 <krtaylor> that is a periodic dashboard proposal
17:10:26 <devananda> rloo: but there is the further need for us to have periodic jobs *anyway*, eg for other upstream things like upgrade testing that takes 2 hours per run
17:10:27 <NobodyCam> krtaylor: awesome I will try and look afterthe meeting
17:10:29 <krtaylor> we have several 3rd party requirements to be able to push results, non-gerrit patch based
17:11:02 <rloo> yeah, it would be good to have periodic jobs
17:11:56 <dtantsur> rloo, what's the use of testing in gate? if it's voting, it will annoy people whose patch just got approved. If it's non-voting it's the same as just running a job on master from time to time - it won't help a reviewer
17:11:58 <NobodyCam> if we have time lets come back to this
17:12:00 <devananda> thanks for the link, krtaylor. good stuff
17:12:12 <krtaylor> sure, np, I think it will be a requirement for us to start having in-tree/out-of-tree discussions, start with periodic
17:12:23 <rloo> dtantsur: to be able to pinpoint when/if a particular patch causes the failure.
17:12:53 <dtantsur> hmm, right
17:12:55 <jlvillal> rloo: dtantsur: Wouldn't periodic just run against the tip?
17:12:56 <devananda> dtantsur: a non-voting test run on the gate could still be used to isolate a change that introduced a failure to a single patch, rather than a window of time (test_time - last_successful_test_time)
17:13:12 <dtantsur> understood, thanks :)
17:13:16 <rloo> jlvillal: yeah, it'd run against tip but then you'd need to see 'what changed' since last test
17:13:28 <devananda> let's move on -- I think we all agree we need to have a place to collate periodic job test results
17:13:31 <jlvillal> rloo: Okay.
17:13:47 <NobodyCam> ok moving on.
17:13:51 <NobodyCam> #topic Neutron meeting recap
17:14:02 <NobodyCam> jroll: can you cover this one
17:14:08 <jroll> ohai
17:14:20 <jroll> so we had the first ironic/neutron integration meeting this morning
17:14:31 <jroll> it went pretty well overall and we made some good plans
17:14:54 <devananda> jroll: thx for covering that [while I was on a plane] :)
17:15:04 <jroll> there will be specs incoming from BertieFulton and myself this week, around "how do we store physical network info" and "how do we flip around networks", respectively
17:15:19 <jroll> we *shouldn't* need nova/neutron specs for this stuff, but we might. there will be nova changes.
17:15:45 <jroll> be on the lookout for those specs!
17:15:51 <jroll> that's all I have for now, I think
17:15:53 <jroll> devananda: np :)
17:16:06 <NobodyCam> awesome stuff jroll
17:16:08 <NobodyCam> Thank you
17:16:19 <rloo> jroll: i guess we just need to be mindful if we need nova specs, to get them in before the cutoff date
17:16:33 <NobodyCam> looking forward to all the new toys for ironic
17:16:37 <jroll> rloo: oh, we will :)
17:16:39 <devananda> ++ what rloo said
17:16:53 <jroll> rloo: I've already started on nova patches to stay ahead of the game
17:17:13 <rloo> jroll: awesome!
17:18:09 <devananda> shall we move on?
17:18:10 <NobodyCam> any questions for jroll (or anyone) on this?
17:18:16 <NobodyCam> ack
17:18:18 <rloo> jroll: do we consider neutron/ironic a 'subteam'? (wondering if we want weekly status)
17:18:53 <dtantsur> ++ for weekly status
17:18:53 <jroll> rloo: idk, I'm happy to give weekly updates
17:18:55 * jlvillal would vote +1
17:18:58 <devananda> there is a separate IRC meeting for this effort - so yea, I'd call it a subteam
17:18:59 <NobodyCam> I was expection we would just bug jroll for status' as he did the first one
17:19:04 <jroll> whether official subteam or whatever
17:19:06 <NobodyCam> lo
17:19:07 <jroll> cool
17:19:15 <NobodyCam> ok moving on.
17:19:17 <rloo> ok, adding it to our etherpad/subteams
17:19:31 <NobodyCam> ty rloo
17:19:31 <jroll> ty
17:19:41 <NobodyCam> #topic Should Ironic modify filesystems on disk
17:19:52 <NobodyCam> this was added by jayf
17:20:00 <NobodyCam> is he here?
17:20:07 <devananda> the spec has been up for over a month now
17:20:27 <NobodyCam> #link https://review.openstack.org/#/c/173142
17:20:38 <NobodyCam> it has a -2 on it
17:20:46 <devananda> I've objected to it, and JayF has -2'd it, because it proposes that IPA mount every file system on the host, scan for a file named "fstab" and then modify that file
17:21:05 <devananda> writing the configdrive as a raw file and creating a loopback device for it
17:21:10 * NobodyCam would vote -2
17:21:33 <NobodyCam> we should not touch users files
17:21:37 <devananda> to apparently get around issues that one operator is having with configdrive partition taking up more space than they want to give it
17:21:41 <NobodyCam> welcome JayF
17:21:54 <devananda> and/or avoid having too many primary partitions
17:21:56 <JayF> hey, sorry for being late
17:22:04 <rloo> would be good to have the submitter of that spec here too
17:22:17 <natorious> JayF: #topic Should Ironic modify filesystems on disk
17:22:23 <jroll> I'm also -$vote on this, fwiw
17:22:30 <jroll> whether that's -1 or -2
17:22:30 <devananda> rloo: indeed, but I don't see jxiaobin anywhere on IRC
17:22:42 <rloo> devananda: maybe they didn't know (or diff time zone).
17:22:48 <JayF> My primary concern is that today we don't touch filesystems on disk at all, and it's a support matrix I'm not sure we should take on
17:22:52 <devananda> timezone may make that hard. IIRC, he is in korea
17:23:03 <rloo> I haven't read the spec, but if we can address the person's concerns some other way, seems like that would be better
17:23:15 <BadCub> This spec is basically to satisfy one user's use-case?
17:23:17 <JayF> The idea of not only writing out a file to disk, but modifying configs makes Ironic have knowledge distribution/OS + filesystems required
17:23:27 <JayF> moreso than it does today
17:23:36 <devananda> I believe the boundary between user data and operator control plane needs to be (at least within upstream codebase) inviolate
17:23:49 <devananda> there are clearly defined APIs for passing data into the user's instance (read: cloud-init)
17:23:58 <devananda> but going in and mucking with /etc/fstab is NOT one of them
17:24:11 <NobodyCam> devananda: ++
17:24:15 <JayF> ++
17:24:19 <gabriel-bezerra> ++
17:24:25 <dtantsur> ++
17:24:28 <BadCub> ++
17:24:29 <TheJulia> ++
17:24:33 <clif_h> ++
17:24:40 <Nisha> ++
17:24:41 <jroll> ^^
17:24:48 <devananda> heh. well. that's pretty clear :)
17:24:49 <NobodyCam> so this spec needs to be re-worked
17:24:56 <rloo> that seems fair enough. I see that jxiaobin is a new contributor so perhaps someone can spend a bit 'more time' than normal communicating/discussing with them?
17:25:10 <JayF> Anyone who was here for mid-cycle-alt in SF met them
17:25:14 <JayF> that's the group of folks from Ebay
17:25:15 * jroll touches his nose
17:25:27 * JayF doesn't have the time
17:25:36 * rloo thinks she understans jroll's reference...
17:25:43 <devananda> #agreed ironic should not cross the user-data/operator-control-plane boundary and start editing files within the user's instance directly; it must rely on existing APIs for that (eg, cloud-init)
17:25:53 <NobodyCam> Ty devananda :)
17:25:56 <JayF> rloo: touch nose = "not it" ... as in last person to touch their nose *is* it
17:25:59 <jroll> rloo: https://en.wikipedia.org/wiki/Nose_goes
17:26:07 <NobodyCam> ok is pshige here
17:26:27 <rloo> jroll: i was wrong, i think (some) asians do that to refer to 'themself'. Ie, you're it.
17:26:31 <jlvillal> NobodyCam: pshige stated not feeling well and skip to next week.  According to agenda
17:26:44 <NobodyCam> ya was just checking
17:27:01 <NobodyCam> so next up is:
17:27:06 <NobodyCam> #topic Should remainder of PEP8 compliance work be done?
17:27:09 <jroll> rloo: interesting, TIL :)
17:27:11 <NobodyCam> jlvillal: thats you
17:27:22 <jlvillal> sambetts: Has started the work on this.
17:27:25 <NobodyCam> #link https://bugs.launchpad.net/ironic/+bug/1421522
17:27:25 <openstack> Launchpad bug 1421522 in Ironic "Ironic code ignores all E12* pep8 errors" [Wishlist,In progress] - Assigned to Sam Betts (sambetts)
17:27:35 <jroll> jlvillal: so I'm curious what E126,E127,E128 are
17:27:39 <jlvillal> I just wanted to make sure that everyone is okay with it.  As it will likely touch a lot of code
17:27:58 <dtantsur> jroll, IIRC indentation
17:28:03 <jlvillal> jroll: http://pep8.readthedocs.org/en/latest/intro.html#error-codes
17:28:03 <sambetts> E123 (*) 	closing bracket does not match indentation of opening bracket’s line
17:28:06 <sambetts> E126 (*^) 	continuation line over-indented for hanging indent
17:28:09 <sambetts> E127 (^) 	continuation line over-indented for visual indent
17:28:12 <sambetts> E128 (^) 	continuation line under-indented for visual indent
17:28:12 <jroll> I presonally hate the indentation rules
17:28:18 <devananda> meh. I dont see any significant value in those
17:28:23 <NobodyCam> i would vote -1 for 128
17:28:32 <dtantsur> I hate the rules, but I hate when they're violated all over the place
17:28:40 <devananda> there are a LOT of cases where readability is improved, IMNHSO, by ignoring those
17:28:45 <rloo> dtantsur: ha ha, that doesn't make sense!
17:28:49 <jroll> devananda: +1
17:28:53 <jlvillal> I would vote for consistency and OpenStack states code should be PEP8 compliant
17:29:00 <jroll> I also find I spend significant time tweaking things to fit those rules
17:29:05 <devananda> eg, because line wrapping to 80 chars of some highly indented code would make one expression span a bagillion lines
17:29:08 <devananda> or three
17:29:11 <devananda> either way it's too many
17:29:11 <jlvillal> But I may be in minority :)
17:29:31 <dtantsur> for the record: inspector never ignored any pep8 rules
17:29:47 <jlvillal> python-ironicclient is fully PEP8 compliant also.
17:29:47 <dtantsur> so I'm generally on the positions of: rules might such, but they're rules
17:29:57 <krtaylor> I don't see a problem with being pep8 compliant personally
17:30:10 <dtantsur> s/such/suck/
17:30:12 <devananda> off hand, I think E128 is the one I would want to continue ignoring
17:30:39 <rloo> for the record, E129 isn't there cuz lucas? and I objected to it
17:30:52 <devananda> I'm probably at fault for breaking E123 all over the place. hang over from my C / Perl days
17:31:01 <NobodyCam> yea I'm okay will all but the 128..
17:31:12 <devananda> tl;dr; do these rules improve readability when we follow them, or when we break them?
17:31:47 <sambetts> the patches to fix 123, 6 7 and 8 are up for review, and I think there are several cases when it does improve the readablity of the code
17:31:57 <devananda> hm
17:31:57 <rloo> i looked at part of one of the patches, and it improved it for some cases
17:32:04 <jlvillal> I think they improve readability for the most part.
17:32:11 <devananda> ok then
17:32:12 <NobodyCam> sambetts: can you #link them here for the record
17:32:18 <jlvillal> I don't think we can see it does it for all cases.  But in the aggregate...
17:32:19 <devananda> and if the refactoring is already done, then yea, I'm for it.
17:32:34 <jlvillal> s/see/say/
17:32:35 <devananda> it will cause some rebasing of other patches immediately -- better t oget that out of the way if we are going to enable these checks
17:32:36 <sambetts> The top of the tree of patches: https://review.openstack.org/#/c/186021/
17:32:49 <NobodyCam> #link https://review.openstack.org/#/c/186021
17:33:20 <jlvillal> Did we make a final decision on E128?  Yay or nay?
17:33:25 <NobodyCam> I'm good with what ever direction we want to go.. should we vote?
17:33:36 <jlvillal> I think the patch is already doing E128
17:33:45 <rloo> isn't that the bottom of the tree of patches? (what is top vs bottom?)
17:33:50 <jroll> if the works done, I'm fine with it
17:34:02 <sambetts> rloo: yes, thats probably true
17:34:13 <rloo> umm, i'm not fine with it w/o looking at it
17:34:22 <jlvillal> First patch to review is 186021 as all the others depend on it.
17:34:26 <devananda> #startvote should we enable E123,6,7,8 checks? yes, no, abstain
17:34:27 <rloo> regardless if the work is done or not ;)
17:34:27 <openstack> Begin voting on: should we enable E123,6,7,8 checks? Valid vote options are yes, no, abstain.
17:34:28 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:34:37 <jlvillal> #vote yes
17:34:40 <thiagop> #vote yes
17:34:42 <devananda> #vote yes
17:34:42 <NobodyCam> #vote yes
17:34:43 <sambetts> #vote yes
17:34:45 <rloo> why all or nothing?
17:34:56 <BadCub> #vote abstain
17:35:00 <devananda> rloo: you can abstain or vote no if you dont want all
17:35:01 <TheJulia> #vote yes
17:35:02 <afaranha> #vote yes
17:35:05 <Nisha> #vote yes
17:35:06 <rloo> #vote no
17:35:09 <_lintan> #vote abstain
17:35:09 <gabriel-bezerra> #vote abstain
17:35:09 <dtantsur> #vote yes
17:35:19 <clif_h> #vote no
17:35:26 <cinerama> #vote abstain
17:35:32 <jroll> #vote yes
17:35:43 <natorious> #vote yes
17:35:57 <clif_h> I just don't like the continuation indent rules
17:36:03 <devananda> giving it another minute
17:36:34 <devananda> or not - since it seems everyone is done voting now :)
17:36:37 <devananda> #endvote
17:36:38 <openstack> Voted on "should we enable E123,6,7,8 checks?" Results are
17:36:39 <openstack> yes (11): TheJulia, NobodyCam, jlvillal, afaranha, devananda, jroll, dtantsur, Nisha, natorious, sambetts, thiagop
17:36:40 <openstack> abstain (4): cinerama, BadCub, _lintan, gabriel-bezerra
17:36:41 <openstack> no (2): rloo, clif_h
17:37:00 <clif_h> I think the ayes have it
17:37:01 <devananda> we've got 1 core voting no, 1 core abstaining
17:37:10 <devananda> 4 cores voting yes
17:37:17 <devananda> and overall a lot more support for yes
17:37:44 <NobodyCam> yep
17:37:46 <devananda> #agreed enable E 123,6,7,8 checks
17:37:46 <rloo> (who's the core that abstained?)
17:38:04 <devananda> rloo: oops! I misread. we have no cores abstaining
17:38:10 <NobodyCam> :-p
17:38:20 <NobodyCam> ok moving on
17:38:20 * BadCub hands devananda more coffee
17:38:27 <NobodyCam> #topic Ironic Mid-Cycle Sprint
17:38:34 <NobodyCam> I think is is BadCub
17:38:39 <devananda> BadCub: thanks. remind me to never sit in a casino while trying to pay attention to IRC again
17:38:40 <BadCub> Yep
17:38:50 <BadCub> devananda: lol noted!
17:38:51 <NobodyCam> lol
17:39:03 <BadCub> So folks. Sprint.... Seattle work for everyone?
17:39:14 <jroll> ok so, "It's near the feature freeze. It might be a little late." <- first question, do we want to change release models this cycle or next
17:39:16 * NobodyCam hands deva some $$$ for the closest slot machine
17:39:24 <jroll> I'm +1 on seattle though
17:39:31 <TheJulia> devananda: when they ask for your drink order, ask for coffee :)
17:39:39 <jlvillal> Works for me, but I will be in Moscow for all of July....
17:39:39 <TheJulia> +1 on seattle
17:39:39 <BadCub> devananda: advised he would get in touch with facilities at HP
17:39:51 <devananda> I've pinged the local facilities mgr, but no answer yet
17:39:52 <dtantsur> north america does not work for me, so abstain on seattle :)
17:39:58 * jlvillal assumes he will get visa....
17:40:09 <devananda> dtantsur: france didn't work for you last time, either :(
17:40:13 <jlvillal> dtantsur: You can come to Moscow and we can have mini-sprint ;)
17:40:22 <NobodyCam> jlvillal: visa's from protlanda are hard to get I hear
17:40:50 <jroll> s/protlanda/portlandia
17:40:50 <dtantsur> devananda, yes, you can safely assume that generally midcycles do not work for me :) in EU there are some (small) chances though...
17:40:56 <NobodyCam> :)
17:40:57 <BadCub> So what about timing? devananda proposed 12-14 Aug, but that is close to freeze
17:41:02 <jlvillal> Is there a date range?
17:41:11 <jroll> so I ask again, are we having a freeze this cycle?
17:41:26 <jroll> read: switching release models this cycle or next?
17:41:27 <dtantsur> jroll, I was assuming we follow our new model
17:41:36 <jroll> me too, which means freeze doesn't exist :)
17:41:43 <devananda> fwiw, I'm looking at dates of Aug 12 - 14, which is the week before LinuxCon / CloudOpen in Seattle
17:41:46 <BadCub> I have a secondary discussion item about spec review freeze later as well
17:41:52 <devananda> http://events.linuxfoundation.org/events/linuxcon-north-america/extend-the-experience/co-located-events
17:41:58 <jlvillal> +1 on dates and location
17:42:01 <rloo> did we decide for sure to use new release model? thought it was still in proposal stage
17:42:21 <dtantsur> BadCub, I thought that in a new model we don't have spec freeze, but maybe it's only me :)
17:42:29 <jroll> rloo: we all (soft?) voted on it in vancouver, I was under the assumption this was an informational spec
17:42:33 <NobodyCam> jroll: I would like to land: https://review.openstack.org/#/c/185171
17:42:36 <JayF> fwiw 8/12-8/14 I wouldn't be able to attend; but I'm OK with that
17:42:37 <jroll> rloo: I don't see disagreement on the list either
17:42:41 <gabriel-bezerra> dtantsur: I thought that too
17:42:48 <rloo> jroll: give me a day or two...
17:42:51 <BadCub> dtantsur: yeah, I put it up there for us to confirm that we are going to follow new model
17:42:55 <cinerama> that is ok for me i think
17:43:05 <devananda> on the topic of release cycle / freeze / etc -- I dont know yet. I'd *like* to not do a feature freeze, *but* we are somewhat dependent on how far the community gets in changing the release models
17:43:13 <devananda> adapting their release tooling to support it
17:43:18 <jroll> NobodyCam: same.
17:43:30 <jroll> NobodyCam: needs some updates, I'll get to that this week
17:43:39 <NobodyCam> jroll: +++
17:43:41 <devananda> so far, it looks like dhellmann is on the ball with all that, and ttx has already announced changes to how we'll track/report on release cycle progress
17:43:52 <devananda> so, it looks possible (if not likely) that it'll happen this cycle
17:44:11 <dtantsur> which means we're having a release soonish :)
17:44:20 <devananda> dtantsur: eh?
17:44:26 <BadCub> so [assuming] we will follow the new model. Is everyone good with 12-14 Aug in Seattle?
17:44:32 <dtantsur> we decided to have intermediate releases
17:44:40 <jlvillal> vote?
17:44:48 <devananda> dtantsur: sure. but "soonish" - I dont know where that came from
17:45:02 <dtantsur> my speculations
17:45:02 <BadCub> Vote would be good
17:45:15 <devananda> voting on?
17:45:19 <NobodyCam> dates?
17:45:25 <BadCub> devananda: sprint date/location
17:45:33 <BadCub> NobodyCam: 12-14 Aug
17:45:34 <rloo> not everyone can attend these meetings.
17:45:45 <rloo> seems odd to be voting on the date
17:45:45 <devananda> oh. yea. not something to vote on here
17:45:51 <jroll> to the list!
17:46:21 <BadCub> Okay, then I will [assume] that 12-14 Aug in Seattle is good and move forward
17:46:30 * jlvillal forgets about the mailing list at times.  His life is only about IRC....
17:46:52 <devananda> quick question for folks re: dates
17:47:00 <NobodyCam> ok so we'll move on and maybe get thru the whole agenda
17:47:07 <NobodyCam> waiting
17:47:08 <devananda> regadless of release models, who would prefer a date sooner than aug 12?
17:47:45 <NobodyCam> devananda: I am good with +/- a week
17:47:47 <jroll> mmm, actually. I might be out of town aug 13-16 :/
17:48:02 <devananda> I mean like a month earlier
17:48:04 <jroll> go without me if that's the best date but I'd like to be there if possible
17:48:17 <jlvillal> I would prefer anytime after 4-Aug.  As I would not be able to attend in July.
17:48:19 <jroll> devananda: sounds like we need a doodle thing on dates
17:48:26 <devananda> yea ... sounds like we need a poll
17:49:03 <rloo> at the summit, there was discussion about trying to colocate with another project (or at least have ironic liaisons at other projects)
17:49:10 <devananda> #action devananda to post a poll for midcycle dates
17:49:14 <BadCub> then let's do a poll so we can get a consensus that works for as many as possible.
17:49:19 <rloo> maybe 'discussion' is too strong. more like 'mention'
17:49:46 <jroll> rloo: +1 for liasions
17:50:14 <NobodyCam> we'll need a list of where / when the other mid cycles are
17:50:16 <jroll> we have two topics left, should we agree to poll and move on?
17:50:27 <devananda> rloo: IIRC, we said colocating with nova might be good, and we should try to cross-pollinate with cinder and neutron
17:50:28 <NobodyCam> yep moving on :)
17:50:33 <devananda> ++ to moving on
17:50:41 <NobodyCam> #topic capabilities
17:50:45 <NobodyCam> Nisha: are you here
17:50:51 <Nisha> NobodyCam, yeah
17:51:06 <NobodyCam> (links on agenda item)
17:51:09 <Nisha> i wanted to know the discussion on capabilities
17:51:25 <jroll> has there been discussion on it?
17:51:28 <jroll> I haven't see any
17:51:41 <Nisha> even devananda mail on summit update doesnt list any update on it
17:51:51 <Nisha> i heard some discussion did happened at summit
17:52:01 <Nisha> but not sure whats the conslusion
17:52:11 <devananda> outside of the nova scheduler sessions, I didn't see any discussions at the summit even related to this
17:52:27 <gabriel-bezerra> we had some discussions about flavors extra_specs that sounded like capabilites.
17:52:41 <jroll> the discussions I had on it were "when are we doing capabilities"
17:52:45 <devananda> there was a similar spec proposed by thiagop (i think) for adding a "passthrough" to nova flavors, which got heavily -2'd
17:52:47 <jroll> from approximately 9001 people
17:52:48 <devananda> perhaps because of the name
17:53:04 <gabriel-bezerra> #link https://review.openstack.org/186536
17:53:06 <devananda> but it is, in principle, trying to achieve the same thing: pass some flavor data down to Ironic so that the driver can act upon it
17:53:09 <Nisha> devananda, ok...so how do we want to deal with capabilities for ironic
17:53:10 <devananda> gabriel-bezerra: thanks!
17:53:26 <gabriel-bezerra> devananda: np
17:54:01 <Nisha> devananda, that is done still, correct?
17:54:02 <devananda> Nisha: so one problem with this work is that Nova is (still....) trying to refactor and split out the scheduler
17:54:03 <gabriel-bezerra> I'll discuss with johnthetubaguy and dansmith about that later though
17:54:07 <wanyen> There were some discussion about by-pass flavors.  Nisha Imentione dyour nova/capability specs at one of the break-out session but I don't think we made any conclusion.
17:54:08 <devananda> so they are resisting anything which changes how the scheduler works
17:54:46 <devananda> it's quite frustrating for me as well. BUT. I've proposed to Nova an alternative approach, which is basically that we create a new plugin for the scheduler that queries Ironic's REST API directly
17:54:56 <NobodyCam> so maybe better to wait until they finish their refactor
17:55:05 * jroll cries
17:55:10 <jlvillal> 5 minutes
17:55:13 <devananda> to do that, we need to implement a queriable endpoint, with filtering abilities, and probably do some table refactoring
17:55:15 <Nisha> NobodyCam, that may be too late for us to get anything in Nova
17:55:15 <jroll> "wait on nova" is always sad
17:55:16 <devananda> I haven't written this anywhere yet
17:55:20 <rloo> any idea on when that refactor might happen? earliest is M (my guess)
17:55:20 <Nisha> in liberty
17:55:27 <dansmith> don't count on it :)
17:55:39 <dansmith> I don't think this is completely wrapped up in the scheduler, FWIW
17:55:48 <dansmith> the concerns are more fundamental than that,
17:55:51 <devananda> so first step is probably for me to write a spec on what dansmith and mikal and I talked about, as far as the API in Ironic and the Nova scheduler changes to use it
17:55:59 <dansmith> which means the "good news" is we can discuss it separate from that I think
17:56:01 <gabriel-bezerra> I was in the design session about refactoring flavors extra_specs. I can see the intention/the pain point but could not see agreement there.
17:56:18 <devananda> dansmith: oh?
17:56:18 <NobodyCam> dansmith: awesome
17:56:55 <clif_h> are we going to have an open discussion before the hour runs out?
17:56:57 <NobodyCam> we have one more topic on the agenda
17:57:00 <devananda> dansmith: Ah. Nova's idea of a flavor == find the thing I want, != make the thing I want magically appear
17:57:03 <devananda> yes?
17:57:28 <devananda> blah. time. let's open it up and continue this afterwards
17:57:31 <NobodyCam> #topic Open Discussion / Food For Thought
17:57:41 <jroll> 2 minutes :P
17:57:43 <jroll> clif_h: whatcha got
17:57:44 <clif_h> I humbly request eyes on
17:57:51 <clif_h> #link https://review.openstack.org/#/c/161832/
17:57:52 <NobodyCam> there is also a item for spec review cut off date
17:58:00 <jroll> yay caching.
17:58:01 <clif_h> image caching patch
17:58:16 <BadCub> NobodyCam: if we are following the new model, that wont be applicable
17:58:22 <jroll> BadCub: sow ith the new release model, do we need a spec freeze? (or is that your question?)
17:58:25 <NobodyCam> ack!
17:58:27 <clif_h> has come a long way and appears to work well with arsenal
17:58:28 <dansmith> devananda: I dunno that either of those is really correct anymore
17:58:30 <dansmith> but anyway
17:58:30 <devananda> clif_h: image caching ++
17:58:38 <clif_h> although its not in production downstream just yet
17:59:01 <NobodyCam> *one minute*
17:59:09 <rloo> BadCub: shouldn't your question be addressed/added in jroll's spec about the new release model?
17:59:17 <BadCub> jroll: not really, my only concern is the Cores are not overwhelmed with reviews, etc.
17:59:34 <jroll> BadCub: I think the freeze is what overwhelms us
17:59:39 <devananda> dansmith: I'm probably out of touch. happy to learn if you'd like to clarify what the current model is
17:59:53 <BadCub> rloo: indeed it should. I think we need to come to the consensus on what our release model will be moving forward.
18:00:02 <NobodyCam> and thats time...
18:00:06 <dansmith> devananda: I mean that with things like numa, there's some of "find what I want" in addition to "create what I want"
18:00:07 <NobodyCam> thank you all
18:00:09 <dansmith> even for virt
18:00:10 <jroll> thanks err'body
18:00:15 <devananda> BadCub: others: please discuss release model (concerns) on the mailing list and/or the spec
18:00:33 <devananda> thanks all! good meeting
18:00:36 <NobodyCam> #endmeeting