20:00:07 <skraynev_> #startmeeting Heat
20:00:09 <openstack> Meeting started Wed Dec 16 20:00:07 2015 UTC and is due to finish in 60 minutes.  The chair is skraynev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:12 <openstack> The meeting name has been set to 'heat'
20:00:16 <skraynev_> #topic rollcall
20:00:25 <jdob> o/
20:00:26 <Drago> o/
20:00:27 <prazumovsky> hi
20:00:31 <rpothier> o/
20:00:45 <pas-ha> o/
20:01:58 <skraynev_> #topic Adding items to agenda
20:02:09 <skraynev_> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-12-16_2000_UTC.29
20:02:26 <stevebaker> \o
20:03:13 <skraynev_> we have two nice questions in agenda (other is just reminders) ;)
20:03:33 <shardy> o/
20:03:34 <skraynev_> stevebaker: do you want to add something to agenda?
20:03:46 <skraynev_> shardy : ^
20:03:57 <skraynev_> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-12-16_2000_UTC.29
20:04:03 <stevebaker> lgtm
20:04:14 <skraynev_> if - no, we will continue.
20:04:29 <skraynev_> #topic Review priorities (https://etherpad.openstack.org/p/heat-reviews)
20:04:34 <shardy> skraynev_: nothing from me, thanks
20:04:41 <skraynev_> #link https://etherpad.openstack.org/p/heat-reviews
20:04:51 <skraynev_> shardy, stevebaker: ok
20:05:35 <stevebaker> gerrit is still down, this will make this topic difficult
20:05:53 <skraynev_> yeah...
20:06:00 <jdob> any word on what happened/when gerrit will be back?
20:06:07 <stevebaker> its due to be down for another hour
20:06:08 <pas-ha> in an hour
20:06:10 <jdob> i didnt look through the ML yet for any notification
20:06:13 <jdob> gotcha, thanks
20:06:20 <skraynev_> I just removed one about qos, because I know, that it was eventually implemented
20:06:20 <pas-ha> software update
20:06:32 <jdob> an hour is the perfect window for a nap :)
20:07:00 <skraynev_> jdob: :) not for us
20:07:15 <jdob> haha, damn, this meeting fits into that perfectly
20:07:17 <skraynev_> #topic Reno notes
20:07:43 <skraynev_> Just want to remind about adding Notes.
20:08:13 <skraynev_> it can be done in the same patch  (with feature or important change) or in follow up  patch
20:08:48 <skraynev_> I asked ramishra and tiantian. to add it for their BPs.
20:08:56 <skraynev_> looks easy and simple ;)
20:09:26 <skraynev_> also makes writing release notes at the end of cycle easier ;)
20:09:33 <stevebaker> when backporting changes I assume the reno commit would need to be backported too, so it would be helpful if the reno is in the same commit as the change
20:09:56 <pas-ha> I would ask all cores when reviewing to require a release note for any bp or >=High bug fix
20:09:57 <stevebaker> but I don't think we need to make that mandatory yet
20:10:01 <skraynev_> stevebaker: good catch. +1 for this idea
20:10:38 <skraynev_> stevebaker: AFAIK, it will be required after m2
20:10:47 <stevebaker> ok
20:11:12 <skraynev_> need to ask ttx or dhellmann about it
20:11:47 <skraynev_> pas-ha: yes. for High bugs it will be good
20:12:10 <skraynev_> ok. go to the next item
20:12:12 <skraynev_> #topic New release of python-heatclient
20:12:21 <skraynev_> Do we need new release?
20:12:37 <stevebaker> let me look
20:12:51 <skraynev_> #link https://github.com/openstack/python-heatclient/tree/0.8.0
20:12:56 <skraynev_> 16 Sep
20:13:30 <skraynev_> date of tag
20:13:52 <shardy> stevebaker: re my discussion with jdob yesterday, do we still only tag releases from master?
20:13:59 <skraynev_> stevebaker: I just worried about new API for outputs.
20:14:21 <stevebaker> shardy: there is a stable branch, which we're yet to release from
20:14:44 <shardy> stevebaker: k, I wasn't sure as we were discussing a potentially backwards incompatible change
20:14:46 <stevebaker> I'm only seeing a handful of fixes
20:14:49 <pas-ha> shardy, if there were backports, we could release a microversion update from stable branch
20:15:04 <shardy> my take was it's best to keep master backwards compatible where possible
20:15:37 <jdob> to be clear, it's the client being able to use older versions of the server
20:15:38 <shardy> e.g it wouldn't make sense if the pypi version of heatclient was broken will all stable/released heat versions?
20:15:57 <skraynev_> stevebaker: but we need to merge one patch first... Which allows to work new heatclient with old versions (support new API was done without backward compatibility...  ) I thought, that it was ok, but then realized, that it looks bad
20:16:00 <shardy> sorry, slight tangent on the release, but I wanted to clarify
20:16:02 <jdob> (as compared to a number of other ways we could break backward compat)
20:16:42 <stevebaker> sorry, I don't know the background for this outputs api change
20:17:12 <shardy> the discussion w/jdob was about moving to server-side evaluation of environments
20:17:26 <jdob> shardy: we're talking two different things here
20:17:29 <shardy> I suggested we should fall-back to the client-side approach
20:17:29 <skraynev_> stevebaker: I can only show merged patch. will it be enough ?
20:17:32 <jdob> the outputs API v. the server-side env
20:17:37 <shardy> jdob: Yeah
20:17:52 <jdob> though I suppose the question applies in both cases
20:18:03 <shardy> IMO it's fine to add new features which fail on older versions, but not break existing interfaces
20:18:06 <skraynev_> stevebaker: https://github.com/openstack/python-heatclient/commit/d06bcd87d98a337a93cfc7709d6f440a972bb127
20:18:59 <skraynev_> stevebaker: we fully migrated to new api calls, but they are not presented in old versions. so...
20:19:21 <skraynev_> there is one patch on review , which we can not look right now.
20:19:43 <jdob> given that this is coming up more and more, should we start working towards .y versions on the REST API?
20:19:56 <stevebaker> skraynev_: ok, so for outputs we need to fix those commands to fall back to extracting them from a stack GET if the output call fails?
20:19:59 <skraynev_> stevebaker: this one https://review.openstack.org/257963
20:20:56 <skraynev_> stevebaker: in mentioned patch we catch NotFound and try to get outputs using the old way (as you said via getting stack)
20:21:04 <shardy> jdob: probably, but it'll be a lot of work and nobody has yet stepped up to do it
20:21:46 <jdob> i'm off for the next two weeks, but when I get back, unless it's magically done I'll start putting togheter a spec for it
20:22:02 <skraynev_> shardy: can you describe plan in spec and we will find a volunteer :)
20:22:06 <jdob> wasnt sure if there was a specific reason we hadn't moved towards it (other than lack of times/resources)
20:22:23 <stevebaker> jdob: as for envs, if the env list is specified in a new argument I think an older heat would reject that, and heatclient could use that response to fall back to a client-side merge
20:22:23 <skraynev_> shardy: or... jdob is our volunteer ;)
20:22:24 <shardy> skraynev_: sounds like jdob will do it :)
20:22:27 <shardy> thanks jdob!
20:22:34 <jdob> thats another option, if you had the time for the spec, I'd volunteer as tribute
20:22:36 <skraynev_> shardy: agreed
20:22:54 <jdob> stevebaker: ok, thats the approach i was going to take, just wanted to check with you to see if there was anything smoother
20:23:04 <jdob> and apparently, I'll be working on making that smoother in the new year :D
20:23:06 <stevebaker> jdob: nothing occurs to me
20:23:08 <shardy> jdob: basically we need to look at the cross-project view of what's happening wrt API micro-versions and align with what other projects are doing
20:23:32 <shardy> jdob: my main concern is making it transparent to users, e.g look at the huge pain caused by migration to keystone v3
20:23:48 <jdob> my hope is that we seem very disciplined in the RPC API handling and can translate some of those practices over
20:23:57 <skraynev_> shardy: may be nova has enough experience in this area
20:23:59 <skraynev_> ?
20:24:01 <shardy> we have to look at patterns which make it completely simple for users, even those not using the python clients
20:24:03 <stevebaker> so back to the topic, maybe we should backport the few real fixes to the heatclient stable branch, given that master is gradually landing osc commands currently
20:24:47 <shardy> stevebaker: +1, if we're going to release from it we should monitor and backport where appropriate
20:25:38 <skraynev_> stevebaker: +1 for backports. However, what;s about new version of client? I mean new tag for pip
20:26:24 <skraynev_> it will allow to install latest code from pip package.
20:26:48 <shardy> skraynev_: Yeah that was my question, e.g if you do pip install heatclient, do you get a version which will only work with an unreleased development version of heat?
20:26:55 <stevebaker> skraynev_: I think we just push a change to the releases repo
20:26:59 <shardy> traditionally that has not been the case
20:27:15 <shardy> and lifeless has a spec re making stronger promises for client backwards compat
20:27:35 <stevebaker> skraynev_: http://git.openstack.org/cgit/openstack/releases/tree/deliverables/liberty/python-heatclient.yaml
20:27:49 <stevebaker> skraynev_: then magic happens
20:27:54 <shardy> it's a cross project spec, so we should monitor it as it may mean we don't want to do any irreversable backwards incompatible things
20:28:04 * shardy would link it but... gerrit
20:28:13 <dims> if magic does not happen quickly hop onto #openstack-release :)
20:28:52 <dims> shardy : net,net of that was no "active" releases should break with a new library release
20:29:27 <shardy> dims: what about python-*client's - do they have to maintain compatibility with all non-EOL stable releases of the services?
20:29:45 <dims> shardy : y that was the proposal
20:29:54 <shardy> dims: Ok, thanks for the clarification!
20:30:01 <stevebaker> skraynev_: I'm about to go off the grid for 3 weeks, I can continue whatever backport process that is done when I get back
20:30:13 <shardy> that's pretty much a complete reversal of the direction we were taking with the stable-branches for all-the-clients ;)
20:30:24 <skraynev_> shardy: hm.. I suppose, that this client should work with all previously released versions, but it may no support for new release (which currently is not released and in development right now..)
20:31:42 <skraynev_> stevebaker: so do you suggest wait all backports first, right?
20:32:08 <lifeless> shardy: hai
20:32:12 <skraynev_> or it's not related with new tag at all :)
20:32:22 <lifeless> https://review.openstack.org/#/c/226157/11/specs/backwards-compat-libs-clients.rst
20:32:38 <shardy> hey lifeless, thanks for the link ;)
20:33:29 <stevebaker> gerrit down
20:34:02 <lifeless> yah
20:34:04 <skraynev_> :(
20:34:08 <lifeless> I just happen to have it in my browser :)
20:34:23 <lifeless> but the tl;dr is pretty simple
20:34:32 <lifeless> don't break compat with supported things
20:34:38 <stevebaker> lifeless: just regarding timing, we have stable client branches now, and in the future likely not. For now should we be using those stable branches?
20:34:44 <lifeless> derprecation is ok
20:35:10 <lifeless> stevebaker: so, this is really orthogonal to having stable branches or not of things
20:35:25 <lifeless> stevebaker: redistributors very much don't trust us not to mess up on master
20:35:33 <lifeless> so they want stable things to mitigate risk
20:35:46 <jdob> lifeless: do you know if the other projects have adopted some form of more finely versioned REST APIs in all of this?
20:35:48 <lifeless> and - they're not wrong: we're not mature enough to avoid a raft of ways things can break
20:36:07 <lifeless> jdob: like novas?
20:36:10 <pas-ha> jdob, Ironic has api microversions
20:36:26 <jdob> we were talking about nova as an example earlier, i didnt know about ironic
20:36:44 <jdob> i was basically wondering since everyone was gonna have these troubles if a clear convention was rising up
20:36:53 <jdob> sounds like the best bet is to check out what nova's doing
20:37:02 <lifeless> jdob: so there's three separate discussions
20:37:20 <lifeless> one, already had, is server compat tag:follows-standard-deprecation
20:37:36 <lifeless> which is 'minimum of one release cycle for changes affecting users', more or less
20:37:38 <stevebaker> stable releases by the looks of it http://git.openstack.org/cgit/openstack/releases/tree/deliverables/liberty/python-novaclient.yaml
20:38:10 <lifeless> stevebaker: like I said, stable clients are really orthogonal: they don't remove the need for backwards compat
20:38:20 <stevebaker> sure, I totally agree
20:38:20 <lifeless> stevebaker: and they don't remove the impact of backwards incompat on users
20:38:39 <lifeless> stevebaker: cool; I've had contrary positions argued is all :)
20:39:46 <stevebaker> we're reimplementing all commands in osc, so my desire to change existing heat commands is zero :) and our client lib is pretty stable
20:40:04 <shardy> lifeless: yeah, thanks, that clears things up, despite stable branches we still must not break backwards compat on master for heatclient
20:40:33 <shardy> a few patches have shown up recently where confusion on that point was created due to the existence of stable branches
20:41:30 <jdob> so the takeaway here is "don't break shit anywhere", right?
20:41:48 <lifeless> jdob: we can break it, just not if its supported
20:41:55 * jdob hopes that doesn't make it into the meeting notes
20:42:02 <jdob> ok
20:42:23 <lifeless> the third discussion, which is the one mordred is hoping to drive, is 'support things that were in an api forever'
20:42:31 <lifeless> I don't think there is consensus on that yet
20:42:32 <mordred> aroo?
20:42:35 <stevebaker> having said all that, once we have a full set of osc commands I'd like to consider releasing 1.0.0, since people have this weird opinion that projects < 1.0 are immature
20:42:43 <lifeless> though I have a lot of sympathy for the position
20:42:55 <jdob> stevebaker: +1
20:43:02 <lifeless> stevebaker: given that our semver docs say exactly that, its not all that weird :)
20:43:12 <shardy> "forever" is a long time..
20:43:16 <mordred> yup
20:43:21 <mordred> users are around for a long time
20:43:38 <mordred> also - for comparison, amazon has _never_ deleted an API
20:43:41 <stevebaker> lifeless: heh
20:43:41 <skraynev_> gentlemen: could you please summarize last resolutions: 1. we don't break old commands (because we should support everything old) 2. we stop adding new staff to heatclient 3. we mark heatclient as deprecated in favor of openstackclient. 4. we create last tag for deprecated client.
20:43:42 <mordred> and there's only one installation of that
20:43:46 <shardy> mordred: to clarify, keep supporting interfaces, never deprecate anything, ever?
20:43:53 <mordred> shardy: deprecate is fine
20:44:00 <mordred> shardy: remove is bad
20:44:18 <mordred> shardy: because we know that there is and always will be massive version skew in the world
20:44:24 <pas-ha> skraynev_, heatclient as Python API lib is never going to be deprecated
20:44:29 <mordred> so not dealing with seamless upgrades in our code
20:44:30 <pas-ha> only CLI part
20:44:36 <mordred> means that all of our end users have to do it
20:44:38 <shardy> mordred: deprecating then not ever being able to kill something will result in a lot of cruft or complex legacy translation code, but OK
20:44:43 <mordred> yes
20:44:44 <mordred> it will
20:44:50 <jdob> i see the concept, but the idea of deprecation without ever removing kinda defeats the purpose of deprecation in the first place
20:44:56 <mordred> but if we don't - then our end users have to do that cruft intheir code
20:45:22 <shardy> mordred: well, it might be they get warned to s/old/new for 2 years, and they just have to s/old/new
20:45:35 <skraynev_> pas-ha: what's about keystoneclient example?
20:45:35 <mordred> shardy: nope, that's deployers
20:45:36 <shardy> but your argument is we just s/old/new internally?
20:45:40 <mordred> yes
20:45:43 <pas-ha> same stuff
20:45:45 <mordred> my argument is that WE do compat
20:45:48 <shardy> we actually already do that fyi
20:45:54 <mordred> then you're awesome
20:45:59 <mordred> other projects not so much
20:46:00 <shardy> with all our deprecated/hidden resource properties
20:46:02 <pas-ha> it will be left as python api to actuall Keystone service
20:46:19 <mordred> the trick is, we can say for 2 years "move to this new version"
20:46:22 <pas-ha> with cli in osc and auth in keystoneauth
20:46:26 <mordred> but there are still diablo clouds in the wild
20:46:30 <mordred> so uses who use openstack
20:46:32 <lifeless> mordred: and then we have a keynote...
20:46:33 <jdob> do we want to pause on this deep dive and pick it up after the heat meeting?
20:46:34 <lifeless> mordred: yeah
20:46:45 <mordred> still need to account for diablo vs. current in their code
20:46:46 <jdob> feels like we got a bit off topic; valuable, but diverted the meeting a bit
20:47:08 <mordred> and when the differences are things like renaming username to user-name without also still accepting username
20:47:11 <mordred> it's like poking our users in the face for absolutely no reason
20:47:34 <shardy> Yeah this is interesting, but we should probably get back to the agenda ;)
20:47:35 <mordred> in any case, it sounds like shardy says that's already going on here, so SWEET
20:47:57 <shardy> mordred: yeah, it's already happening at least with some of our interfaces
20:48:01 <shardy> thanks for the input :)
20:48:33 <mordred> shardy: thanks for caring about your users
20:48:34 <skraynev_> shardy, mordred: I suggest to continue this discussion in IRC or on review,  if you don't mind
20:48:36 <jdob> ya, thanks lifeless and mordred, that was useful
20:48:37 <mordred> ++
20:49:19 <skraynev_> so. about topic. can somebody clarify me, what is the decision?
20:49:48 <skraynev_> about backports to stable/liberty - we have agreement.
20:50:15 <jdob> we should be -1ing client patches that don't have some sort of safety against old server APIs
20:50:34 <skraynev_> jdob: ok.
20:50:45 <lifeless> -2'ing
20:50:50 <skraynev_> what about new tag? and when?
20:51:06 <skraynev_> stevebaker: shardy ^
20:51:23 <shardy> jdob: yeah it's something to keep a look out for
20:51:39 <shardy> lifeless: we're all about the educational -1'ing in the heat community ;)
20:51:52 <jdob> not to mention i'm not core, so the best I could do is -1  :D
20:51:57 <stevebaker> skraynev_: lets do a 0.8.1 in Jan, and a 1.0.0 when there are enough osc commands to justify it
20:51:57 <jdob> we know of two cases already:
20:52:05 <jdob> my env patch and the outputs API one
20:52:17 <skraynev_> stevebaker: good. thx. I am happy now ;)
20:52:29 <jdob> what I didn't understand was the comment made a bit ago about no further changes to heatclient v. osc
20:52:55 <jdob> or, rather, I'd like a formal restating if that's something we need to be doing
20:53:40 <skraynev_> jdob: I suppose, that we plan to add new staff to osc instead of heatclient directly...
20:53:50 <skraynev_> #topic Summer Meet-up gently reminder
20:54:03 <shardy> jdob: new features could go only into the osc plugin, leaving the old heatclient CLI stuff working but not having all the latest features
20:54:21 <jdob> i'll ping you in #heat, I have some more questions about the state of the osc work
20:54:23 <shardy> I'm not sure we've agreed on doing that, but e.g keystone has already gone in that direction
20:54:46 <skraynev_> I have send mails about plans for potential summer meet-up. So if you have some ideas - fell free to send response me.
20:55:08 <skraynev_> #topic gate-tempest-dsvm-neutron-src-python-heatclient - what does it test??
20:55:18 <shardy> skraynev_: it's a bit hard to respond other than for availability, as there's no agenda and we've got another summit before
20:55:36 <shardy> skraynev_: what/where's the proposed venue?
20:55:59 <jdob> i missed that email too, this is new to me
20:56:18 <skraynev_> shardy: currently the best candidate is convergence future
20:56:23 <shardy> jdob: vague plans around a mid-cycle meetup, in the N cycle
20:57:08 <skraynev_> shardy: p.s. it's good chance to add some ideas for venue
20:57:56 <skraynev_> pas-ha: ping
20:58:03 <pas-ha> yes
20:58:08 <skraynev_> 3 minutes... :(
20:58:39 <pas-ha> basically the job I am talking is not even having heat installed
20:59:06 <pas-ha> so I wonder what is it testing in heatclient???
20:59:14 <skraynev_> shardy: yeah. the best word is vague plans. So any suggestions are welcome
21:00:08 <pas-ha> gate-tempest-dsvm-neutron-src-python-heatclient  that is the job
21:00:18 <skraynev_> #endmeeting