17:00:47 <devananda> #startmeeting ironic
17:00:48 <openstack> Meeting started Mon Mar  9 17:00:47 2015 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:52 <openstack> The meeting name has been set to 'ironic'
17:00:59 <rloo> o/
17:01:06 <TheJulia> o/
17:01:10 <devananda> as usual, the agenda is up -- https://wiki.openstack.org/wiki/Meetings/Ironic
17:01:39 <jgrimm> o/
17:01:45 <devananda> it looks fairly light today, but I suspect we'll spend a fair bit of time on stuff
17:01:57 <devananda> #topic announcements
17:01:59 <GheRivero> o/
17:02:16 <devananda> no announcements, just a reminder  -- we've now past the "feature proposal freeze" point
17:02:18 <d0ugal> o/
17:02:26 <mjturek1> o/
17:02:35 <devananda> ie, no more specs should land for Kilo, because we already have a *TON* of work ahead of us, and only two weeks to land it
17:02:55 <devananda> the exception possibly being the spec on api microversions (will get to that soon)
17:03:11 <devananda> because it is informational and we've already actually landed the code
17:03:16 <devananda> like, a month ago.
17:03:18 <devananda> anyway...
17:03:21 <NobodyCam> :)
17:03:32 <lucasagomes> :) good
17:03:37 <devananda> we're tracking the ongoing work here
17:03:39 <devananda> #link https://launchpad.net/ironic/+milestone/kilo-3
17:04:05 <devananda> during the next month (leading up to k3 and the subsequent RC release) please review things based on their status on launchpad
17:04:08 <rloo> what does 'good progress' mean? no code to review yet?
17:04:24 <devananda> rloo: means there is still code to be written, not available for review yet
17:04:24 <lucasagomes> I think we have a status for need code review
17:04:27 <devananda> which concerns me
17:04:39 <wanyen> deva, partition image for IPA was on KIlo3 lp now it's not there
17:04:45 <Nisha> devananda, but for inspection code is there for review
17:04:48 <devananda> we have a very aggressive goal here - another 16 "features" to review
17:05:10 <devananda> if a blueprint is assigned to you and the status is incorrect -- dont tell me. go update it
17:05:23 <devananda> if it needs more code, put it in "* progress"
17:05:24 <Nisha> devananda, ok
17:05:30 <devananda> if ALL the code is up, put it in "needs review"
17:05:41 <devananda> if ALL the code is landed, but it still needs docs or tests -- it is NOT done
17:06:05 <lucasagomes> the support for local boot, code-wise pretty much landed already
17:06:10 <lucasagomes> need docs ofc
17:06:13 <devananda> I will continue to bump things as we get closer to feature freeze, which is only two weeks agao
17:06:16 <devananda> *away
17:06:26 <devananda> some docs can be done after that cut-off, too
17:06:28 * lucasagomes will mark as implented later
17:07:04 <BadCub> lucasagomes: which one do you need implemented. I can update that one for you later today
17:07:09 <NobodyCam> I'd like to just mention that we should also start to think about our thrid part testing needs.
17:07:10 <devananda> don't hestitate to ping me or BadCub if something looks like the status is wrong and you can't change it, or you think something is not going ot make it and should be re-targeted
17:07:19 <wanyen> lucas: is uefi local boot coded landed?
17:07:25 <devananda> NobodyCam: sure. but not in the next two weeks :)
17:07:32 <NobodyCam> oh ya
17:07:35 <lucasagomes> BadCub, https://blueprints.launchpad.net/ironic/+spec/local-boot-support-with-partition-images
17:07:38 <devananda> NobodyCam: I think discussing our third-party testing (and all testing of drivers) is a great vancouver topic
17:07:40 <NobodyCam> deff not until after L
17:07:41 <lucasagomes> wanyen, it wasn't part of the spec
17:07:42 <NobodyCam> opend
17:07:45 <NobodyCam> opens
17:08:09 <rameshg87> wanyen: we are still working on it, there are couple of reviews already out
17:08:10 <wanyen> lucas:  The spec that Faizan proposed include uefi local boot
17:08:16 <devananda> that's it for announcements -- let's move on, and we can continue discussing specific proposals in the opendiscussion later
17:08:17 <BadCub> thanks lucasagomes do you want me to change it now, r is there something else you need to add first?
17:08:58 <lucasagomes> BadCub, wanyen I think it's out of topic a bit. I ping you guys on the channel
17:09:02 <devananda> #info feature proposal freeze is past. feature freeze is in two weeks. please revie all the code, following priorities on LP.
17:09:18 <devananda> #info ping BadCub or devananda if you believe a status is wrong AND you can't change it yourself
17:09:22 <devananda> #topic subteam status reports
17:09:55 <devananda> adam_g: I saw you doing a bunch of functional-test-related things last week - but I dont see any notes on the white board
17:10:05 <devananda> adam_g: is the status worth sharing yet? or still in-flight?
17:10:50 <devananda> I see a note that we don't have naohirot today. I'll update the 'pad
17:12:03 <devananda> GheRivero: looks like a lot of changes coming from oslo recently? wow ...
17:12:28 <GheRivero> mostly synced and minor changes to use released versions
17:12:41 <devananda> GheRivero: ok, cool. anything you feel is high-risk for this late in the cycle?
17:13:01 <GheRivero> not really.
17:13:10 <devananda> great
17:13:59 <devananda> ok - any further comments on drivers before we move on?
17:14:26 <jroll> just pointing out that pxe_ipa is now running on check
17:14:28 <jroll> \o/
17:14:31 <devananda> (giving folks anoter minute)
17:14:49 <stendulker_> devananda: We want two ilo defects milestone to be changed to kilo-3
17:15:04 <stendulker_> #link https://bugs.launchpad.net/ironic/+bug/1418327
17:15:06 <openstack> Launchpad bug 1418327 in Ironic "pxe_ilo and iscsi_ilo driver sets capabilities:boot_mode in node property if there is none" [High,In progress] - Assigned to Shivanand Tendulker (shivanand-tendulker)
17:15:14 <stendulker_> #link ttps://bugs.launchpad.net/ironic/+bug/1412559
17:15:24 <stendulker_> #link https://bugs.launchpad.net/ironic/+bug/1412559
17:15:25 <openstack> Launchpad bug 1412559 in Ironic "agent_ilo deploy driver do not support uefi boot mode" [High,In progress] - Assigned to Shivanand Tendulker (shivanand-tendulker)
17:15:43 <lucasagomes> jroll, +1 o/
17:15:58 <jroll> agent / uefi sounds more like a feature :/
17:16:11 <devananda> #action devananda to review above bugs after the meeting
17:16:37 <wanyen> jroll, deva suggested us to file a bug for uefi/agent
17:16:37 <stendulker_> devananda: thanks
17:16:43 <Nisha> jroll, no it is just switching between boot modes in agent ilo driver
17:16:44 <jroll> huh. ok.
17:16:49 <jroll> right on
17:17:10 <devananda> thanks for the updates, everyone. let's move on
17:17:33 <devananda> #topic python client's default microversion
17:17:54 <devananda> for a bit of background here...
17:18:16 <devananda> about a month ago, I wrote up microversion support for our API, following Nova's spec on it
17:18:24 <devananda> though we didn't go through our own spec and just referenced theirs
17:18:49 <devananda> when we (in particular lintan_ ) started adding support to the client to pass a version header to the server
17:19:00 <devananda> there was considerable disagreement on what the default behavior should be
17:19:18 <devananda> and a discussion ensued on both lintan_ 's review and on the spec which mrda subsequently proposed
17:19:26 <devananda> #link https://review.openstack.org/#/c/155624/
17:19:32 <devananda> #link https://review.openstack.org/#/c/161110/
17:20:05 <devananda> I also started drafting a reply to rloo's concerns, but put it in an etherpad and asked -infra to sanity-check me
17:20:21 <devananda> I haven't gotten around to polishing it and actually sending it ... but it does provide some context none the less
17:20:24 <devananda> #link https://etherpad.openstack.org/p/oHVxTVRFix
17:20:40 <devananda> </end background>
17:20:43 <devananda> let's discuss :)
17:22:08 <Shrews> Probably would have been helpful to have reviewed these links before the meeting  :/
17:22:16 <rloo> note that the API defaults to minimum version if the version header isn't specified
17:22:47 <rameshg87> rloo: i guess that's why we introduced "latest"  (still reading through docs :( )
17:23:23 <rloo> rameshg87: yes, you can get max version if you specify 'latest'.
17:23:38 <rloo> rameshg87: the question is what to do if the user doesn't specify a version (or 'latest')
17:24:01 <rloo> devananda: I would like to distinguish the client library from the client CLI.
17:24:20 <rloo> devananda: or do you think they both should behave the same?
17:24:22 <jroll> +1
17:24:23 <devananda> rloo: i do not believe that's a valid distinction. as a user of the client, I consume it in both ways
17:24:48 <devananda> I believe there are two salient points here (and possibly more) -- how this impacts our testing, and how this impacts usability
17:25:15 <rloo> devananda: I can't really read the etherpad stuff and grok it in a few minutes. but it discusses our testing/usability. I'm worried about our users (maybe that is only rackspace so it doesn't matter)
17:25:23 <devananda> as a user, I *never* want to have to specify what version of the API to use. I just want my client to work with the server that I point it at
17:25:34 <jroll> rloo: we don't matter? :P
17:25:40 <devananda> rloo: I use it too. and I'm sure there are many other users out there
17:25:40 <lucasagomes> devananda, +1
17:25:43 <devananda> 9and in here)
17:25:49 <jroll> devananda: as a user, I don't want my client to break when I upgrade my server, either.
17:25:51 * lucasagomes still reading stuff
17:25:54 <rloo> devananda: we changed nova ironic driver so it recognizes NOSTATE and AVAILABLE. so if we change the default to be 'latest', the nova ironic driver won't break.
17:26:04 <jroll> devananda: or my applications that use the client.
17:26:07 <devananda> jroll: right. and I dont want a new client to break when I point it at an old server
17:26:09 <rloo> devananda: but what about others that don't have code that recognizes AVAILABLE yet?
17:26:24 <rloo> jroll: I mean you've/rackspace is probably uptodate anyway.
17:26:39 <jroll> rloo: ehhh. trying.
17:27:22 <devananda> rloo: so if there are applications using pyhton-ironicclient which upgrade the client library, we can reasonably expect them to look at the changelog and update the applicaiton accordingly
17:27:37 <devananda> rloo: we are not going to break an application which chooses to not upgrade the client
17:27:43 <jroll> I'm having trouble reasoning about all of the cases this touches, btw. still trying to wrap my head around it all.
17:28:32 <devananda> the current client is still passing no header by default
17:28:41 <devananda> which means that, by default, if we were to release Kilo like this,
17:28:49 <rloo> devananda: ok, if we can expect users to read the changelog, etc, then I am fine with whatever default you want to use.
17:28:50 <devananda> users will still get the "v1.1" API
17:28:52 <devananda> which is basically Juno
17:28:56 <devananda> er, sorry
17:29:17 <devananda> Juno + what ever we landed early this cycle before microversioning
17:29:22 <devananda> which I think is just maintenance_reason
17:29:36 <rloo> devananda: right. but you want the client to be changed so it defaults to the maximum version it supports/knows about.
17:30:27 <devananda> rloo: correct. and just to re-state: that is not the literal "latest" string, but a literal version (eg, 1.6) that we write into the client lib
17:30:28 <NobodyCam> I think that makes the most sense for our client
17:30:54 <devananda> however, i also want the client to be smarter about talking to older servers
17:30:54 <Shrews> If *I* am a user of a client, and I install the latest version of that client, I totally expect it to give me the EVERYTHING that is supported by both client and server. I would NOT want to have to explicitly tell it *anything* about versions
17:30:57 <devananda> and right now, it's not
17:31:03 <jroll> I think defaulting to latest is mostly good, but it does create effort when the application using the client relies on something (e.g. tempest breaks right now with >1.1)
17:31:04 <devananda> Shrews: exactly
17:31:10 <devananda> jroll: not "latest", no.
17:31:26 <jroll> right, I type slow.
17:31:40 <devananda> jroll: to be clear, "latest" is a valid version header value, which indicates to the server that it should use ITS latest, which is reasonably newer than what ever the client understands
17:31:45 <devananda> that is essentially the behavior we have today
17:32:05 <devananda> old client + new server == client should still work by disregarding pieces of the response thta it doesn't understand
17:32:11 <jroll> devananda: I know. I typed that before you clarified that you want to hardcode a version. unclear how I feel about that.
17:32:18 <devananda> k
17:32:37 <jroll> devananda: but it's probably reasonable to release a new client to get new API features, since we'll need to handle those properly
17:32:47 <devananda> Shrews: I also expect the client to work when pointed at some old server, the current server, and the server which I install tomorrow
17:32:47 <jroll> I feel like we're going to duplicate a lot of version checking code :|
17:32:50 <rloo> I also don't like what I feel is an inconsistency, that if the header isn't specified in API, the min version is used. But if no version is specified to the client, the client sends a header to use some max version.
17:33:17 <rloo> but really, i only care if we break people's applications, so since it is user beware when upgrading client, then I am fine with whatever.
17:33:28 <jroll> rloo: I tend to think that's fine. think about it as a client feature that it uses the latest it knows about
17:33:29 <devananda> rloo: the server "no header == min versoin" is there to support older clients that didn't pass any header
17:33:32 <Shrews> devananda: I do too. So the client should either know about different API version options (and which ones to present to the user), or the server could possibly return that info some how.
17:33:50 <JayF> Why can't the client query the API for what version it is, then make some decision on support based on that?
17:33:52 <devananda> rloo: whereas "new client sends the max version it understands" is the desired behavior going forward
17:33:59 <JayF> Shouldn't all the information for the client ot act sanely already exist?
17:34:02 <devananda> JayF: totally. that's actually the ideal case
17:34:21 <JayF> I feel like I'm missing some dimension of this problem, because it seems that's a clear solution?
17:34:22 <devananda> however we aren't even close to supporting multi-versioning in the client
17:34:25 <devananda> today
17:34:43 <lucasagomes> right
17:35:20 <wanyen> maybe for the future to support client-server version negotiation
17:35:34 <devananda> the client library wasn't designed to interact with servers of different versions, and so the code architecture doesn't facilitate it yet
17:35:34 <rloo> for me, it isn't a question of the client acting sanely (we can decide what 'sane' means). it was what if we break people's applications cuz the user using the client didn't specify a version, and now they get everything.
17:36:00 <devananda> rloo: so before we introduced microversions, that is exactly what clients got -- everything the server returned
17:36:14 <devananda> rloo: we're not changing that behavior
17:36:21 <rameshg87> devananda: +1
17:36:29 <devananda> rloo: previously, a user would install a new client version, and get new functionality form their client
17:36:42 <devananda> rloo: if we have the client NOT send any version header, we CHANGE that behavior
17:36:45 <rloo> devananda: right, before we introduced microversions, regardless of via API and client, the user got everything.
17:36:52 <devananda> and the client will stop exposing any new features ...
17:37:07 <rameshg87> devananda: same question was asked before. an example of logical names /v1/nodes/foo might have returned error, whereas before logical names user would expect error
17:37:25 <Shrews> devananda: sounds sort of like we want a protocol negotiation at connection time
17:37:27 <rloo> devananda: but we have now introduced microversions and ... this is a new world...
17:37:28 <BadCub> if the existing behavious is not changing, and the client was getting *allthethings* anyway, this seems logical path to take
17:37:33 <devananda> rameshg87: exactly.
17:37:36 <devananda> Shrews: yup!
17:37:45 <Shrews> fun
17:37:47 <devananda> BadCub: that's my point
17:37:55 <rameshg87> devananda: but i would assume it's not changing the behaviour
17:38:01 <rameshg87> devananda: it was just an extension right ?
17:38:07 <rloo> but we did change the existing behavior. if you send a request via the API w/o specifying the header, you don't get the latest, you get the minimum.
17:38:23 <devananda> I'd like the user experience to not change -- that is, "install new client, get new feature if my server supports it"
17:38:40 <lintan_> One question, why not let server use it's latest version if no specific version
17:38:45 <devananda> rloo: we changed that a month ago. I think that was a mistake on my part, which I'm trying to correct, and to prevent it landing in the Kilo release
17:39:04 <NobodyCam> devananda: that make sense to me, esp with the fact that client releases can hapen any time
17:39:17 <rloo> devananda: OH. Why didn't you say that before?
17:39:22 <devananda> rloo:  :)
17:39:26 <jroll> heh
17:39:28 <BadCub> lol
17:40:00 <devananda> rloo: so let me clarify what i may not have been clear about in hasty typing
17:40:08 <rloo> devananda: so, what do you want to happen if the user sends a request via API but doesn't specify a header?
17:40:36 <devananda> rloo: the change from NOSTATE -> AVAILABLE is actually a breaking API change
17:40:45 <devananda> technically, we should have gone to /v2/ at that point
17:40:57 <devananda> because it is a non-backwards-compatible change, and IF we were following SemVer
17:41:01 <devananda> we'd have to bump the major version
17:41:16 <rloo> devananda: I thought the whole idea of microversions was to deal with NOSTATE->AVAILABLE instead of a /v2
17:41:21 <devananda> microversions let us work around that
17:41:24 <devananda> rloo: exactly
17:41:26 <devananda> but
17:41:50 <devananda> if we're going to preserve the old behavior of /v1/, we need to accept that "no header" == min version == v1
17:42:03 <devananda> otherwise we just broke /v1/
17:42:12 <devananda> for anyone using the juno-era client
17:42:26 <devananda> and an upgrade from juno - kilo will be impossible
17:42:48 <devananda> we need to support juno/nova + kilo/ironic
17:42:57 <devananda> for the upgrade path that many folks will take
17:43:11 <JayF> What's the virtue in not making a /v2/?
17:43:39 <jroll> seems like a lot of work to change the name of a state.
17:43:41 <JayF> This is intentionally a little naive, but isn't it just a question of where the version goes? Why not bump the "big version"
17:43:46 <devananda> JayF: it's painful to make a new endpoint. users have to point somewhere else. keystone has two entries for ironic
17:44:10 <rloo> don't forget, this state thing is just one example. we could potentially have other features that aren't backwards compatible.
17:44:16 <JayF> Isn't it also painful to check microversions everywhere?
17:44:26 <jroll> heh. true.
17:44:30 <devananda> JayF: sort of. it's also about adding some sanity to our client-server negotiation. though I think we're still at least a cycle from that
17:45:15 <devananda> backwards-incompatible-changes are really hard ... this lets us deal with the only "mistake" we've found so far in the early API
17:45:29 <devananda> allow older clients to continue working, while newer clients can iterate on newer features
17:46:39 <NobodyCam> +1
17:47:40 <devananda> to be clear, we should continue to avoid making backwards-incompatible changes. I dont think microversions give us any carte blanche to make more -- they're going to continue to be just as painful for users, even if we're able to handle them slightly better in our CI environment now
17:48:10 <jroll> I mean, microversions do make it less painful
17:48:13 <jroll> (imho)
17:48:19 <devananda> for us, yes
17:48:25 <devananda> and for anyone using python-ironicclient - yes
17:48:35 <jroll> that's with my user hat on
17:48:40 <jroll> even without
17:48:44 <devananda> hm, ok
17:48:47 <jroll> keeps things from breaking
17:48:55 <jroll> as long as I specify a version :)
17:49:03 <devananda> ah - good point
17:49:10 <jroll> (which sucks, but if you're using something that's well versioned, you should specify your version)
17:49:16 <devananda> yup
17:49:26 <jroll> (kinda like how most non-openstack-people use requirements.txt)
17:49:30 <devananda> so, I think we need to move on, even if there's not a conclusion
17:49:37 <devananda> because we're almost out of time
17:49:53 <rloo> I thought we did conclude. Or I conceded anyway ;)
17:49:58 <devananda> rloo: oh :)
17:50:07 <jroll> heh
17:50:14 <NobodyCam> I think for us at this late point in the cycle it is our best solution. if we have time next cycle we could look at a negotiation
17:50:20 <NobodyCam> option
17:50:26 <devananda> #topic python-openstackclient support
17:50:36 <devananda> d0ugal: hi! sorry for the late inclusion here
17:50:39 <d0ugal> Hi :)
17:50:50 <d0ugal> devananda: No problem, I have a quick question, I think
17:50:52 <devananda> d0ugal: but the above discussion is hopefully at least slightly relevant too :)
17:50:59 <d0ugal> Indeed, it was
17:51:29 <d0ugal> My question - is anyone working on a plugin for python-openstackclient? and if not, is this something people are interested in?
17:51:47 <devananda> I am not aware of any earnest work on that
17:51:51 <jroll> to point 2) I'm interested
17:51:55 <NobodyCam> I have not heard of anyone working on it
17:51:59 <lucasagomes> I don't know anyone too
17:51:59 <d0ugal> I'm aiming to make the TripleO experience a bit nicer :)
17:52:22 <d0ugal> Okay, so if I wanted to help - would a spec be the place to start?
17:52:28 <devananda> d0ugal: iirc, there has been push-back a few times when ive been in discussions about adding ironic to common clients
17:52:42 <d0ugal> devananda: Right
17:52:45 <devananda> d0ugal: because thoes clients are geared towards end-users of clouds, whereas Ironic should never be visible to end-users
17:53:00 <devananda> it's an admin-facing service (the only one in openstack afaik)
17:53:01 <d0ugal> devananda: Unless your end users are TripleO users I guess :)
17:53:29 <d0ugal> Okay, so it sounds like I might need to take this to the list for further reach.
17:53:29 <devananda> d0ugal: so if openstackclient includes support for eg. nova's admin functions, then I think there's a good case for including ironic as well
17:53:42 <d0ugal> Gotcha
17:54:07 <d0ugal> There is a chance I may be working on one anyway, but wanted to make it upstream if we could
17:54:26 <d0ugal> I think that gives me enough to go on for now, thanks devananda
17:54:35 <devananda> d0ugal: great. welcome!
17:54:40 <devananda> #topic open discussion
17:55:21 <NobodyCam> I'd just like to point out this nova review for OD. https://review.openstack.org/#/c/158269
17:55:34 <devananda> oooh yah
17:55:39 <devananda> #link https://review.openstack.org/#/c/158269
17:55:47 <jroll> sick of fighting nova's model.
17:55:56 <devananda> #info Nova discussion on support for clustered / federated hypervisors is getting interesting. see above link
17:56:09 <devananda> jroll: you can bet there's going to be (yet another) session in vancouver on it
17:56:16 <jroll> devananda: oh ya
17:56:32 <devananda> though I think enough folks in Nova want to solve it the right way (tm) this time, too, that I'm hopeful we'll make progress
17:56:44 <NobodyCam> devananda: do you think that could land in K or will it be more likely L
17:56:52 <jroll> the question is if fixing it the right way will be prioritized at all.
17:57:05 <devananda> NobodyCam: wht's "that" ?
17:57:12 <NobodyCam> teh nova review
17:57:17 <NobodyCam> changes
17:57:19 <jroll> that patch? definitely not kilo
17:57:22 <devananda> NobodyCam: no. not that patch
17:57:26 <NobodyCam> :)
17:57:53 <devananda> jroll: thta's what I mean by "enough folks".
17:58:00 <jroll> yeah
17:58:01 <devananda> jroll: I think it's becoming a priority for several nova cores now
17:58:07 <jroll> ok, cool
17:58:12 <NobodyCam> * fyi: * 2 minutes to go *
17:59:27 <devananda> ok, thanks for the lively discussion today folks
17:59:34 <NobodyCam> Thank you all !
17:59:36 <devananda> see you all back in channel!
17:59:37 <NobodyCam> great meeting
17:59:43 <BadCub> thanks everyone!
17:59:55 <devananda> #endmeeting