14:00:17 #startmeeting heat 14:00:18 Meeting started Wed Jun 6 14:00:17 2018 UTC and is due to finish in 60 minutes. The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:22 The meeting name has been set to 'heat' 14:00:25 #topic roll call 14:00:50 o/ 14:00:55 o/ 14:00:57 o/ 14:01:22 kazsh_, sorry didn't review your patch yet, but will do it right after meeting! 14:01:40 ricolin: no worries, mate & thanks! 14:02:00 ramishra, therve ? 14:02:09 hi 14:03:03 #topic adding items to agenda 14:03:08 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282018-06-06_1400_UTC.29 14:04:22 #topic Vancouver Summit 14:04:28 #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131221.html 14:05:09 I send a ML for video and slide link from summit sessions 14:05:23 also the user feedback etherpad 14:05:54 We seems got a lot of require by users 14:06:22 at least every user I ask are using heat in some interesting way:) 14:07:38 ramishra, there was user asking about swift backend for heat template:) 14:08:27 Also some requirement for multi cloud and improve our ASG 14:08:37 anyway that's what I got from Summit 14:08:56 #topic Review policy for Heat cores 14:09:39 zaneb proposed to change our review policy with allow a core to directly approve patch when it's proposed by another core. 14:10:14 Any idea on that? 14:11:15 with only 4 active cores, who are also doing most of the development, 75% of us have to be involved to get a patch in at the moment 14:11:56 that seems like too high a bar to get anything done 14:12:21 I'd say, on all patches then 14:13:46 ramishra, what you think 14:14:02 +1, unless the patch is too complex 14:14:28 +1 from me too 14:14:45 I mean more eyes is always good, but we've limitations:) 14:15:02 ramishra: yeah, it's never compulsory to approve a patch after you've +2d (even if there is already a +2). you can always wait for more feedback if you think it's warranted 14:15:29 zaneb: yep 14:15:56 therve: by 'all patches' do you mean including patches from non-cores? 14:16:05 zaneb: Yeah 14:17:34 therve: that feels like a bigger step. this is just saying 'we assume you reviewed your own patch before submitting it/clearing Workflow-1" 14:17:56 I mean if the core feels like approving with only him/her reviewing, it should be fine, no? 14:18:09 let's try this out first rather than jump straight to 'only 1 +2 required to merge' 14:18:22 ok 14:18:51 unless it's trivial of course. we already approve trivial patches with a single +2 (at least I do) 14:19:37 I think trivial patch not limited:) 14:19:45 Wonder if we can also apply this new policy to our stable branch review? 14:20:39 I think we should approve stable patches with only one stable core revewing as an agreed policy from now on 14:21:16 ramishra, yeah 14:21:29 unless stable maint team makes noise about it;) 14:21:42 I remember stable-maintain-cores once mention they willing to direct provide +2 if any of our stable core +2ed, which sounds like what allow directly a single core policy:) 14:21:45 ramishra: and by 'we' you mean me, right? ;) 14:21:53 zaneb, yes! 14:21:59 zaneb: exactly:) 14:22:07 zaneb, that obvious? 14:22:31 I'm happy to do that (and often end up doing that anyway) 14:22:43 there's still a problem for stable backports that I submit 14:22:52 somebody needs to review those 14:23:20 Yeah just stop doing that :) 14:23:43 so I would appreciate it if y'all could do +1s on stable reviews so that I can nominate more people for stable core 14:23:57 therve: stop doing backports myself? 14:24:04 Yeah 14:24:26 zaneb, will try to keep that in mind 14:24:35 therve: if you're volunteering, I'm fine with that ;) 14:25:47 since all agree, I assume we can close this topic now 14:26:07 zaneb: yeah we can manage that, it's not that difficult to handle with gerrit UI support for backports unless there are conflicts 14:26:12 ricolin: should we put some #agreed things in the minutes? 14:26:26 zaneb, right 14:27:17 #agreed team aggree to allow core reviewer to directly approved on patches what was proposed by another core 14:28:20 #agreed in stable branch, single stable core can directly approve patches 14:28:33 therve, ramishra zaneb sounds right? ^^^ 14:28:45 yep 14:29:10 BTW zaneb queens gate is broken and need this backport https://review.openstack.org/#/c/562455 14:29:10 :) 14:29:29 two patches actually:) 14:29:32 I just +2d them earlier, but I guess I can approve now :) 14:29:49 I suspect those patches will need to be squashed together to pass the gate now though 14:30:00 zaneb, cheers for the sudo power:) 14:30:16 Move on 14:30:17 apparently I am not allowed to do that myself, so... 14:30:30 haha 14:30:42 #topic Credential in Multi-Cloud 14:31:59 As we plan to work on multi-cloud in this release, would like to collect idea on what we should deal with credential. I working on using clouds.yaml to record provider information for other clouds https://docs.openstack.org/os-client-config/latest/user/configuration.html . 14:32:00 Ops input cloud provider name and barbican id(from remote side). 14:32:00 Pregenerate clouds.yaml file with cloud auth info. Use that auth to talk to another cloud (in future it can be a application credential with only limited to access to heat stack operations). 14:32:00 Remote Heat receive API to create Stack, and use that stored barbican credential to refresh context with actual user credential 14:33:13 Try to working on spec and POC right now, would like to learn if that sound like the right track or not 14:33:47 zaneb, ideas? 14:34:35 s/actual user credential/token/ 14:34:50 but yes, that sounds correct 14:36:05 cool 14:36:18 ideally we should support any sort of credential (password, application credential, &c.) that a user can use with the SDK and clouds.yaml/secrets.yaml 14:36:49 we use that to grab a token from the remote cloud's auth_url, and we go from there 14:38:28 when you mean by grab a token, you mean as a heat service to greb a token to access to another heat service right? 14:38:51 zaneb, try to figure out if I can do better in protect any credential 14:39:31 that's what we're getting a token for, yes. at the time we're getting the token, we just get it from keystone, it doesn't know what we're going to use it for 14:41:05 zaneb, yeah, and once Application credential allow only access to single API, we can try to use that instead acquire a token with full power 14:41:41 ricolin: we don't have to do anything. the *user* can give us a locked down credential 14:43:14 fair enough, just have to make sure os client config allow taht credential, everything should be the same 14:43:56 as long as we allow app creds in general, then we can't tell the difference 14:44:35 zaneb, true 14:45:08 will try to working on more detail and keep you all sync! 14:45:14 Harald Jensås proposed openstack/heat master: Allow updating the segment property of OS::Neutron::Subnet https://review.openstack.org/567206 14:46:10 okay, let's move on 14:46:15 didn't put this is agenda, but I think maybe we can talk about long term support? 14:46:50 I mean Extended Maintenance 14:47:33 #topic Open discussion 14:47:53 Do we have anything to discuss about that? 14:47:55 I can give an update about Extended Maintenance if you want? 14:48:02 zaneb, sure 14:48:10 basically this is the new policy: https://docs.openstack.org/project-team-guide/stable-branches.html 14:48:35 so stable branches are open for all bugfixes for 18 months 14:49:01 they remain open after that as long as someone is maintaining them 14:49:10 (gate is not broken, patches still get reviewed) 14:49:40 if they've been unmaintained for 6 months we'll call them EOL 14:49:58 but iirc we're no longer going to delete the branch and replace it with a -eol tag 14:50:20 oh, also no releases after the first 18 months 14:51:01 so downstreams can co-operate on backporting patches, but they'll have to grab them from git not a tarball 14:51:02 zaneb, yeah, old branch will all keep in repo now 14:51:23 (from my perspective, this is what we do in RDO anyway so that wfm) 14:51:35 any questions? 14:51:46 * ricolin raise hand! 14:52:02 oh no 14:52:22 is this actually working well? I mean you mention RDO doing it 14:52:50 importing patches from git? 14:53:11 yes 14:53:18 for old version 14:53:42 I mean version > 2years 14:53:52 we have lots of tooling to make it easy, so yeah. for us it works well. we just rebase on the latest git master instead of the tarball 14:54:22 tbh ocata is the first branch that is following this, so we don't have any data on that yet 14:54:49 Is releasing such an overhead? there could have been independent releases if the project teams wants 14:54:58 but the old way was after the branch was closed, we had to do backports downstream, and so did all the other distros 14:55:20 I assume you guys will have to do it for Pike eventually 14:55:55 so the new way is better because everyone can continue to collaborate on backports even after 18 months 14:56:38 ramishra: I don't think it's about overhead so much as not creating expectations that a series is still supported by upstream, including VMT &c. 14:56:44 zaneb, we only allow security backport for Old branch, so did that also apply to extended? 14:57:01 extended maintenance is a sandbox for distros to share work 14:57:13 zaneb: OK, makes sense 14:57:34 ricolin: no: "All bugfixes (that meet the criteria described below) are appropriate. No Releases produced, reduced CI commitment." 14:58:18 right! that rule is changed even for all maintained branch 14:58:59 correct, it's changed for the entire lifetime of the branch 14:59:39 let's wait for our first requirement come:) 15:00:04 actually that doc says at EOL we still delete the branch and tag, so I may have misremembered that bit, or it may just not have been updated since the Forum 15:00:42 on another topic 15:00:51 I think only if branch stay in Unmaintained for so long 15:01:16 ricolin: yes. that will eventually happen to all branches though 15:01:25 I posted this yesterday: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131183.html 15:01:54 ricolin: we discussed this ^ in the hallways at summit 15:02:02 zaneb, oh! that cool stuff! 15:02:07 looking for volunteers 15:02:15 * zaneb stares at therve 15:02:22 Hi 15:03:01 that is all. 15:03:40 Let's keep that part up to dated! 15:04:27 we're running out of time 15:04:47 Thanks all for join 15:04:53 #endmeeting