15:00:17 <ricolin> #startmeeting heat
15:00:18 <openstack> Meeting started Wed Apr 26 15:00:17 2017 UTC and is due to finish in 60 minutes.  The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'heat'
15:00:25 <ricolin> #topic roll call
15:00:53 <zaneb> o/
15:00:55 <therve> Hi
15:01:03 <cwolferh> hello
15:01:03 <ramishra> hi
15:01:42 <ricolin> hi guys:)
15:02:02 <ricolin> #topic adding items to agenda
15:02:08 <ricolin> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-04-26_1500_UTC.29
15:02:29 <ricolin> pilgrimstack1 around for floating ip?
15:04:01 <ricolin> #topic Announce
15:04:24 <ricolin> So we have release newton and ocata
15:04:34 <ricolin> and the very last version of Mitaka
15:05:17 <ramishra> ricolin, Is mitaka eol tagged yet?
15:05:25 <ricolin> not yet
15:05:33 <ricolin> but I think it's soon
15:05:37 <ramishra> ok
15:05:55 <ricolin> If more patch land in we can try to hurry another version
15:06:19 <zaneb> iirc there weren't many left for mitaka
15:06:48 <zaneb> #link https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/mitaka
15:07:13 <zaneb> those all have -1s
15:07:28 <ricolin> zaneb yeah, and most of it get conflict advice from stable maint core
15:07:43 <ramishra> We should abandon those then and be ready for eol tagging
15:07:51 <zaneb> +1
15:08:10 <ricolin> Okey I can do that
15:08:57 <ricolin> also there is one high bug this week
15:09:16 <ricolin> which therve just send patch for it
15:11:04 <ricolin> which cause by translate patch I reviewed;/
15:11:34 <ricolin> that's all I have for announcement
15:12:17 <ricolin> #topic Glare integrate
15:12:26 <zaneb> if that's the worst bug we get from the translation changes we are in good shape
15:13:14 <ricolin> zaneb try to review the entire and hope it's the worst
15:13:46 <ricolin> So Glare!
15:14:11 <ricolin> the spec work seems stuck
15:14:12 <ramishra> there can be more though, Not sure if StackValidationFailed messages were like that before https://bugs.launchpad.net/heat/+bug/1686360
15:14:13 <openstack> Launchpad bug 1686360 in heat "unclear validation error mesage for nested stacks" [Medium,New] - Assigned to Rabi Mishra (rabi)
15:14:27 <ramishra> seems to be another one from that patch series
15:15:19 <zaneb> ramishra: I wouldn't be surprised if they were always that bad
15:16:05 <ramishra> zaneb: yeah may be
15:16:29 <zaneb> is glare still alive?
15:16:35 <ricolin> ramishra good timing to fix it:)
15:16:54 <ricolin> zaneb interesting question!
15:17:18 <ricolin> anyone interesting in finding it out?:)
15:18:11 <ramishra> Is there a need for us doing anything with it?
15:18:25 <ricolin> template?
15:18:27 <zaneb> 17 reviews so far in Pike http://stackalytics.com/?module=glare&metric=marks
15:18:56 <ramishra> oh, we had that bp, ok
15:19:13 <ricolin> #link https://review.openstack.org/#/c/315439/
15:19:23 <ricolin> ramishra yep, this one
15:19:40 <therve> ricolin, You put the glare topic?
15:19:51 <ricolin> yes
15:20:04 <therve> Sounds like you want to work on it
15:20:10 <ramishra> lol
15:20:20 <ricolin> My question to the team is, do we still need it done
15:20:40 <therve> I mean, if it existed, it'd be a nice to have
15:20:51 <therve> I don't think it exists, so the point is moot
15:21:40 <zaneb> if someone wants to work on it, I think it's a Good Thing
15:21:49 <ricolin> therve you mean exists in glare or heat:)
15:22:03 <zaneb> but if nobody wants to work on it, that's probably because not many people are working on glare at all
15:22:15 <therve> ricolin, I mean if glare exists
15:22:21 <ricolin> lol
15:22:49 <ricolin> therve zaneb point taken...
15:23:17 <ricolin> move on:)
15:23:25 <ricolin> #topic gerrit review dashboard
15:23:46 <ricolin> #link https://review.openstack.org/#/c/459685/
15:24:19 <ricolin> this just a small tool for help on making URI for reviewing heat
15:24:48 <ricolin> the output of the URI will looks like this
15:24:48 <ricolin> #link goo.gl/LvYg8X
15:26:04 <ricolin> I think It might be great if those patches can get more attention on:)
15:27:06 <ricolin> so feel free to add the link to your review menu :)
15:27:42 <ricolin> #topic Open discussion
15:28:10 <ricolin> #link https://review.openstack.org/#/c/454222/
15:28:31 <ricolin> the heat define test
15:28:33 <ramishra> I wanted to remove this from the config http://git.openstack.org/cgit/openstack/heat/tree/heat/common/config.py#n189
15:29:15 <ramishra> This does not work yet, users enable it(knowingly and unknowingly) and come with some weird errors.
15:30:09 <therve> At least improve the doc
15:30:16 <ramishra> Anyway, we discussed about adding a flag to stack-update command
15:30:17 <ricolin> you propose to deprecate and remove it?
15:31:02 <ramishra> remove it, it does not work and we anyway decided earlier to add a flag to 'stack update'
15:31:57 <ricolin> ramishra right, which I already done but forget to upload to gerrit
15:32:44 <ricolin> will do it tomorrow:)
15:33:00 <ramishra> ok, we agree on removing it then
15:33:10 <ricolin> +1
15:33:18 <ricolin> therve, zaneb?
15:33:31 <zaneb> deprecate, then remove
15:34:24 <ramishra> zaneb: it does not work, it's purely experimental all the time
15:34:43 <ramishra> we still have patches for it https://review.openstack.org/#/c/255287/
15:34:50 <zaneb> right, but we can't break people's configs without warning
15:34:58 <therve> zaneb, I don't think it breaks anything
15:35:09 <therve> You can put whatever, we ignore unknown options
15:35:11 <ramishra> yeah, it would not break anything
15:35:24 <zaneb> do we?
15:35:26 <zaneb> ok then
15:35:35 <therve> Well "we" as oslo.config
15:35:51 <zaneb> I thought just removing options was a big no-no for upgrades
15:36:17 <therve> Yeah I thought so too
15:36:39 <therve> Maybe worth asking around
15:37:00 <ricolin> on mailing list?:)
15:37:18 <zaneb> oh great, the project navigator is busted
15:37:20 <therve> Wherever really
15:37:46 <ramishra> Anyway, I will check with oslo guys
15:38:11 <zaneb> https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html#requirements
15:39:25 <ramishra> it would not change the software behaviour
15:40:08 <ricolin> so `if` we have to deprecated before remove, how short we can make the process?
15:40:28 <therve> Yeah it doesn't talk about not removing
15:40:32 <therve> Just forward compatible
15:40:44 <zaneb> ricolin: if we have to then deprecate in Pike, remove in Queens
15:40:46 <therve> It's kind of the opposite, you can't add a required config option
15:41:53 <zaneb> so if somebody can have "observe_on_update = False" in their config and that won't break when we remove it, just remove it
15:42:35 <ramishra> yep, it would not
15:42:48 <ricolin> IIRC it won't?
15:44:07 <ricolin> sounds like we have agreement on that:)
15:44:38 <ricolin> anything would like to discuss about?
15:45:15 <therve> About to make the amqp gate voting
15:45:28 <therve> I fixed the last slowness, so we should be good to go
15:46:24 <ramishra> therve: it still takes 10 odd mins more than the other jobs
15:46:39 <therve> ramishra, It shouldn't since yesterday night-ish
15:46:54 <ramishra> ok
15:47:36 <therve> It's possible I missed something, so let me know :)
15:48:15 <ricolin> still wait for http://status.openstack.org/openstack-health/ to show me something...
15:48:43 <ramishra> therve: I've not checked it in the last few days
15:48:51 <therve> ricolin, It won't show anything for that gate though
15:49:16 <ramishra> so should be ok, if you've fixed it
15:49:20 <therve> ramishra, Yeah the devstack change was recently merged
15:49:34 <ricolin> therve oh, don't know that. thx
15:49:49 <therve> ricolin, health only works on gate, not check jobs
15:49:52 <ramishra> btw, I wanted to talk about e other thing I wanted to talk about https://review.openstack.org/#/c/407328/
15:50:47 <ramishra> there is something called auto_allocate_topology in neutron
15:51:11 <ramishra> that creates a network/subnet/router, the whole set
15:51:18 <therve> What? I thought nova handled those options?
15:51:35 <ramishra> if you set networks=auto for server
15:52:03 <ramishra> therve: it handles in server create
15:52:29 <ramishra> but the issue I've is these resources would not be managed by heat
15:52:39 <ramishra> Is that ok for us?
15:53:00 <therve> ramishra, I don't get it, why do we need to call .get_auto_allocated_topology?
15:53:27 <ramishra> if someone changes to auto for a server from none during an update?
15:53:42 <ricolin> in a part that if we try to delete a stack, those extra resources won't block us right?
15:54:09 <therve> ramishra, So that means we are re-implementing the meaning of auto inside heat?
15:54:17 <therve> Instead of passing the flag to nova?
15:54:24 <ramishra> therve: yeah, to some extent
15:54:32 <therve> Giant -2 then from me
15:54:44 <zaneb> it feels like that's what we're doing if we allow updates of that property
15:54:56 <therve> Yeah let's just not allow update on that
15:55:15 <therve> We're going to have other issues otherwise anyway
15:55:17 <ramishra> Again, I don't know if nova would delete these neutron resources when you delete the server
15:55:32 <therve> Well then that's a nova bug
15:55:36 <zaneb> therve: having your server replaced because you wanted to add a network to it also sucks though :/
15:55:57 <ramishra> so those may be left behind after the stack is deleted
15:56:53 <therve> zaneb, Ah yeah I guess there is no way to not go into a FAILED state?
15:56:59 <therve> Like fail at validation or something
15:57:22 <therve> We need to do less network garbage in the nova resource, not more
15:57:28 <zaneb> ramishra: IIUC leaving the network + router behind is OK/expected. the port should get cleaned up by Nova
15:57:35 <therve> This is already a giant mess in needs of refactoring
15:57:38 <zaneb> it may not be so bad
15:57:55 <zaneb> therve: if a resource is FAILED it's just going to get replaced on the next update
15:58:10 <therve> Yeah that I know :)
15:58:29 <zaneb> therve: whoops, missed the 'not' in there
15:58:38 <therve> Ah right
15:58:51 <zaneb> there's an 'immutable
15:58:57 <zaneb> property thing
15:59:03 <zaneb> can never remember what that does
16:00:18 <ramishra> zaneb: why do you think leaving the resources behind which were created by the stack(read nova) would be OK?
16:00:52 <therve> ramishra, Because that happens when you do nova boot?
16:00:59 <therve> ricolin, eom!
16:01:24 <ricolin> going back to heat!:)
16:01:30 <zaneb> ramishra: so it sounds like the idea is that if you're using 'auto' in the tenant, then the first server will create a network, router, & subnets and everything will just use that
16:01:33 <ricolin> #endmeeting