05:00:11 <devananda> #startmeeting ironic
05:00:12 <openstack> Meeting started Tue Mar 17 05:00:11 2015 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:00:15 <openstack> The meeting name has been set to 'ironic'
05:00:18 <jlvillal> o/
05:00:24 <mrda> o/
05:00:26 <devananda> good morning / evening / late night, folks
05:00:43 <naohirot> o/
05:00:49 <JoshNang> o/
05:00:50 <ramineni> o/
05:00:52 <jroll> \o
05:00:55 <rameshg87> o/
05:01:52 <devananda> this is a pretty rough meeting time for some of us, and I suspect we'll be missing several folks
05:02:05 <devananda> ... but let's give them a couple more minutes before we dive in
05:02:11 * jroll rubs his eyes
05:02:22 <wanyen> o/
05:02:31 * rameshg87 gives jroll a glass of water :)
05:02:39 <lintan> o\
05:02:44 <devananda> nothing specific got added to the agenda last week, and I'm sure we're all focusing on kilo-3 right now
05:03:24 <devananda> so i'd just like to go over that, answer any questions folks have about the release process, etc, since we have a lot of new folks this cycle
05:03:33 <devananda> and because that's all the stuff that's on my mind right now :)
05:03:59 <rameshg87> devananda: mrda and myself just added one more item to agenda
05:04:10 <devananda> oh. /me refreshes
05:04:43 <naohirot> devananda: Is Ironic going to be official project after releasing kilo?
05:05:14 <devananda> naohirot: "official" is a strange word
05:05:25 <devananda> naohirot: what do you really mean?
05:05:40 <naohirot> devananda: I mean graduating incubation?
05:05:40 <wanyen> integrated?
05:05:48 <devananda> .... :-/
05:06:21 <naohirot> devananda: sorry if I used wrong word
05:06:36 <jroll> ironic is super official already, and has been for at least a few cycles
05:06:39 <jroll> (fwiw)
05:06:43 <devananda> yah
05:06:56 <devananda> naohirot: sorry, I'm just a little tired of answering that question
05:06:59 <devananda> naohirot: https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n179
05:07:13 <jroll> naohirot: I'm curious why it matters :)
05:07:14 <devananda> ironic graduated in Juno
05:07:32 <devananda> and the TC has abolished the process of incubation anyway
05:07:38 <devananda> so the point is moot now
05:07:49 <jlvillal> devananda: Does Ironic
05:07:59 <jlvillal> devananda: Does Ironic's status change at all when Kilo is released?
05:08:09 <devananda> anyway ... we should continue with the meeting. anyone who's not here yet is probably not joining
05:08:17 <jroll> jlvillal: totes, it's even more awesome!
05:08:28 <jroll> awesomer status.
05:08:31 <mrda> :)
05:08:32 <jroll> or something.
05:08:33 <devananda> jlvillal: we release another release with a bunch more awesome features? is that not enough?
05:08:44 <jlvillal> devananda: Works for me :)
05:08:51 <naohirot> devananda: I thought Ironic hasn't graduated, because Juno openstack manual doesn't mention about Ironic much
05:09:01 <devananda> I honestly dont know what "status" or "official" have to do with "does this project do what you need"
05:09:23 <devananda> naohirot: the manual has nothing to do with it ... BUT we should definitely contribute stuff to the manual!
05:09:35 <jroll> naohirot: being part of the integrated release is different from graduating. but honestly, those shouldn't mean anything to the user.
05:09:36 <devananda> let's table this. we could go on for a while ....
05:09:41 * jroll shuts up
05:10:05 <naohirot> devananda: Anyway I certainly understood that Ironic had graduated. :)
05:10:16 <devananda> #topic Kilo-3 status
05:10:24 <devananda> #link https://launchpad.net/ironic/+milestone/kilo-3
05:10:58 <devananda> So. kilo-3 will be tagged at some point in the next few days, basically when everything that we think we will land has landed
05:11:37 <wanyen> does that mean all the features on kilo3 LP?
05:11:39 <devananda> I havav been bumping a few things, and will start bumping features much more aggressively tomorrow if the code is still in review / needing refactoring / not looking like it's going to land
05:12:00 <devananda> wanyen: yes. that's the status page for the features we are tracking for kilo-3
05:12:32 <devananda> the core team has been coordinating on this etherpad, as we often do during review jam sessions
05:12:37 <devananda> #link https://etherpad.openstack.org/p/IronicReviewDay
05:12:45 <mrda> FWIW, I don't think all of API microversions can land, so it's "Informational" state is about right.
05:12:51 <devananda> mrda: totally
05:13:00 <mrda> Just bad timing
05:13:09 <devananda> mrda: on API microversions, there are server-side things and client-side things
05:13:24 <devananda> we can clean up some of the client stuff later -- that's not great, but it's doable from a release mgmt standpoint
05:13:30 <devananda> hoewver, we need to get ALL the server stuff done
05:13:40 <devananda> so, let's talk about that for a minute
05:13:48 <mrda> ok, thanks deva for the direction
05:14:00 * devananda wishes for a subtopic button
05:14:12 <devananda> #topic microversions
05:14:24 * naohirot jroll: devananda: whether graduated or not is important for company to decide whether company commit to Ironic or not.
05:15:03 <jroll> naohirot: we should come back to that later (or in the ironic channel), but that upsets me to no end
05:15:16 <rameshg87> devananda: is it the topic that mrda and myself added ?
05:15:27 <devananda> rameshg87: basically. but it was already something i wanted to talk about
05:15:45 <mrda> rameshg87: that is specific to behaviour for one particular case, whereas this is a little more general
05:15:52 <devananda> are there server-side changes we need in order to complete microversion support in kilo?
05:15:53 <rameshg87> okay
05:16:00 <rameshg87> devananda: yes
05:16:08 <naohirot> jroll: I'm terribly sorry
05:16:10 <devananda> rameshg87: link?
05:16:21 <rameshg87> devananda: and for https://review.openstack.org/163730
05:17:08 <devananda> right
05:17:11 <rameshg87> devananda: had a basic question is on server-side changes, that's why we brought the meeting topic
05:17:21 <rameshg87> the basic question is this - should we exactly emulte the previous behaviour for logical names (like in juno)?
05:17:25 <rameshg87> consider for example GET /v1/nodes/<>
05:17:31 <rameshg87> before logical names support (juno) - we give only 2 errors - 400 if the value sent is not a uuid OR 404 if node is not found
05:17:36 <devananda> #info https://review.openstack.org/#/c/163730/ adds logical name support for ports
05:17:42 <rameshg87> after logical names support (kilo) for older micro version < logical name support - we give 3 errors - 400 if value sent doesn't look like (uuid or logical name), 406 if they sent a logical name, 404 if node is not found (only for uuid)
05:17:52 <rameshg87> is this behaviour okay ?
05:18:09 <devananda> #info https://review.openstack.org/#/c/164369/ adds a v1.0 base version which is equivalent to stable/juno
05:18:32 <jroll> (to be clear, that's adding logical names for identifying a node to list ports for, not names for ports)
05:18:44 <devananda> jroll: right
05:18:48 <mrda> So we decided that if we tried to access an API that wasn't available until a later microversion, we'd return 406 Not Acceptable
05:18:59 <devananda> jroll: eg, GET /v1/ports?node=name   <<< mrda, right?
05:19:04 <mrda> we did that when we added name support in Ironic earlier in the cycle
05:19:06 <jroll> devananda: correct
05:19:40 <devananda> mrda: oh. I see. 406 because the header is wrong, not 404 NOT FOUND .... yah ...
05:20:04 <mrda> but that breaks backward compat, because for the same input we previously returned 400
05:20:19 <rameshg87> 406 - because they sent something-like-logical-name which is not supported for micro version
05:20:21 <mrda> "breaks backward compat" ick
05:20:27 <devananda> so there are some implications of microversions that make me cringe. this is one of them
05:20:33 <mrda> what I meant was that it now returns something different in that error situation
05:20:50 <mrda> We need to choose.
05:21:19 <devananda> mrda: relatedly, tae a look at the second link I pasted. it implements v1.0
05:21:30 <devananda> which we actually don't currently have
05:21:37 <mrda> devananda: I started reviewing that earlier :)
05:21:39 <devananda> our v1.1 != stable/juno right now
05:22:02 <devananda> going 'back in time' and implementing v1.0 is, as dtantsur pointed out, breaking backwards compat slightly
05:22:14 <devananda> if someone assumed that no header == some random point in kilo
05:22:21 <devananda> which, for a CD cloud, is fair
05:22:48 <devananda> but for a release-to-release deployment model, 164369 will help
05:23:00 <devananda> so, these are both tough questions
05:23:13 <mrda> I think that it's ok for us to return things like 406 if a new API is accessed by an old microversion is specified
05:23:15 <jlvillal> devananda: Which backwards compatibility is more important.  With a release or mid-release?  If I'm understanding what is being said.
05:23:40 <mrda> it is s/is/if/
05:23:57 <devananda> jlvillal: that's the question. I'm clearly in favor of release-to-release _right_now_  because we are currently following a 6-mo server release cycle
05:24:11 <jlvillal> I would also vote for release.
05:24:13 <devananda> whether or not that release cycle is good is orthogonal. we're following it now.
05:24:19 <jroll> side note: I wonder how many CD clouds are out there where deployer/operator/developer are very separate, enough where a small break like this would be painful
05:24:21 <mrda> yup
05:24:23 <devananda> so I think we should favor compat between major releases
05:24:31 <rameshg87> devananda: mrda: with a new api, it's a different story, but how about something basic like GET /v1/nodes
05:24:48 <jroll> if there's ever a tie, I also think release-to-release should win, as sad as releases make me
05:25:00 <rameshg87> devananda: mrda: is it the same ? a totally new error code is acceptable ?
05:25:03 <devananda> jroll: if releases were more frequent, I would still favor that
05:25:11 <devananda> *favor release-to-release over commit-to-commit
05:25:16 <jroll> devananda: as long as releases exist, yeah
05:25:24 <jroll> which they likely always will
05:25:33 <devananda> jroll: we'll always have a release of some form, not just git SHAs
05:25:38 * jroll head in the clouds
05:25:54 * mrda sees jroll standing on a soapbox :)
05:25:59 <devananda> heh
05:26:12 <mrda> So, we need to decide.
05:26:18 <devananda> s/always/insert longer explanation of thoughts here/
05:26:34 <devananda> mrda: indeed
05:26:58 <mrda> Exactly the same API? Allow some differences, but only enough to allow the API to evolve and give useful errors?
05:27:43 <devananda> rameshg87: if i understand, GET /v1/nodes/XXXX should continue to return 404 NOT FOUND if the requested identifier is neither a matched UUID nor a matched NAME
05:28:03 <mrda> I think we decided the latter (i.e. review 141737 where we introduced 406), but this review opens it up for us to validate that decision
05:28:33 <jroll> this is basically a matrix, we need a whiteboard
05:29:02 <devananda> yea, we're not going to solve that tonight
05:29:12 <devananda> at least my brain isn't
05:29:46 <devananda> mrda: rameshg87: can you sketch out the implications here on a whiteboard and we'll discuss tomorrow?
05:29:57 <rameshg87> devananda: sure ..
05:30:14 <devananda> if the implication is "we dont support logical names for PORTs in Kilo" -- well ,that's not the end of hte world
05:30:18 <devananda> it's a limited API
05:30:23 <mrda> sure, FWIW, I think looking at it from use cases (ref https://review.openstack.org/#/c/163730/3/ironic/api/controllers/v1/utils.py) is helpful
05:30:40 <jroll> I don't think it's a huge deal to land it for ports the same way it works for nodes today
05:30:48 <jroll> and I think the big question here is "should we fix nodes"
05:30:56 <rameshg87> jroll: yeah
05:31:00 <devananda> jroll: right
05:31:15 <devananda> i'm not seeing the problem for nodes yet. /me needs to see the matrix
05:31:19 <mrda> well, I think what is K will be the decision.  So we'd better decide before K-RC-Final
05:31:28 <mrda> :)
05:31:31 <devananda> mrda: yup
05:31:32 <jroll> so like, let's land the ports thing and iterate?
05:31:50 <mrda> I'm happy to etherpad something up
05:32:07 <mrda> and we can land 163730 and interate
05:32:11 <mrda> iterate
05:32:15 <jroll> woot.
05:32:28 <rameshg87> +1
05:32:31 <devananda> great. moving on :)
05:32:57 <devananda> #topic Kilo-3 status
05:33:05 <devananda> or rather, moving back to the main topic
05:33:33 <devananda> I see a couple patches in merge-conflict ... hoping folks will rebase soon
05:34:00 * jroll checks if still in conflict
05:34:17 <devananda> https://review.openstack.org/#/c/151596/ and https://review.openstack.org/#/c/163572/ implement out of band discovery for iLO
05:34:35 <jroll> two of them were not
05:34:43 <devananda> I'd love to get some non-HP eyes on these, as they look ready to land,
05:35:08 <jroll> JoshNang mentioned he figured out https://review.openstack.org/#/c/161453/ and is hacking on a devstack patch
05:35:13 <jroll> (cleaning for agent driver)
05:35:29 <devananda> jroll: awesome - i wsa just about to ask as I hadn't seen any progress
05:35:31 <JoshNang> yah. also filling in missing tests
05:35:52 <devananda> that's a really crucial one, IMO, but if we need a change in devstack to be able to move forward,
05:35:56 <devananda> it's going to be really tight
05:36:01 <JoshNang> agreed
05:36:04 <jroll> we can get it done, it should be a small change
05:36:10 <jroll> one line AIUI
05:36:14 <devananda> honestly not sure that we can push that through, but I'll do what I can to help
05:36:19 <devananda> oh - heh
05:36:21 <JoshNang> thank you :)
05:36:27 <JoshNang> yeah, need the cleaning network uuid in the config file
05:36:30 <devananda> smaller the better
05:36:56 <jroll> and with depends-on we should be able to +A the ironic change whenever
05:37:08 <devananda> JoshNang: we also need to be prepared for the Nova changes not to land
05:37:23 <JoshNang> devananda: yup. fingers crossed they will, but no movement on them today from cores :/
05:37:35 <JoshNang> though, they didn't pass jenkins until mid afternoon.
05:37:43 <devananda> i can poke a few cores directly, but nova's freeze policy is much stronger than ours right now
05:38:00 <jroll> I think the best route, if nova changes don't land, is to disable cleaning by default
05:38:04 <jroll> as horrible as that is
05:38:07 <JoshNang> agreed
05:38:18 <devananda> yea. it makes me sad, but yea ...
05:38:50 <devananda> #action devananda to poke nova cores re: new cleaning states
05:39:19 <jroll> JoshNang: you should poke a couple cores you know too :P
05:39:25 <JoshNang> jroll: i will :)
05:39:40 <devananda> there are also a slew of changes for the iLO driver, adding cleaning and uefi boot support
05:39:59 <rameshg87> and uefi secure boot too - that's the least reviewed of all :(
05:40:24 <rameshg87> would like to have some reviews at that ..
05:40:46 <wanyen> ramesh87: +1
05:41:23 <ramineni> ilo cleaning is fairly simple - https://review.openstack.org/#/c/157715/ , should be able to land , hoping some reviews
05:42:54 <JoshNang> last time i looked, that one looked ready
05:42:55 <devananda> given the risk that cleaning might need to be disabled by default, would it be better to focus your work on the uefi patches?
05:42:56 <mrda> JoshNang: can you PM me the Nova code review?
05:43:30 <JoshNang> mrda: i'll put in channel
05:44:21 <jroll> devananda: I think that code is still valuable even if disabled by default
05:44:33 <devananda> jroll: ack
05:44:51 <jroll> (but maybe uefi is more valuable, dunno)
05:45:22 <devananda> hmm. the 'pad section for UEFi doesn't match gerrit very well
05:45:25 <wanyen> devananda,  secure boot is importatnt for ilo drivers
05:46:10 * rameshg87 checks etherpad
05:47:33 <devananda> fixed, i think
05:48:35 <devananda> there's also the cisco UCS driver -- looks like last revision was < 24 hours ago so it's still current
05:49:06 <rameshg87> devananda: the code is mostly in code shape except for small things - it needs more tests as per the last patch set (according to me)
05:49:18 <rameshg87> i mean good shape :)
05:49:43 <devananda> rameshg87: ok. is that stuff which can reasonably be followed up (ie, adding more unit tests) next week?
05:50:03 <jlvillal> FYI: 10 minutes remaining
05:50:15 <rameshg87> devananda: if that's okay .. it's more like not all code paths in all functions are tested
05:50:18 <devananda> i'd like to be able to include it, but on the other hand, the first code drop on that BP was less than a month ago
05:51:17 <jroll> I'm inclined to drop it as it's going to be a distraction
05:51:30 <devananda> yup
05:51:32 <rameshg87> devananda: most of the hard-specific code is moved to cisco's python library. so it's only power and management code mostly calling these methods.
05:51:41 <rameshg87> i mean hardware-specific
05:52:28 <devananda> huh
05:52:35 <devananda> it requires the cisco SDK? https://github.com/CiscoUcs/UcsPythonSDK
05:52:41 <devananda> that's ... odd :(
05:52:51 <jroll> why is that odd?
05:53:05 <devananda> maybe just hte name is odd
05:53:07 <jroll> (other than that library has zero tests)
05:53:14 <jroll> yeah, I've never liked the word sdk
05:53:19 <jroll> "word"
05:53:26 <devananda> also, the library is a port of java code
05:53:31 <devananda> anyway
05:53:38 <devananda> i'm OK bumping it if we dont have time
05:53:54 <jroll> oh man, don't read that code
05:54:10 <devananda> that review hasn't been around very long, and a lot of other hard work has been done by folks throughout the cycle -- and that takes priority, in my opinion
05:54:21 <jroll> +1
05:54:57 <stendulker> To all cores: All ilo secure boot patches have been rebased. Please have a look at these patches.
05:56:26 <devananda> stendulker: thanks!
05:56:30 * rameshg87 notes 4 minutes left
05:56:38 <devananda> #topic open discussion
05:57:00 * mrda notes that rameshg87 and my action item is dealt with already
05:57:08 <devananda> mrda: link?
05:57:23 <mrda> sorry, not action item, I meant agenda item
05:57:31 <mrda> I'll post the etherpad link in channel later tonight
05:57:33 * jroll points out that people are working their butts off and I thank them for that
05:57:48 <devananda> oh
05:58:01 <devananda> mrda: ty
05:58:02 <rameshg87> devananda: just to confirm except for the return codes thing which still needs discussion - we have decided to land the port's patch (for accepting logical names), right ?
05:58:09 <devananda> also, what jroll said ...
05:58:23 <jroll> rameshg87: let's review the patch before we land it :P
05:58:32 <devananda> everyone is doing an incredible job focusing on reviews and fixing things rapidly :)
05:58:34 <mrda> rameshg87: I'm taking today's discussion as a yes :-P
05:58:36 <rameshg87> i meant that implicitly :)
05:58:46 <rameshg87> jroll: ^^
05:58:57 <jroll> yeah, was a joke :P
05:59:06 <mrda> :)
05:59:58 * jroll hears his bed calling
06:00:05 <devananda> thanks, ya'll! see you again soon -- after I sleep :)
06:00:13 <lintan> good night :)
06:00:19 <mrda> thanks everyone!
06:00:22 <jroll> thanks everyone, good night
06:00:27 <rameshg87> good night and good day  folks  (which ever is applicable)
06:00:27 <JoshNang> o/
06:00:31 <wanyen> good night!
06:00:35 <devananda> #endmeeting