13:00:57 #startmeeting heat 13:00:58 Meeting started Wed Oct 11 13:00:57 2017 UTC and is due to finish in 60 minutes. The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:02 The meeting name has been set to 'heat' 13:01:06 #topic roll call 13:01:25 yes. I'm not even sure you can just change lb_server.yaml with lb_group.yaml 13:01:54 hi 13:01:58 lb_group seems autonomous stuff 13:02:02 o/ 13:02:23 maestropandy: see you after the meeting 13:02:24 ioggstream: we're in a meeting, can we keep the discussion for later? 13:02:34 ramishra: sure 13:03:00 I would like to join meeting how ,, please say 13:03:23 maestropandy, just join~ 13:03:25 :) 13:03:27 #topic adding items to agenda 13:03:32 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-10-11_1300_UTC.29 13:04:29 ramishra, also our gate should get fixed any mins from now. Waiting for ceilometer's patch to land 13:04:32 #link https://review.openstack.org/#/c/510919 13:05:42 #topic neutron lbaas service issue http://paste.openstack.org/show/623346/ 13:05:44 ricolin: yeah, but there are some other issues too, not sure it would fix all issues 13:05:51 http://logs.openstack.org/39/511139/1/check/gate-heat-python27-ubuntu-xenial/d916edc/console.html#_2017-10-11_05_25_37_813322 13:05:51 sorry,i'm late 13:05:53 o/ 13:05:58 maestropandy, there you go:) 13:06:05 kiennt26, o/ 13:07:42 Hi.. ricolin.. thanks for :) .. My question is being newbie.. I am started autosclaling .. in devstack/ocata.. where no issue with creating stack and seperately load balancer.. but when am going for autoscaling .. need to merge.. so i taken autoscaling.yaml and lb_server.yaml from master bracnh of heat templates.. and faced error.. 13:08:06 maestropandy, That's not a good topic for the meeting 13:10:02 therve: I am newbie.. understand.. my questions are how to utilise lbaasv2 with heat autoscaling && how far better to use gnocchi as data store && how far senlin autoscaling is far better than heat - autoscaling 13:11:41 maestropandy, Anyway, for short, I think the issue should be in your neutron services, you can check for neutron lbaas client and see if that's working 13:12:05 maestropandy, maybe we can discuss those question right after meeting's over:) 13:12:24 ricolin: will discuss after meeting.. lbaas client is working fine 13:12:39 maestropandy: that template is using lbaasv1 resources, you need to change it to use lbaasv2 resources, just changing lb_server.yaml with lb_group.yaml would not help. it's incorrect. 13:12:59 we probably have to update those templates 13:13:29 ramishra, we need to update this one https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml#L172 13:13:40 yes 13:14:24 ramishra: not like that blindly did file mapping.. also changed "OS::Neutron" along with Lbaaas to utilise LBaasv2.. also.. i hope in that way it works.. need to update both server.yaml && autoscaling.yaml with lbaasv2 13:15:39 let's move on and discuss this later 13:15:52 #topic tempest id 13:16:25 so we need to have a way to add tempest ids for our gabbit api tests 13:16:43 ramishra, any suggestion on how we do it? 13:17:42 ricolin: I don't know, may be this feature has to be added to gabbi. good to check with cdent 13:18:43 We've to move tempest tests to separate repo, probably we should for that to finish? 13:18:45 The other test will be cover by this patch (https://review.openstack.org/#/c/506525/) which we can redo it after your tempest repo separate 13:19:34 ramishra, +1 migrate repo first 13:21:27 Anyway, will ask cdent for advise as well 13:22:05 we need to let refstack team know before 12/25, if we can make this done or not 13:22:49 on a related topic I was wondering whether we should make the heat-tempest-plugin branchless like other plugins, making it branchless would bring number of problems 13:23:02 ricolin: I'll check too 13:23:48 we would need some way to skip new tests on old branches, may be a feature flag for every feature 13:24:43 maybe we can add tags like we recently added for convergence tests 13:25:29 #link https://review.openstack.org/#/c/509863/ 13:26:21 not sure making it branchless would give us any benifits though, as we've all kinds of tests and not only api tests, we don't have api versiong too 13:26:25 maybe not a config, but something checking branch within wrapper func 13:27:28 ricolin: my question is whether to make it branchless or not and not 'how';) We can work that out later:) 13:28:07 therve: do you've any opinion on that? 13:28:22 ramishra, yeah, we just separate it out, and see when we can make it branchless 13:29:01 ramishra, I thought making it branchless was the whole point 13:30:00 therve: Is it? I thought installing a plugin with the service is an issue, which we wanted to get rid of 13:30:39 I see number of issues with branchless tempest 13:31:02 if something is broken in master, all branches are broken too 13:31:17 I mean branches of services using tempest 13:32:13 Yeah. We better not break it then. 13:33:52 although all tempest plugins existing in separate repo are branchless, not sure if that's a requirement;) 13:34:17 Is there any known issue from other tempest plugin repo for other services? 13:34:20 o/ 13:34:38 zaneb, yo! 13:35:44 ricolin: I don't know, but I see number of issues with branchless tempest on a regular basis 13:37:20 ramishra, we should definitely find a place to record those issues down and resolve all of it before we migrate our test to a branchless mode 13:38:10 s/all of it/many of those as we can/ 13:40:08 ricolin: you mean track tempest isues? I assume we've to probably decide now about our plugin and make it work with the stable branches, if we want it branchless 13:40:48 probably I'll start a ML thread to discuss about it. So let's move on 13:42:14 ramishra, IMO, do hope it to be branchless in long term if no blocking issue there 13:43:59 Anyway, we can separate repo first and see if there's any major issue pop out from ML before we move our tests to use new repo 13:44:05 #topic Open discussion 13:44:55 https://review.openstack.org/#/c/510919 landed 13:45:08 so we only got package issue left 13:45:26 we've got no feedback on cloudwatch removal, should we wait more or just do it?;) 13:45:50 just do it+1 13:45:58 zaneb, therve ? 13:47:10 is there _any_ alternative for the metric proxying thing? 13:48:01 zaneb: not that I know 13:48:26 that makes me a little nervous 13:49:34 no one has come back with any concern though 13:52:16 though there can be users who don't care reading mails') 13:54:04 How about we wait a little more, and see if there's user care about it. Don't see any way we can decide this right away with those concerns pop:) 13:54:53 I can't imagine someone using that 13:55:45 ricolin: we can wait as long as we want or leave it there for ever:) 13:55:50 maybe keep refresh that ML until queens-3? 13:56:29 therve: we have had a few people asking about how to put custom metrics into ceilometer over the years. I don't know how they do the auth though 13:57:55 Do we know if it even works? 13:58:17 I wouldn't be surprised it doesn't anymore 13:58:30 fair point 13:58:43 talk about something that might doesn't work 13:58:54 I would like to propose to hidden OS::Heat::HARestarter 14:00:58 +1 14:01:33 time run out, any thing else? 14:02:20 ricolin: I'd like to go even further and replace it with OS::Heat::None and delete all the code in Stack that is there to support it. but maybe not until R 14:02:43 the gate is broke, but we can discuss that after 14:02:44 therve: I assume it works, but we can check it 14:04:36 zaneb, maybe propose to hidden in Q first:) 14:04:45 Also policy in code patches now works just fine (once we fix the gate) https://review.openstack.org/#/c/502386/ 14:04:57 ricolin: +1 14:05:03 Anyway we should end meeting now:) 14:05:23 The best part is, we all still here:) 14:05:25 #endmeeting