20:00:16 <stevebaker> #startmeeting heat
20:00:16 <openstack> Meeting started Wed Sep 23 20:00:16 2015 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:20 <openstack> The meeting name has been set to 'heat'
20:00:29 <stevebaker> #topic rollcall
20:00:30 <prazumovsky> hi all!
20:00:34 <Drago> o/
20:00:35 <jasond> o/
20:01:07 <tspatzier> hi
20:01:13 <pas-ha> o/
20:01:18 <jdob> o/
20:01:27 <stevebaker> this will be my last meeting as PTL!
20:02:01 <skraynev_> o/
20:02:03 <stevebaker> oh, skraynev is here
20:02:12 <shardy_afk> o/
20:02:32 <stevebaker> zaneb: ping
20:02:43 <stevebaker> #topic adding items to the agenda https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-09-23_2000_UTC.29
20:02:49 <zaneb> oh, it's that week
20:03:09 * ryansb is late for attendance
20:03:09 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-09-23_2000_UTC.29
20:04:12 <stevebaker> #topic rc1 is out, lets go through potential rc2 bugs
20:04:26 <stevebaker> rc1 is indeed out!
20:04:26 <zaneb> skraynev_: loved your PTL candidacy message btw
20:04:35 <skraynev_> do we have a list ?
20:04:42 <pas-ha> #link https://bugs.launchpad.net/heat/+bugs?field.tag=liberty-rc-potential
20:04:42 <skraynev_> of potential bugs ?
20:04:48 <pas-ha> this one?
20:04:56 <skraynev_> pas-ha: thx :)
20:05:10 <stevebaker> we have a regression on nova-network, so we'll need an rc2
20:05:22 <stevebaker> https://bugs.launchpad.net/heat/+bug/1498079
20:05:23 <openstack> Launchpad bug 1498079 in heat "Heat stack creation fails with 501: HttpNotImplemented Error" [Critical,In progress] - Assigned to Angus Salkeld (asalkeld)
20:06:07 <pas-ha> also I would vote this goes in rc2 too https://review.openstack.org/#/c/226504/
20:06:18 <zaneb> people can't stop using nova-network too soon
20:06:25 <pas-ha> (volume error status on delete afterfix)
20:06:32 <skraynev_> zaneb: your message and article mentioned in it inspired me :)
20:06:48 <stevebaker> so this is a good chance to fix any other bugs that should get to liberty
20:06:51 <stevebaker> #link https://bugs.launchpad.net/heat/+bugs?field.tag=liberty-rc-potential
20:07:20 <zaneb> skraynev_: actually I just cunningly timed it so I could take credit for what I knew was going to happen anyway ;)
20:07:23 <stevebaker> especially gate failures, since this will make getting backports in a real pain
20:07:47 <stevebaker> zaneb: could you raise a dedicated bug for https://review.openstack.org/#/c/226504/ ?
20:08:14 <zaneb> stevebaker: I mean... I could
20:08:28 <pas-ha> just for housekeeping :)
20:08:29 <zaneb> can't we just post a backport and approve it?
20:08:38 <zaneb> it's really part of the same bug
20:08:58 <stevebaker> we should reopen that bug then
20:09:24 <skraynev_> zaneb: good move :)
20:10:14 <zaneb> stevebaker: I don't mind, just seems like it would be easier to find later if it's all one bug
20:10:41 <stevebaker> zaneb: too late, I've reopened, and approved the change with Closes-Bug
20:11:16 <zaneb> ++
20:11:30 <stevebaker> while we're on this topic, there are only a couple of test failures on the convergence test, it would be great if we could get fixes for those into rc2
20:11:43 <stevebaker> https://bugs.launchpad.net/heat/+bug/1498660
20:11:44 <openstack> Launchpad bug 1498660 in heat "Convergence: test_stack_update_replace_with_ip_rollback failure" [High,Triaged] - Assigned to Rakesh H S (rh-s)
20:11:59 <stevebaker> https://bugs.launchpad.net/heat/+bug/1486281
20:12:01 <openstack> Launchpad bug 1486281 in heat "convergence functional tests sometimes timeout" [High,In progress] - Assigned to Rakesh H S (rh-s)
20:13:47 <stevebaker> skraynev_: some thought may need to be given to restore_after_rollback on convergence for https://bugs.launchpad.net/heat/+bug/1498660
20:13:48 <openstack> Launchpad bug 1498660 in heat "Convergence: test_stack_update_replace_with_ip_rollback failure" [High,Triaged] - Assigned to Rakesh H S (rh-s)
20:14:27 * skraynev_ is surprised..
20:14:44 <skraynev_> stevebaker: will take a look tomorrow
20:15:09 <stevebaker> ok, Rakesh may come up with something too
20:15:27 <skraynev_> sure, I don't mind
20:15:27 <stevebaker> #topic state of the gate
20:15:33 <stevebaker> ... is pants
20:15:38 <skraynev_> I will discuss it with him
20:16:12 <stevebaker> #link https://bugs.launchpad.net/heat/+bugs?field.tag=gate-failure
20:16:16 <shardy> stevebaker: what's broken now?  I thought things were merging pretty quickly pre-rc1
20:16:52 <shardy> Or at least, there were a few hours where things were going fairly smoothly ;)
20:16:57 <stevebaker> shardy: https://bugs.launchpad.net/heat/+bug/1496555 is happening a lot, I'll take a look at that today
20:16:58 <openstack> Launchpad bug 1496555 in heat "Software Deployment metadata timeout" [High,Triaged]
20:17:29 <shardy> stevebaker: Aha, that's actually possibly a good thing, as I believe it's manifesting via TripleO CI failures too
20:17:40 <shardy> at least we have a heat specific reproducer now
20:18:10 <stevebaker> shardy: hmm, I sure hope not. my theory is that it is a test race rather than a real bug, but I could be wrong
20:20:09 <stevebaker> there is this one too https://bugs.launchpad.net/heat/+bug/1497157
20:20:10 <openstack> Launchpad bug 1497157 in heat "heat_integrationtests.functional.test_resource_group.ResourceGroupTest.test_props_update fails " [Medium,Triaged]
20:20:15 <stevebaker> which is unassigned currently
20:20:34 <pas-ha> stevebaker, try to rename test/module, that should change the test balance between workers
20:20:52 <pas-ha> see if it helps
20:21:19 <stevebaker> pas-ha: I don't even vaguely understand what you're talking about :)
20:21:30 <shardy> stevebaker: ramishra has been investigating a similar/same issue I believe
20:22:25 <shardy> stevebaker: if nobody else takes it I'll chat to him tomorrow and see if he might pick it up
20:22:26 <pas-ha> if it is a race, it happens due some other particular test being run in parallel. you should try to make it spread test differently between workers, might help
20:22:56 <stevebaker> hmm, that sounds like a real bug then
20:23:36 <pas-ha> or at least prove it is a race
20:23:42 <stevebaker> yeah
20:23:44 <stevebaker> #topic Liberty release notes
20:24:04 <stevebaker> I made a start https://etherpad.openstack.org/p/heat-liberty-release-notes
20:24:06 <stevebaker> #link https://etherpad.openstack.org/p/heat-liberty-release-notes
20:24:45 <stevebaker> we need a short paragraph for the state of convergence, I'll write one if nobody else does.
20:25:12 <stevebaker> any links to blueprints will become a single line summary of the change
20:26:00 <stevebaker> 30 new resources, thats epic (sure, many were in contrib)
20:26:01 <pas-ha> there's one thing wrong there - I've only marked nova flavor as admin-only resource for now https://github.com/openstack/heat/blob/master/etc/heat/policy.json
20:26:26 <pas-ha> line 79
20:26:39 <stevebaker> pas-ha: sure, but default openstack policy will make those other admin resources fail even if they're visible
20:26:51 <pas-ha> yes, that's true
20:27:02 <pas-ha> but idea was to fail early
20:27:40 <stevebaker> we should probably add policy for the OS::Keystone::* too then
20:28:01 <pas-ha> i mean the part "only visible to" is not yet corerct
20:28:24 <pas-ha> but we could quickly patch policy.json for that, will do tomorrow
20:28:44 <stevebaker> pas-ha: assuming they customise their policy, which they should. I wouldn't want to tie down the default policy too much
20:29:00 <shardy> I'm confused, are we proposing per-resource policy defined in heat?
20:29:14 <pas-ha> shardy, it is already there
20:29:32 <skraynev_> stevebaker: could you please add also note about batching for create/update for RG?
20:29:42 * zaneb can't wait to see the keystone devs reaction when they hear about this ;)
20:29:43 <pas-ha> hiding/denying create for admin-only resources
20:29:47 <stevebaker> pas-ha: actually, lets leave the flavor on there as the example, but just encourage operators to write their own appropriate policy
20:29:59 <skraynev_> looks like it was missed in etherpad
20:30:06 <pas-ha> ok, sounds reasonable
20:30:14 <shardy> pas-ha: where, I only see per API path ones in policy.json?
20:30:23 <stevebaker> skraynev_: like 26, it will become a bullet summary
20:30:40 <pas-ha> shardy, https://github.com/openstack/heat/blob/master/etc/heat/policy.json#L79
20:30:51 <shardy> IMO we really shouldn't be doing anything which enforces per resource policy, it's impossible to do correctly without a centralized policy service/repository
20:31:16 <stevebaker> shardy: yes, so lets document that it is up to the operators to write their policy
20:31:19 <skraynev_> stevebaker: I see. missed links on bps. was shocked by huge list of new resources :)
20:31:24 <zaneb> shardy: that's true, but we'll be waiting forever for keystone to come up with that
20:31:33 <skraynev_> stevebaker: thx ;)
20:31:47 <pas-ha> its not even keystone I believe, isn't it Congress?
20:31:58 <stevebaker> like 93, can you please comment on Upgrading from Kilo to Liberty?
20:32:00 <zaneb> pas-ha: No!
20:32:05 <stevebaker> do we need more?
20:32:32 <shardy> pas-ha: thanks, I missed that off the bottom of my screen ;)
20:33:38 <shardy> zaneb: I guess, it still seems wrong to me, but at least it can be documented and easily bypassed
20:35:14 <stevebaker> no comments on line 93-94?
20:35:21 <zaneb> shardy: it's not wrong so much as just a filthy, error-prone hack. basically what got us where we are today ;)
20:35:31 <zaneb> stevebaker: do we have rpc version pinning yet?
20:35:34 <shardy> zaneb: keystone v3 actually already has a policy interface, only nobody uses it
20:35:49 <skraynev_> stevebaker: no from my side
20:36:04 <zaneb> stevebaker: I thought we did not, in which case we should mention that as a reason to take the service down
20:36:23 <stevebaker> zaneb: I don't think so. however
20:36:24 <zaneb> stevebaker: unless we do, it which case we should mention how to pin it across an upgrade
20:37:51 <stevebaker> zaneb: as long as the first service instances to be upgraded includes engines wouldn't that allow any new RPC requests to be serviced?
20:38:18 <zaneb> stevebaker: engines talk to engines now (for nested stacks), so no
20:38:42 <stevebaker> zaneb: multiple engines then
20:38:45 <zaneb> or at least, not necessarily
20:39:20 <shardy> zaneb: how is that different to API->engine if both use the rpc client API?
20:39:36 <stevebaker> ok, I'll finish of the release notes and put them on the wiki. We can continue to edit if necessary
20:39:48 <zaneb> shardy: a new engine can send a message to an old engine even if you update all the engines before the apis
20:39:51 <stevebaker> #chair skraynev_ zaneb
20:39:51 <skraynev_> stevebaker: +1
20:39:52 <openstack> Current chairs: skraynev_ stevebaker zaneb
20:40:00 <shardy> zaneb: aha, thx
20:40:09 <stevebaker> I need to do the school run
20:40:17 <stevebaker> #topic Summit session topics
20:40:21 <skraynev_> stevebaker: ok.
20:40:26 <stevebaker> skraynev_: its over to you :)
20:40:34 <skraynev_> yeah. it's mine
20:40:36 <zaneb> skraynev_: this is your topic anyway :)
20:40:43 <skraynev_> I have prepared this etherpad:
20:40:52 <skraynev_> https://etherpad.openstack.org/p/mitaka-heat-sessions
20:41:07 <zaneb> #link https://etherpad.openstack.org/p/mitaka-heat-sessions
20:41:23 <skraynev_> so welcome with ideas and comments about several already existing topics
20:42:22 <skraynev_> I just added the most important topics with description, as I see it.
20:42:27 <jdob> there's going to be at least one proposed about the resource capabilities stuff. i'll work with shardy about getting it written up
20:42:41 <shardy> skraynev_: I'd like to propose a session on composition enhancements (the capabilities spec which is currently blocked)
20:42:50 <jdob> right, that one :)
20:42:57 <shardy> jdob: haha ;)
20:43:16 <shardy> skraynev_: I'll add it to the etherpad for consideration
20:43:23 <skraynev_> shardy: sure. Could you add to etherpad ?
20:43:27 <skraynev_> yeah :)
20:43:48 <pas-ha> shardy, jdob is that on checking/formalizing resource interfaces?
20:44:10 <jdob> ya, and also the introspection-y APIs to ask questions about them
20:44:17 <pas-ha> ok
20:45:11 <jdob> https://review.openstack.org/#/c/196656/  <-- that one
20:45:26 <shardy> pas-ha: https://review.openstack.org/#/c/196656/
20:45:43 <shardy> pas-ha: it's about making advanced composition via the resource_registry easier
20:45:56 <pas-ha> yeah, remember it
20:46:03 <shardy> I thought we were close to consensus in the spec review, then zaneb disagreed ;)
20:46:13 <shardy> So it'd be good to try to get a common understanding
20:46:29 <shardy> I may hack on some PoC code beforehand if I have time
20:46:42 <zaneb> my objections were somewhat lessened by face to face discussion
20:46:59 <zaneb> but I do think a workroom session on this would be great
20:47:00 <jdob> note to self: physical intimidation works with zaneb
20:47:07 <shardy> lol
20:47:51 <shardy> zaneb: that's good to hear, but it'd be good to get folks agreement so we can get on with implementing it/something
20:48:08 <shardy> zaneb: you're welcome to remove your -1 if you now don't mind the idea ;)
20:48:13 <skraynev_> zaneb: anyway we have a lot of slots... and small list of sessions :)
20:48:43 <zaneb> shardy: that would require me to read it again and try to remember what I think ;)
20:48:50 <skraynev_> so currently it's possible to nominate for session, I suppose ;)
20:48:59 <pas-ha> we could try inviting Murano people to that session as well
20:49:48 <shardy> pas-ha: Yup, that would be good, I was looking for feedback on how this fits with the murano composition concepts
20:49:58 <zaneb> pas-ha: so one of the things that reduced my objection was finding out that Murano doesn't attempt to do anything similar
20:50:03 <zaneb> unlike what I had assumed
20:50:04 <shardy> AFAICT they are complimentary, in that murano composition is much higher level
20:50:35 <shardy> e.g wiring instances together doing different things, vs composing multiple fragments to build one instance
20:51:55 <skraynev_> zaneb, shardy: anything else about current topic ?
20:52:17 <zaneb> not from me
20:52:24 <skraynev_> or may  move  to the last one ? ;)
20:52:48 <skraynev_> #topic How we deal with new API versions
20:53:23 <skraynev_> I have added this one after reading mail thread related with lbaas v2 API resources
20:53:34 <stevebaker> (back)
20:53:39 <skraynev_> #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg63942.html
20:54:21 <shardy> skraynev_: I'd always assumed we'd aim to support the latest stable API for any services, in the corresponding Heat release
20:54:21 <pas-ha> afaik for now we've only had a cinder vs cinder v2
20:54:26 <skraynev_> last idea was to use another name space for lbaas v2 resources, like OS::lbaas
20:54:41 <shardy> I know we've sometimes failed at that and had an older version in some cases
20:54:55 <kfox1111> ideally, the newest api for a service will be a superset of the previous versions, and so the resource doesn't have to change and is transparent to the user.
20:55:07 <pas-ha> and cinder v1 is to be removed in M
20:55:09 <zaneb> shardy: that's easy when there are no backward compatibility issues
20:55:18 <kfox1111> the odd thing about lbaasv2 is that it is basically a completely different service then lbaasv1.
20:55:19 <stevebaker> what is neutron's migration story? will existing state from v1 be moved to v2 during cloud upgrade?
20:55:29 <zaneb> but generally new api versions exist because... there are
20:55:38 <shardy> kfox1111: invariably for the rest API's thats never the case, because folks only bump major versions when they want to make major/breaking changes
20:55:56 <skraynev_> shardy: agree with zaneb
20:55:58 <kfox1111> see cinder or glance api changes. listing images works through both api's.
20:56:05 <pas-ha> shardy, just like we are doing
20:56:05 <kfox1111> but lbaasv1 vs v2 wont.
20:56:15 <zaneb> I think shardy and I are saying the same thing
20:56:28 <skraynev_> if we support only last one and don't have real huge differences it's not difficult
20:56:44 <skraynev_> but looks like we can do the same for lbaas
20:56:47 <kfox1111> for services where v1 -> v2 keeps all your stuff, yeah.
20:57:09 <shardy> kfox1111: This sounds like another example of a uniquely broken neutron API which we'll have to somehow paper over then :(
20:57:12 <kfox1111> but if v1 and v2 are seperate services, there's a migration period where users may need to support v1 and v2 at the same time while migration happens.
20:57:19 <kfox1111> shardy: yeah. :(
20:57:32 <zaneb> shardy: surely not :P
20:57:39 <kfox1111> I think they assumed wrongly that v1 was never used and they started fresh. :/
20:57:40 <shardy> kfox1111: I agree that the basic functionality should be maintained, even if the interfaces aren't identical
20:57:51 * shardy sighs
20:58:18 <kfox1111> so since they are completely seperate, the cleanest thing would be to have a completely different set of resources. :/
20:58:21 <shardy> LbaasV2 resource and deprecate the old one then?
20:58:24 <pas-ha> I am basically in favor of ::LBaaS:: naming
20:58:31 <kfox1111> yeah.
20:58:47 <shardy> it's dumb that we have to even consider that tho :(
20:58:50 <skraynev_> shardy: no. please without suffix V* :)
20:58:51 <kfox1111> The other possibilty is that the resource names are different enough that the resources could figure out if it was a v1 or v2 api.
20:58:56 <stevebaker> it would be good to get some lbaas folk in the room for that session
20:59:01 <kfox1111> I think v1 calls lb's pools, and v2 calls them lb's.
20:59:26 <zaneb> kfox1111: well +1 for sanity there anyway
20:59:29 <skraynev_> 1 minute
20:59:31 <stevebaker> kfox1111: we can always add properties which explicitly state what version to use
20:59:40 <pas-ha> AFAIR there is now a real LB resource (our current Neutron one is an artificial Heat-only thing)
20:59:41 <shardy> skraynev_: heh, I just mean, if they actually do a different thing, we'll have to name them differently
21:00:00 <zaneb> will the v2 API support the pattern where we have a resource for the LB member that we put inside the scaled template of a scaling group?
21:00:01 <kfox1111> a couple of things like poolmembers I think are the same, but heat could use the suplied lbid and ask neutron which version it belongs to, and then use the right api. but thats more work. but easier on the user.
21:00:05 <kfox1111> I'm good either way.
21:00:25 <skraynev_> shardy: oops. got it. but please do not use version in names still ;)
21:00:30 <skraynev_> out of time
21:00:31 <kfox1111> zaneb: I sure hope so. Its very broken otherwise. :/
21:00:33 <shardy> times up!
21:00:40 <skraynev_> let's continue in #heat
21:00:49 <skraynev_> #endmeeting