15:00:13 <ramishra> #startmeeting heat
15:00:13 <openstack> Meeting started Wed Feb  1 15:00:13 2017 UTC and is due to finish in 60 minutes.  The chair is ramishra. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:16 <openstack> The meeting name has been set to 'heat'
15:00:22 <ramishra> #topic roll call
15:00:32 <ricolin> o/
15:00:34 <breton> o/
15:00:40 <cwolferh> o/
15:01:03 <ktychkova> o/
15:01:06 <skraynev> o/
15:01:23 <therve> /o
15:02:15 <zaneb> o/
15:02:21 <ramishra> my last meeting as PTL:)
15:02:29 <zaneb> therve: that looks painful
15:02:39 <ramishra> #topic adding items to agenda
15:02:51 <ramishra> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-02-01_1500_UTC.29
15:03:08 <therve> :)
15:03:40 <ramishra> #topic ocata-rc1 status
15:03:51 <ramishra> #link https://launchpad.net/heat/+milestone/ocata-rc1
15:04:02 <prazumovsky> Hi
15:04:11 <ramishra> Anything we want from these bugs before we tag rc1?
15:04:22 <ramishra> None of them look critical to me
15:05:07 <therve> They should be marked as such otherwise :)
15:05:09 <therve> So yeah I agree
15:05:34 <ramishra> It would have been good to land https://review.openstack.org/374321 though
15:06:12 <zaneb> bumped https://bugs.launchpad.net/heat/+bug/1625759 to pike-1, since it's a feature
15:06:12 <openstack> Launchpad bug 1625759 in heat "Should be able to select external subnet for FloatingIP" [Medium,In progress] - Assigned to Tanvir Talukder (tanvirt16)
15:06:19 <ramishra> magnum resource renaming thing.
15:06:54 <zaneb> https://review.openstack.org/#/c/358106/ should be an easy one, will review after this
15:06:54 <ricolin> I will be great to land it:)
15:07:49 <ramishra> ok, I'll wait till tomorrow, else move them to pike-1
15:07:56 <shardy> o/
15:08:20 <ramishra> shardy: hi
15:08:28 <skraynev> ramishra: sounds good.
15:08:47 <skraynev> ramishra: regarding https://review.openstack.org/374321 is is just renaming?
15:09:22 <ricolin> skraynev: For most of the resource logic, yes!
15:09:31 <ramishra> skraynev: yeah renaming and some property name changes.
15:09:33 <skraynev> ok. I will try to review it :)
15:09:46 <ramishra> ok, then let's move on
15:09:54 <skraynev> but of course you may merge it before me :)
15:09:57 <ramishra> #topic Heat support of Keystone Federated tokens
15:10:03 <skraynev> it's mine.
15:10:06 <breton> hi
15:10:15 <breton> Federated tokens don't work in heat now when heat uses trusts
15:10:31 <breton> It happens because when user authenticates in keystone, their groups (which provide roles) are stored only in tokens.
15:10:48 <breton> there are 2 parts of the problem
15:10:56 <ramishra> skraynev: yeah we see users coming with issues on irc when they use heat with federated keystone
15:11:25 <ramishra> shardy: do you know how it should work?
15:11:26 <breton> 1. on trust creation. Keystone tries to lookup federated user's roles in the database and fails, because there is no persistent record. It is kinda solvable, we can extract groups from token and lookup the roles.
15:11:30 <skraynev> ramishra: yeah breton tries to describe the root cause :)
15:12:03 <breton> 2. On trust usage. Keystone tries to verify that trustor still has the roles that he is passing. And here it becomes bad. There is no persistent record about the federated user in the database and keystone cannot verify it. From keystone point of view, federated trustor has no roles.
15:12:13 <skraynev> ramishra: looks like we can not use trusts with fernet tokens
15:12:32 <shardy> breton: so, basically trusts don't work with Federated tokens in general, this isn't actually a heat specific issue?
15:12:39 <breton> skraynev: this is not about fernet at all
15:12:51 <breton> the problem is there from liberty and we ran into it.
15:12:53 <breton> skraynev: yes.
15:13:02 <breton> oh
15:13:05 <breton> shardy: yes
15:13:17 <breton> I myself work mostly on keystone, but yesterday at the meeting we decided that fixing it in keystone requires a lot of work and some controversial decisions that might create vulnerabilities.
15:13:28 <breton> (and still maybe won't work for heat)
15:13:40 <shardy> breton: is there some alternative model for delegation available that does work with federation?
15:13:40 <breton> so i was wondering, maybe we can do something on Heat side to work around that issue?
15:14:12 <breton> shardy: i can't think of any
15:14:24 <shardy> breton: what sort of workaround did you have in mind?
15:14:42 <shardy> it sounds like the problem is on the keystone side, I'm unclear how we can fix it as a consumer of trusts
15:14:53 <breton> shardy: none. I was wondering what you can suggest.
15:15:30 <ramishra> probably a good topic at PTG along with keystone folks?
15:15:40 <shardy> breton: Hmm, I'm not sure what to suggest, heat uses trusts, and keystone broke trusts, I can't think of a heat side fix for it but we can certainly think about it :)
15:15:57 <shardy> ramishra: yeah that's a good idea, and gives us all some time to look into the issue further
15:16:16 <zaneb> shardy: remind me why we care about the roles?
15:16:16 <shardy> breton: thanks for raising this, will you be at the PTG?
15:16:31 <breton> shardy: yes, i will, mostly around keystone table probably
15:16:31 <shardy> zaneb: because trusts require you to specify the roles which are delegated
15:16:39 <shardy> both when creating the trust, and when consuming it
15:17:19 <zaneb> can _we_ store that info when we create the trust?
15:17:20 <ricolin> breton: maybe we can add new session
15:17:27 <ricolin> #link https://etherpad.openstack.org/p/heat-pike-ptg-sessions
15:17:52 <shardy> zaneb: yes we can, but isn't the problem that keystone doesn't know about it, so it can't validate the list of roles?
15:18:05 <zaneb> ah, ok
15:18:25 <breton> shardy: right
15:18:32 <zaneb> breton: I don't see how that's fixable outside of keystone
15:18:40 <zaneb> even in principle?
15:18:45 <skraynev> shardy: yes, as I understand keystone can not get any information about roles for users ..
15:18:46 <shardy> when keystone gives you a trust scoped token, it gives you a token with a list of roles (and user identity) associated with the trust ID
15:19:15 <breton> maybe heat could do things as `heat` user with admin roles?
15:19:20 <breton> instead of imitating the user
15:19:25 <zaneb> breton: NO
15:19:36 <shardy> breton: No, because then when you e.g do autoscaling the new VMs wouldn't be owned by the users
15:19:47 <shardy> imagine the billing and security implications for a second ;)
15:20:12 <breton> ok, i was just wondering :)
15:20:20 <breton> i have little idea how heat things work :)
15:20:29 <shardy> breton: the other alternative (which heat already supports) is to use the "password" option for delegated auth, but then we store user passwords, which may change, in the heat DB
15:20:33 <shardy> which is bad
15:20:45 <zaneb> bad bad bad
15:20:52 <shardy> breton: well, honestly the problem seems to be keystone broke trusts for everyone
15:21:03 <breton> shardy: you are right
15:21:13 <shardy> so I'm not clear what heat can do, except maybe plan to find another way to do this in the long term
15:21:15 <zaneb> breton: if you can offer us OAuth2 or something instead then we can work with that
15:21:24 <shardy> breaking stuff without deprecation is pretty uncool tho :(
15:21:36 <breton> shardy: we never broke it
15:21:43 <breton> shardy: federation + trusts never worked :p
15:21:51 <ramishra> shardy: did they break it?
15:21:59 <ramishra> yeah it never worked
15:22:06 <shardy> zaneb: Yeah I was going to say oauth, but last time I looked you can't create delegations without a finite expiry
15:22:19 <shardy> breton: my point is you implemented a feature which broke trusts
15:22:21 <zaneb> breton: if you're telling us that only human people physically sitting in front of a keyboard can use OpenStack APIs then you need to have another think about what OpenStack is :)
15:22:25 <shardy> or at least is incompatible with it
15:22:41 <shardy> so a heat side workaround doesn't help that much, as I assume there are other users with the same problem
15:23:15 <breton> shardy: come tell that at the PTG
15:23:22 <breton> shardy: i 100% support you
15:23:26 <shardy> anyway, lets try to be constructive, I'm just frustrated that this wasn't considered before it broke us
15:24:00 <shardy> breton: is keystone planning to deprecate trusts, or find a more general solution?
15:24:11 <zaneb> shardy: I don't know that it broke us so much as the intersection of those 2 features doesn't work
15:24:29 <breton> shardy: probably no
15:24:38 <zaneb> which imho makes federation fairly useless
15:25:04 <shardy> zaneb: yeah my point was just it's an intesection of two keystone features, heat is just a consumer of keystone
15:26:16 <skraynev> zaneb, shardy, breton. wow. guys. let's avoid accusations. the reality is, that it does not work
15:26:16 <shardy> Ok, well sounds like we won't solve this today, let's all think about it and try to figure out a path forward at the PTG
15:26:34 <shardy> breton: thanks for raising this, be good to discuss further in atlanta
15:26:39 <ramishra> shardy: yeah, I'll add a PTG session with keystone team
15:26:42 <skraynev> and we need to communicate with keystone team and explain our point of view. and try to find solution
15:27:07 <skraynev> ramishra: thx ;)
15:27:23 <ramishra> Not sure if it would be cross-project session or we can just invite keystone guys
15:27:33 <zaneb> ramishra: +1
15:27:41 <ricolin> ramishra: cross-project+1
15:27:45 <zaneb> fwiw there are many other projects using trusts
15:27:52 <zaneb> aodh, mistral come to mind
15:28:05 <ramishra> I think trusts is an important feature for not to work with federation
15:28:46 <shardy> Yeah mistral, heat, sahara, magnum
15:28:52 <shardy> I think they all use trusts
15:29:10 <ramishra> should we move on now?
15:29:16 <zaneb> sounds cross-project-ish
15:29:32 <skraynev> ramishra: yeap
15:29:43 <ramishra> #topic PTG sessions
15:30:01 <ricolin> #link https://etherpad.openstack.org/p/heat-pike-ptg-sessions
15:30:30 <ramishra> May be it's time to add some more topics:)
15:30:41 <ricolin> the keystone cross project will be a good topic to add in
15:31:13 <ramishra> shardy anything tripleo specific we should add?
15:31:22 <ricolin> we will figure out which team going to host the session, but will be great to write down first:)
15:33:15 <ramishra> We need 2 full days worth topics
15:33:35 <ricolin> maybe no fishbow this time?
15:33:55 <therve> ricolin, There is no such thing in the ptg
15:34:01 <therve> AFAIK
15:34:02 <zaneb> ricolin: yeah, there are no fishbowl-style sessions at the PTG
15:34:04 <ricolin> therve: great!
15:34:09 <zaneb> those still happen at the Summit
15:34:10 <ramishra> ricolin: we have a room for 2 days, we can do whatever we want
15:34:11 <shardy> ramishra: Nothing specific, but I've been wondering now we added conditions if we'll ever add a way to create repeating groups of resources natively in heat without having to nest them
15:34:26 <ramishra> not sure how big the rooms would be though
15:34:30 <shardy> we said no several times in the past, but tripleo now shows why folks were asking for it
15:34:36 <shardy> all the j2 loops everywhere
15:35:44 <shardy> that may be a disscussion for the beer-track vs a formal session though
15:36:05 <ramishra> shardy: beer-track +1
15:36:21 <ricolin> +1
15:36:55 <ramishra> Request all to spend some time and help finalize the sessions
15:37:25 <ramishra> moving on..
15:37:37 <ramishra> #topic Meeting time discuss
15:37:50 <zaneb> would it help to have a list of people who are planning to attend the PTG?
15:38:13 <ricolin> I would like to propose to move all meeting time schedule to current one
15:38:23 <ricolin> zaneb: I think foundation have it
15:38:57 <ramishra> zaneb: we can ask people to add their names to the etherpad if they are attending
15:39:05 <zaneb> ricolin: I meant we should just write in the etherpad
15:39:19 <ricolin> zaneb: Sounds great
15:39:37 <zaneb> e.g. I suggested a session on property translation but I don't know if prazumovsky is going to be there
15:40:06 <ricolin> #link https://etherpad.openstack.org/p/heat-pike-ptg-sessions
15:40:13 <ricolin> I add the attendee list in it
15:40:25 <zaneb> thanks
15:41:25 <ramishra> ricolin: we don't have many APAC guys attending the 0800 meeting, so I would be +1 for having them at 1500 every week
15:41:30 <ricolin> prazumovsky: are you going to attend PTG?:)
15:41:43 <zaneb> re meeting schedule, this time wfm but I don't know about everyone
15:43:05 <therve> I've been working on making the py3 gate works
15:43:16 <ricolin> We can alway have some other meeting or ML for APAC if we have more people would like to join and discuss
15:43:17 <therve> I think we mostly have issues in the tests now
15:43:18 <ramishra> May be ask a few other folks or start a ML thread?
15:43:26 <therve> We'll get stuck on swift soon
15:43:32 <ramishra> therve: I had looked at it last week too
15:43:37 <ricolin> ramishra: Sure, I will send the ML out
15:43:44 <ramishra> I see some issue with cloud-init no?
15:44:05 <therve> ramishra, Yeah haven't looked at that one yet
15:46:07 <ricolin> Let's decide through this week, if no much opposition, we will move next week's meeting to 1500
15:46:08 <ramishra> therve: I've moved the apache job now, now that http+wsgi is the default with devstack for api services
15:46:23 <therve> Cool
15:46:26 <ramishra> s/moved/removed in this patch https://review.openstack.org/#/c/427696/
15:48:21 <ramishra> #topic open discussion
15:48:43 <ramishra> Anything else we would like to discuss?
15:49:15 <ramishra> Next week it would be ricolin the new PTL chairing the meeting:)
15:49:25 <ramishra> ricolin: congrats!
15:49:28 <zaneb> congrats ricolin :)
15:49:36 <ricolin> Thanks guys:)
15:49:55 <shardy> congrats ricolin :)
15:50:15 <ricolin> I will try my best to be a mediator:)
15:50:52 <ricolin> And we have a bunch of pre-PTL around!
15:52:39 <ricolin> everything will be great:)
15:52:55 <ramishra> ok then, if there is nothing else....
15:53:06 <ramishra> thank you all for joining
15:53:41 <ramishra> #endmeeting