19:00:31 <devananda> #startmeeting ironic
19:00:31 <adam_g> o/
19:00:32 <openstack> Meeting started Mon Oct 13 19:00:31 2014 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:35 <openstack> The meeting name has been set to 'ironic'
19:00:41 <pensu> o/
19:00:44 <devananda> #chair NobodyCam
19:00:44 <openstack> Current chairs: NobodyCam devananda
19:00:49 <lucasagomes> o/
19:00:52 <devananda> #topic Greetings and Announcements
19:00:54 <mrda> o/
19:00:55 <harshada_kakad> o/
19:01:16 <jgrimm> o/
19:01:16 <rameshg87> o/
19:01:19 <devananda> our agenda is, as usual, up on the wiki here: https://wiki.openstack.org/wiki/Meetings/Ironic
19:01:53 <devananda> I hope everyone had a great weekend :)
19:02:15 <devananda> hm, haven't seen NobodyCam yet?
19:02:52 <devananda> my only annoucement from last week is that we tagged a second release candidate
19:03:09 <lucasagomes> I marked a bug as potential-rc after the release :(
19:03:14 <devananda> d'oh
19:03:21 <devananda> #topic Juno status
19:03:25 <devananda> lucasagomes: link?
19:03:25 <lucasagomes> well I haven't found it before
19:03:30 <lucasagomes> 1sec
19:03:46 <lucasagomes> #link https://bugs.launchpad.net/ironic/+bug/1379705
19:03:47 <uvirtbot> Launchpad bug 1379705 in ironic "DRAC Driver can't continue the deploy" [High,Fix committed]
19:04:10 <lucasagomes> basically the DRAC driver is broken because it has no vendor interface (and it uses PXE for deploy)
19:04:21 <linggao> o/
19:04:31 <lucasagomes> s/is/was the fix is merged in K
19:04:37 <devananda> oh
19:04:55 <lucasagomes> yeah it's a silly one
19:05:13 <devananda> crap. yes, that's broken
19:05:38 <devananda> ok... I can set up an RC3 for the end of this week
19:05:54 <devananda> anyone else find critical bugs since we opened Kilo?
19:05:58 <lucasagomes> cool thanks
19:06:04 <devananda> or things serious enough to need backporting to juno?
19:06:19 <rameshg87> devananda: for juno, we would like to add some documentation for ilo drivers - https://review.openstack.org/#/c/127161/ . does it come under mention here ?
19:06:21 <GheRivero> 7-
19:06:53 * GheRivero moves the cat to another room
19:06:56 <devananda> rameshg87: doc update like that affects the website immediately (once it lands) so it doesn' tneed backporting
19:07:01 <devananda> GheRivero: :)
19:07:26 <rameshg87> devananda: thanks.
19:07:27 <dtantsur> GheRivero, :D
19:07:35 <NobodyCam> o/
19:08:08 <devananda> any other comments on Juno?
19:09:01 <devananda> ok, well, please continue to test RC2 and tag any potentially critical bugs with juno-rc-potential. I'll spin another rev thursday, so we have a few days still
19:09:21 <devananda> #topic kilo planning
19:09:38 <devananda> this sort of has two parts that I'd like us to chat about
19:09:40 <devananda> summit and specs
19:09:54 <devananda> I dont have any more news about the design summit than I did last week
19:10:17 <devananda> are there proposed sessions that folks want to talk about now?
19:10:32 <mrda> devananda: have you got a url?
19:10:48 <devananda> ditto for specs -- and I assume theyll be related. if there's a big topic, it probably also has a related spec (or should!)
19:10:53 <devananda> mrda: https://docs.google.com/spreadsheets/d/1XBKdeDeGfaRYaThjIIoYRwe_zPensECnxsKUuqdoVmQ/edit#gid=0
19:10:56 <mrda> ta
19:11:06 <lucasagomes> we have many potential sessions proposed on the spreadsheet
19:11:16 <jroll> so we've been voting for a week... I don't see a ton of votes :/
19:11:24 <lucasagomes> maybe we should set a date so people can vote and the most voted ones are selected to become a session?
19:11:34 <jroll> yeah, maybe just end of day friday
19:11:39 <NobodyCam> lucasagomes: ++
19:11:45 <jroll> and make a ordered list for next mtg
19:11:55 <lucasagomes> jroll, that would be good
19:12:04 <devananda> jroll: sure, sounds good
19:13:00 <devananda> as a reminder, we have 4 official slots on wed, 1 on thur, and a half day unconference on friday
19:13:30 <NobodyCam> and the pod all week?
19:13:30 <lucasagomes> for the unconference day there's no "format" for it right?
19:13:56 <devananda> yes, we should have a "pod" all week
19:14:10 <jroll> lucas, right
19:14:26 <lucasagomes> I liked what we did on the last mid-cycle, remember the topics on the whiteboard?
19:14:29 <devananda> which basically means a dedicated meeting point where a few folks can gather any time
19:14:36 <lucasagomes> we should do something similar to that on friday maybe
19:14:36 <devananda> but it probably won't be useful beyond ~10 ppl at once
19:14:52 <devananda> lucasagomes: that's my plan for friday, yes
19:15:10 <lucasagomes> awesome
19:15:13 <NobodyCam> for some of the smaller intress topics that should be good
19:15:16 <jroll> we should come up with those topics in advance
19:15:26 <jroll> so we don't spend half the time arguing over what to argue about :)
19:15:27 <devananda> so, here's my thinking
19:15:28 <lucasagomes> jroll, +1 yeah the spreadsheet :)
19:15:33 <jroll> yep
19:15:41 <devananda> everyone votes on the spreasheed this week
19:15:44 <mrda> so we need to decide which topics get "official" slots and the rest we do like mid-cycle?
19:15:53 <jroll> mrda: yes
19:15:57 <mrda> cool
19:16:17 <devananda> friday morning I'll tally things, assign 5 to official slots, and pick several "big ticket items" taht we should prioritize discussion of on friday
19:16:37 <devananda> then on Monday, let's go over that and adjust as necessary
19:16:46 <NobodyCam> devananda: that sounds good +1
19:16:56 <devananda> and during the week, lets use the pod for any impromptu hacking sessions that folks want to hve
19:17:02 <jroll> +1
19:17:08 <lucasagomes> devananda, sounds like a plan
19:17:34 <devananda> #action devananda to review votes on the session spreadsheet on Friday, come up with prioritized list for Monday's meeting
19:17:46 <devananda> ok. about specs for a minute --
19:18:03 <devananda> I want to remind everyone that Kilo is open
19:18:21 <devananda> but specs do not automatically move -- you need to rebase and update your spec if you submitted it during Juno
19:18:45 <devananda> #info specs submitted during Juno need to be updated for Kilo template, and moved to /kilo/ directory
19:18:56 <devananda> (posting that ^ for the minutes for anyone not here)
19:19:18 <pensu> jroll: devananda: We should really try to add this to kilo planning: https://review.openstack.org/#/c/102405/
19:19:45 <devananda> are there specific specs folks would like to talk about today? I'll cap at 10 minutes but we should pick a few to start working on next week
19:20:24 <devananda> pensu: ++
19:21:28 <lucasagomes> should we abandon the open specs for juno?
19:21:32 <lucasagomes> just to clean up the queue?
19:21:59 <devananda> lucasagomes: lets wait another week.
19:22:10 <NobodyCam> lucasagomes: I say a week or so after the conf for something like that
19:22:18 <lucasagomes> right
19:22:29 <devananda> lucasagomes: also if you're using gertty, it's easy to hide them
19:22:57 <jroll> pensu: is that not on the spreadsheet? /me adds
19:23:05 <lucasagomes> it's not that the author can't restore it and submit a new one for kilo... it's just that when you open a list of open patches for ironic-specs there's a bunch of juno specs there and it's hard to sort between juno and kilo
19:23:06 <lucasagomes> but yeah
19:23:11 <lucasagomes> devananda, yeah I've to start using it
19:23:17 * lucasagomes writes it down
19:23:48 <devananda> lucasagomes: yea, using the web UI that would be challenging. in gerrty, my list for ironic-specs is .. about 10 unreviewed specs
19:23:55 <devananda> and I dont see anything else :)
19:24:05 <NobodyCam> :-p
19:24:22 <lucasagomes> :) yeah I'm setting up gertty heh
19:24:26 <Shrews> I would start using gertty, but then I'd have to push something else out of my brain in order to learn it
19:24:38 <devananda> Shrews: I pushed the gerrit web UI out of my brai
19:24:39 <devananda> brain
19:25:11 <devananda> I have just two words: keyboard shortcuts
19:25:29 <devananda> anyway, if folks dont have specific specs to talk about, let's move on
19:25:35 <lucasagomes> for those interested
19:25:37 <lucasagomes> #link https://github.com/stackforge/gertty
19:25:53 <devananda> #topic subteam status reports
19:26:00 <devananda> adam_g: hi! how's CI?
19:26:19 <adam_g> okay--the parallel tests seem to be mostly stable, with the exception of one failure jroll reported today that i'm looking into
19:26:48 <adam_g> our sideways grenade test is a bit jammed right now pending some grenade issues, but will hopefully be resolved this week and running again when stable/juno is up
19:27:02 <adam_g> i'm working on ensuring the grenade juno -> kilo/master job is ready for that as well
19:27:12 <NobodyCam> awesome :)
19:27:15 <devananda> fantastic
19:27:42 <devananda> dtantsur: hi! how's our bug backlog looking?
19:27:52 <dtantsur> Open: 88 (-1). 3 new (-1), 21 in progress (0), 0 critical, 9 high (0) and 4 incomplete (0)
19:28:05 <dtantsur> everything calm, but I'm concerned by number of in progress
19:28:18 <dtantsur> I'll probably start poking people next week
19:28:22 <dtantsur> * this week
19:28:40 <NobodyCam> I was going to ask do we want a bug swatting day?
19:28:48 <devananda> adam_g: on the parallel job, let's not change anything before Juno final (end of this week) but if you are comfortable with it, I'd like to make it voting any time after that
19:28:55 <devananda> NobodyCam: that might be a fun thing to do in person at the summit?
19:29:03 <dtantsur> ++ for in person
19:29:09 <NobodyCam> for our pod area !!!
19:29:10 <devananda> pick a couple hour window when there aren't other things going on, gather in our POD and hack on bugs?
19:29:43 <NobodyCam> ++ i'd buy that for a dollar (/me watched robocop this weekend)
19:29:44 <devananda> who else'd be up for that?
19:29:46 <lucasagomes> :) sounds good
19:29:50 <adam_g> devananda, im okay with it voting under the assumption that people are okay with having to an occasional recheck if it fails for some non-obvious bug. we should start tracking those with elastic-recheck, if they happen
19:29:50 <mrda> +1
19:30:02 <devananda> dtantsur: want to organize that?
19:30:05 <devananda> adam_g: exactly
19:30:05 <jroll> ++ for bug day
19:30:17 <dtantsur> devananda, likely yes
19:30:32 <dtantsur> (though it's my first Summit and I barely imagine how thigs work there :)
19:30:56 <devananda> dtantsur: ahh. lucas?
19:30:59 <NobodyCam> dtantsur: its a mad house no matter how much you plan :-p
19:31:02 <jroll> dtantsur: talks, code, and chaos
19:31:10 <dtantsur> lol
19:31:18 <devananda> dtantsur: not knowing the format will make it a bit challengign for you. chaos is a good way to put it :)
19:31:23 <lucasagomes> yeah I can give a hand fo sure
19:31:31 <devananda> great, thanks
19:31:32 <dtantsur> cool :)
19:31:36 <lucasagomes> dtantsur, we can do a hangout and come up with some ideas
19:31:41 <jroll> "when other things aren't going on" is going to be hard due to various interests, we should identify a few slots and collaborate
19:31:43 <dtantsur> right
19:31:55 <devananda> jroll: there is never a time when all of us will be free
19:32:05 <devananda> but I suspect things like that will work fairly well on tuesday
19:32:16 <devananda> it's mostly cross project workshops that day
19:32:20 <jroll> right... I mean we should identify the best
19:32:34 <jroll> tuesdya might be fine
19:32:48 <devananda> I'll be in and out of several of those, but chances are more of us will be free then than on Wed (ironic and nova) and thu (ironic and nova ...)
19:33:00 <jroll> yeah
19:33:39 <devananda> GheRivero: hi! I think we missed you last week -- thanks for volunteering to continue to be oslo liason.
19:33:50 <GheRivero> you are welcome.
19:34:03 <GheRivero> A couple of announcements for today:
19:34:04 <devananda> GheRivero: aside from the deprecated incubation libraries, which it looks like you and lucasagomes are already on top of (cheers!)
19:34:10 <devananda> any thing else?
19:34:26 <GheRivero> we are using oslo.serialization (jsonutils) landed this weekend
19:34:52 <GheRivero> synces libraries and new config and policy API is on the way (thx to lucasagomes and dims )
19:35:11 <GheRivero> and oslo.logging  is on is way... someday
19:35:32 <GheRivero> s/dims/Roman/
19:36:06 <GheRivero> nothing else
19:36:40 <lucasagomes> thanks GheRivero
19:37:17 <devananda> thanks much, GheRivero !
19:37:41 <devananda> on to drivers -- jroll, linggao, wanyen, lucas! Hi! any news/questions/updaets on your respective drivers?
19:37:55 <jroll> I don't believe I do :)
19:38:01 <NobodyCam> do we have an offical DRAC contact?
19:38:03 <rameshg87> nothing much to report from ilo driver team.  no open items for juno except documentation of the drivers. we are working on few specs for kilo, will post them for review soon.
19:38:10 <lucasagomes> only that DRAC problem
19:38:20 <lucasagomes> NobodyCam, I volunteered to be the contact
19:38:27 <NobodyCam> ++
19:38:27 <lucasagomes> I'm not the expert on it but since I've worke don it
19:38:37 <NobodyCam> thank you lucasagomes
19:38:37 <lucasagomes> and I have access to a DRAC box I think it may make some sense
19:39:19 <devananda> rameshg87: thanks
19:39:29 <devananda> I do have one announcement in this section
19:39:46 <devananda> mirantis has spun up a project a whiel back to track the status of drivers in OpenStack
19:39:49 <devananda> #link https://wiki.openstack.org/wiki/DriverLog
19:40:06 <devananda> they reached out to me to seed the content for Ironic last week -- it's now up, starting around this line
19:40:13 <devananda> https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L880
19:40:46 <lucasagomes> oh awesome
19:40:47 <devananda> if there are any errors (wrong contact, misspelled name) it's entirely my fault, but please correct it
19:40:48 <jroll> oh, I need to add others to the agent maintainers list
19:40:59 <devananda> you can submit directly to the project in gerrit
19:41:03 <jroll> yep
19:41:03 <devananda> stackforge/driverlog
19:41:09 <jroll> devananda: what does "vendor" mean?
19:41:22 <jroll> e.g. for iLO, is HP the vendor because they make ilo?
19:41:27 <jroll> or because HP folks work on it
19:41:28 <devananda> jroll: what company is responsible for contributing/maintaining it, I think
19:41:37 <jroll> hmm, ok
19:41:47 <rameshg87> thanks devananda
19:41:52 <jroll> I'd argue all in-tree drivers are the community responsibility, but ok :)
19:42:10 <devananda> well
19:42:22 <devananda> there've been several lengthy discussions in nova, neutron, and cinder as well
19:42:33 <devananda> about who is responsible for ensuring / attesting to the quality of drivers
19:42:46 <devananda> when the community at large has no access to such hardware
19:42:50 <lucasagomes> heh in part it's but if nobody can test it it's hard to know whether it's working or not
19:42:51 <jroll> ah, true
19:42:58 <devananda> ironic falls into the same boat
19:43:11 <devananda> I would make a case taht IPA is community, since anyone can test and validate it
19:43:16 <jroll> right
19:43:23 <devananda> but iLO is the responsibility of HP, since they manufactor the hardware and contributed the driver
19:43:36 <devananda> tho DRAC gets murky since dell didn't contribute the driver...
19:43:38 <jroll> that's why I asked, makes sense :)
19:44:16 <devananda> moving on then
19:44:21 <devananda> #topic open discussion
19:44:44 <lucasagomes> i've a question here... so when I was porting the config to use the oslo libraries
19:45:03 <lucasagomes> I thought it would be a good idea to split the sample config file in 3: all configs, api configs, conductor configs
19:45:21 <lucasagomes> do you guys think that splitting it makes sense? or should we only have one sample config with all the configs ?
19:45:37 <NobodyCam> i did n't add to the agenda but wanted to gague what folk thought about targeting provisioning to a device other then sda!
19:45:40 <lucasagomes> #link https://review.openstack.org/#/c/128005/
19:45:55 <jroll> hmm, I think 3 may be tough, because folks will need to merge them later
19:46:04 <devananda> lucasagomes: I dont see a strong reason for us to put in the effort to maintaining that split.
19:46:07 <jroll> and how do you automatically decide, in code, which service it belongs to
19:46:10 <NobodyCam> i like single file easy to grep
19:46:11 <jroll> yes, +1 deva
19:46:33 <devananda> lucasagomes: and as an operator, if there's no reason to separate the configs, then it only complicates things if I think I need to
19:46:36 <lucasagomes> right I haven't a strong opnion on that later, I just saw other services (glance) doing that and thought it may be useful
19:46:45 <lucasagomes> devananda, right yeah I agree with that
19:47:19 <devananda> lucasagomes: I would ask how this benefits operators. if it does -- great. if not, we shouldn't do it
19:47:41 <lucasagomes> devananda, ML?
19:47:47 <devananda> lucasagomes: sure
19:47:57 <lucasagomes> right I will fire an email later to the ML asking
19:48:13 <jroll> one data point: we use the same configs on api and conductor hosts
19:48:21 <lucasagomes> but for the next patchset I will just have 1 config (it's easy to break into multiple ones if needed)
19:48:33 <lucasagomes> jroll, oh right, that's good to know
19:48:35 <devananda> NobodyCam: using arbitrary devices for '/' partition is going to introduce a host of complications
19:48:58 <devananda> NobodyCam: for one, the boot partition may be requried to be on a specific device which is not the user-selected one
19:49:02 <NobodyCam> i have had a customer ask that question
19:50:19 <lucasagomes> NobodyCam, right, can u say what was the use case?
19:50:24 <devananda> NobodyCam: I could see that being part of the deploy info (assuming we separate boot & deploy), but I'd like to understand the use-case better
19:50:50 <devananda> Shrews: you posted something to the agenda as well - want to raise it?
19:50:56 <Shrews> So, those hacking errors listed on the agenda are the remaining ones we are ignoring b/c they exist in our code. Does anyone feel strongly about keeping any of those?
19:51:06 <NobodyCam> lucasagomes: the customer had data on sda that they wish to keep, so they install the OS on to sdb
19:51:24 <lucasagomes> NobodyCam, ephemeral partition?
19:51:37 <jroll> Shrews: IMO we should fix them all
19:51:38 <devananda> NobodyCam: they want to use ironic with pre-existing data w/o destroying it?
19:51:44 <lucasagomes> they can use the preserve_ephemeral flag
19:51:45 <mrda> Shrews: How compliant are we?  ie. how much work will be required to bring the code up to scratch?
19:51:46 <NobodyCam> sda is TB in size
19:52:07 <Shrews> mrda: good question. there are A LOT of the E12? errors, but very few of the others
19:52:10 <lucasagomes> oh diff disks hmmm
19:52:11 <jroll> Shrews: though they are all indentation things... I tend to think our indentation is ok
19:52:23 <NobodyCam> they asked the question as that is wha there current deploy is doing
19:52:57 <Shrews> jroll: this is an example of the E111 error: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/drac/management.py#L50
19:52:58 <mrda> If we could knock off the majority and leave the indentation ones, without much work, I'd say do it
19:53:12 <jroll> Shrews: right, I think that's fine
19:53:37 <lucasagomes> Shrews, (as author) heh I don't mind that
19:53:46 <jroll> Shrews: I think E113, E129, and (maybe) E265 should be fixed
19:54:02 <devananda> Shrews: ugh, E111 is really annoying to me. actually all of the E1** are annoying but not a big problem
19:54:21 <devananda> mrda: E1** are all indentation related
19:54:22 <Shrews> devananda: luckily, that was the ONLY E111 problem   :)
19:54:32 <lucasagomes> Shrews, you have any example of E265 handy?
19:54:40 * mrda needs to wake up
19:54:53 <Shrews> lucasagomes: something like:  #NOTE(Shrews): blah blah
19:55:04 <jroll> lucasagomes: I've only ever seen those with """ style comments
19:55:06 <Shrews> instead of: # NOTE(Shrews) blah blah
19:55:07 <lucasagomes> oh missing the space
19:55:14 <Shrews> yeah
19:55:14 <lucasagomes> well... hmm
19:55:18 <jroll> Shrews: really?
19:55:22 <jroll> oh
19:55:23 <lucasagomes> I like that space, but as it's a comment I wouldn't really care much
19:55:24 <jroll> that
19:55:37 <jroll> let's do this
19:55:42 <jroll> clearly none of those matter a ton
19:55:50 <Shrews> right. this is all nitpicking at this point
19:55:50 <lucasagomes> failing on gate because of a space after # in a comment seems too much
19:55:59 <jroll> if someone feels strongly about them, they can do the work to get rid of them
19:56:01 <devananda> jroll: yes. '# NOTE(deva)' is correct. '#NOTE(deva)' is not. also, '""" NOTE(deva)' is not.
19:56:02 <Shrews> i fixed the major ones already
19:56:07 <NobodyCam> this could be a great batch of lhf
19:56:31 <devananda> so, this is stylistic sugar that will get someone easy commit stats
19:56:34 <lucasagomes> devananda, we use some """ <blah> """ in the api
19:56:44 <lucasagomes> as "docstrings" for the attributes
19:56:44 <devananda> lucasagomes: that is actually a doc string
19:56:48 <devananda> not a comment
19:56:48 <devananda> :)
19:56:49 <lucasagomes> right
19:56:50 <jroll> like, I would love to have all of those enabled, but I don't think anyone should do work to do this, unless they really care
19:56:51 <devananda> that's fine
19:56:58 <devananda> jroll: ++
19:57:05 <lucasagomes> yeah well I'm worrying if E269 would see it as a comment
19:57:15 <Shrews> jroll: devananda: all but the E12? errors will be very easy to fix
19:57:25 <jroll> someone will come along and think our code is horribly wrong because we ignore them, and they'll fix it
19:58:06 <NobodyCam> *two minute bell*
19:58:25 <devananda> NobodyCam: I think the answer is "not at this time".
19:58:39 <NobodyCam> ack :)
19:59:24 <jroll> sounds like we're done... thanks everybody :)
19:59:26 <devananda> NobodyCam: that they use /dev/sda for durable-state, and we use /dev/sda for operating system, was a design choice. We could make that a configuration option but then it runs into hardware limitations (eg, if the host requires /dev/sda to be bootable...)
19:59:36 <devananda> cheers, thanks all!
19:59:39 <lucasagomes> thanks
19:59:48 <NobodyCam> Thank you all :) great meeting
19:59:48 <devananda> #endmeeting