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