08:01:23 #startmeeting heat 08:01:24 Meeting started Wed Jan 30 08:01:23 2019 UTC and is due to finish in 60 minutes. The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:01:27 The meeting name has been set to 'heat' 08:01:28 #topic roll call 08:02:04 howdy 08:02:15 o/ 08:02:23 Zane Bitter proposed openstack/heat master: Rename the client routines for sfc to more generic name https://review.openstack.org/625210 08:02:23 Zane Bitter proposed openstack/heat master: Heat support for Tap-as-a-Service resources https://review.openstack.org/589238 08:02:42 hi, I won't be around for long though 08:03:34 ramishra, got it, let's get start 08:03:47 #topic Do we have a way of tagging high-priority stories for the release? 08:04:35 zaneb, about this, how about using https://storyboard.openstack.org/#!/board/list 08:05:28 that works, but iirc there are two ways of creating boards 08:05:50 either adding stuff manually, or automatically using tags 08:06:11 zaneb, any idea which might be better fit? 08:06:30 TBH I think tags is easier 08:06:45 ricolin: there is a wiki page for it;) https://wiki.openstack.org/wiki/StoryBoard/Priority 08:06:48 So I remember I once create a board here 08:06:48 https://storyboard.openstack.org/#!/board/71 08:07:05 good ol' board 71 08:09:09 * ricolin try to figure out what is a working list 08:09:14 that wiki page illustrates some annoying idealogical biases on the part of the storyboard developers 08:09:31 "nobody does triage properly so we won't let 'em try" 08:11:23 so shall we keep using tag `high-priority` and use that board 71? 08:11:33 yeah, tbh I don't like it a bit. It force changes the way things used to work well 08:12:12 ricolin: no, I think we should have a board for each release 08:12:37 that can be done 08:12:41 like "Heat Stein release" and list the stuff targeted for Stein 08:12:59 maybe showing status in each lane like https://storyboard.openstack.org/#!/board/8 ? 08:14:13 yes, that sounds better 08:15:13 I guess instead say it's mid/hi/low, just list the things we need to do and see how we doing with it 08:16:01 s/instead say/instead of saying/ 08:16:03 https://docs.openstack.org/infra/storyboard/gui/theory.html, I think it suggest tracking stuff like trello boards (backlog, in-progess, complete etc) for releases 08:16:17 yeah, if it doesn't end up getting done then it wasn't High, and we bump it to the next release ;) 08:16:33 rather than based on priority 08:17:55 so let's quick brainstorm here, I think we all agree on give a release based Board/working list, so what state we should add in 08:19:04 a tag like heat-stein-target maybe? 08:21:04 how can we move around the state 08:21:28 zaneb, I think the tag is good 08:24:58 Infra team use task instead:) 08:25:22 disadvantage of a tag is that anyone can set it, but I don't think we need to care about that 08:26:21 zaneb, I think we can always go through the Story and see who added that tag, so it's fine IMO 08:26:30 yeah 08:27:27 So I need some more time to learn about how to move things around state(todo->inprogress) in a board 08:27:44 ricolin: gotta go, btw, heat-agents gate is broken. unit tests are broken with paunch I think, if someone has time to fix before I find time to check it. 08:27:44 So what state we need? 08:28:18 ramishra, I will go for that right after meeting and before I need to go too:) 08:28:29 ramishra, thx! 08:28:43 ricolin: I think you create each lane with a different query, so e.g. under review column is is has tag heat-stein-target and status==Review 08:29:27 zaneb, I think that's why infra team use task I assume 08:30:10 ricolin: maybe. that board is waaay old. infra-cloud was decommissioned some time back 08:31:16 zaneb, I will try to see if tag and task state can be query at the same time 08:32:12 you can if I'm reading https://docs.openstack.org/infra/storyboard/gui/theory.html#worklists-and-boards correctly 08:32:23 TBH, storyboard still slow 08:33:29 yup :/ 08:33:53 Is it because the server issue? or it's because the app it self? 08:34:04 so is bugzilla though 08:34:12 and launchpad wasn't great 08:34:47 I think they fixed some stuff on the server, and created some missing indexes 08:36:28 but at the end of the day, all single-page JS apps that retrieve all their data from an API are slow 08:36:34 *cough*Gerrit 08:36:46 appears we can set priority to a task, but I don't know how 08:37:19 lol 08:37:30 shall we move on? 08:37:43 yes we should 08:38:28 #action rico will go setup Board for Stein release 08:39:05 #topic This seems like it would be a good feature for Stein 08:39:15 #link https://storyboard.openstack.org/#!/story/2003579 08:40:54 this is my nomination for the first story to receive the tag for stein ;) 08:41:20 probably not much more to say about it since ramishra already left :D 08:41:21 I believe so:) 08:41:45 but I think this would be a useful achievement for the release, and it's an easy review 08:42:05 next topic :) 08:42:37 zaneb, I always think we should improve what we doing with rollback, so agree on that 08:43:01 #topic multi-cloud 08:43:49 So just back around that idea for where to put auth info for another cloud, and what's best for tempfile 08:45:11 so I know the concern about temp file 08:45:34 I mean it do leave file behind if we have error else where 08:46:04 it's worse than that, it leaks a file descriptor 08:46:37 yeah, so we must do some change 08:47:19 I can change it to regenerate file for each remote client request 08:47:37 but wondering if there's any better way we can targeting here 08:47:45 I think that's the way to go. writing a tempfile is relatively cheap 08:47:57 compared to the HTTP request, it's certainly cheap 08:48:39 it is 08:49:09 the only alternative i can really is is to regenerate both the tempfile *and* the context for each request. which is obviously worse 08:49:30 zaneb, NO! 08:50:25 * zaneb just thought of a nasty hack 08:50:31 I guess we have to wait for python 3.x to be the oldest before get rid of temp file 08:50:52 zaneb, what hack 08:51:19 we could override _action_recorder() to create the context in there and clean it up at the end 08:52:14 yes 08:52:17 nasty 08:52:27 I told you so 08:52:49 a good idea, but nasty 08:53:09 so in short, a good idea 08:54:00 I can live with that:) LOL 08:55:43 zaneb, regarding context with auth and auth_type here https://review.openstack.org/#/c/580550/9/heat/common/context.py 08:56:03 hmm, actually that idea still sucks for getting the attributes 08:57:48 maybe we should override node_data() to clear the context 08:59:14 so the node date have to first check if it needs to be replaced and validate the remote authentication 09:00:31 Also auth and auth_type can be use in server side too, and it's not necessary be stored in clouds.yaml. 09:03:57 ricolin: what would that look like? where would the data come from? 09:04:01 on the server side 09:04:30 With WSGI, we use HTTP_X_AUTH_KEY to store password when heat/common/auth_password.py, maybe we can use it to store auth too? 09:07:41 ricolin: do clients do that? because if they don't it's irrelevant whether we can read it 09:11:01 It's not in our client design, so that's for Rest API only now 09:15:03 ricolin : Hi 09:15:10 asmita, Hi back 09:15:26 :) 09:15:31 I don't see the point in implementing any auth method that the rest of OpenStack doesn't support 09:18:49 zaneb, I guess we can override _auth_plugin in context and move ks_loading.get_plugin_loader to remote stack too 09:19:12 that would be less risky imho 09:20:52 BTW let's end the meeting lol 09:21:25 #endmeeting