20:00:29 <shardy> #startmeeting heat
20:00:29 <openstack> Meeting started Wed Sep  4 20:00:29 2013 UTC and is due to finish in 60 minutes.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:32 <openstack> The meeting name has been set to 'heat'
20:00:37 <shardy> #topic rollcall
20:00:39 <jpeeler> hi
20:00:40 <asalkeld> o/
20:00:40 <radix> hello!
20:00:46 <sdake_> o/
20:00:58 <zaneb> howdy y'all
20:00:59 <m4dcoder> o/
20:01:00 <adrian_otto> o/
20:01:01 <spzala> Hi
20:01:02 <sdake_> feeling ill today may not be all that responsive
20:01:06 <jasond> o/
20:01:11 <stevebaker> hi
20:01:12 <sdake_> watching from bed
20:01:29 <funzo> o/
20:01:39 <adrian_otto> sdake: sorry to hear that. I hope you feel better soon.
20:01:46 <sdake_> thanks adrian
20:01:46 <kebray> hi
20:01:48 <bgorski> o/
20:01:52 <sdake_> school plague season
20:01:53 * sdake_ ughs
20:01:54 <randallburt> hello
20:02:20 <shardy> Hi all, lets get started
20:02:32 <shardy> hope you feel better soon sdake ;)
20:02:37 <shardy> #topic Review last week's actions
20:02:46 <sdake_> fever broke so should be better tomorrow
20:02:48 <shardy> There was only one, which I think randallburt has in progress
20:02:53 <randallburt> indeed.
20:03:03 <shardy> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:03:06 <randallburt> converted to bug so we can track it there from here on out.
20:03:12 <shardy> #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-08-28-20.00.html
20:03:25 <shardy> #info andrew_plunk to move Rackspace resources to /contrib directory
20:03:32 <shardy> #action randallburt to move Rackspace resources to /contrib  directory
20:03:42 <radix> I have a question about that
20:03:59 <shardy> #link https://bugs.launchpad.net/heat/+bug/1220798
20:04:00 <uvirtbot> Launchpad bug 1220798 in heat "Move Rackspace Resources to contrib" [Medium,Triaged]
20:04:06 <radix> will the feature freeze apply to contrib?
20:04:13 <asalkeld> haha
20:04:27 <shardy> radix: ummm
20:04:41 <asalkeld> radix wants get out of jail free card
20:04:49 <shardy> I think it makes sense for it to apply to the whole tree, we should be moving to test/bugfix mode
20:04:52 <zaneb> radix: maybe you should explain what you're planning ;)
20:04:58 <stevebaker> is contrib included in the tarball?
20:05:03 <radix> well, I'm gonna be working on some of those regardless
20:05:14 <zaneb> stevebaker: definitely IMO
20:05:17 <radix> the Rackspace resources I mean
20:05:48 <radix> sorry I'm on a phone :p
20:06:01 <adrian_otto> yes, contrib should be in the tarball, and the freeze rules should apply to the whole tree.
20:06:11 <shardy> So, just to clarify, we only have a couple of weeks until RC1, at which point master will be open for Icehouse development
20:06:12 <zaneb> so, purely from a Rackspace point of view, I think there would be advantages to testing/bug fixing against a stable set of features
20:06:16 <radix> that's fine
20:06:16 <stevebaker> given that they are self-contained and work with a service on a different release cycle, there could be a case for being more relaxed
20:06:33 <shardy> So my preference is just to pause on the features until we get RC1 branched
20:06:42 <radix> shardy: oh! OK, good to know
20:06:42 <shardy> any objections or other opinions?
20:06:52 <radix> that's great
20:06:52 <zaneb> shardy: +1
20:07:06 <stevebaker> shardy: sounds good
20:07:36 <kebray> Is there a target date for branching RC1?
20:07:37 <radix> thanks :)
20:07:41 <shardy> ok, cool, which brings us to;
20:07:49 <shardy> kebray: https://wiki.openstack.org/wiki/Havana_Release_Schedule
20:07:58 <kebray> ah, duh. thx.
20:08:00 <randallburt> shardy:  to clarify, since this is a bug, I can get it in before RC? or are you saying wait until RC.
20:08:11 <shardy> #topic Feature Freeze, final status for h3
20:08:25 <shardy> randallburt: yes, it's just features (blueprints) which are frozen
20:08:31 <shardy> bugs are fine
20:08:43 <randallburt> cool, thought so, just wanted to be sure.
20:09:01 <shardy> So the feature freeze is EOD today, ttx is going to cut the milestone-proposed branch early tomorrow
20:09:54 <ttx> 2 bp left open
20:10:06 <shardy> There are still quite a few patches we need in to complete the last two bps
20:10:09 <ttx> parallel-delete and  vpnaas-support
20:10:14 <shardy> ttx: yup
20:10:21 <asalkeld> so from now on patches have to be cherry picked?
20:10:26 <shardy> #link https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/parallel-delete,n,z
20:10:32 <ttx> asalkeld: no
20:10:35 <zaneb> just approved the parallel-delete patch approx 8s ago
20:10:47 <shardy> #link https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/vpnaas-support,n,z
20:10:51 <shardy> zaneb: thanks
20:10:53 <asalkeld> cool thanks ttx
20:10:58 <ttx> asalkeld: the mp branch that will be cut tomorrow is just for h3
20:11:13 <asalkeld> makes sense
20:11:24 <ttx> master is still used for havana feature freeze exceptions and bugfixes until we do RC1
20:11:44 <ttx> then master unfreezes
20:11:57 <ttx> makes sure everyone stays focused on the RC buglist
20:11:57 <bgorski> sorry i had some technical problems
20:12:06 <bgorski> what about the vpnaas patch?
20:12:38 <shardy> So, we need some reviews for vpnaas, and for those up over the next few hours to keep an eye incase stuff needs rebasing
20:12:51 <shardy> but overall we're looking in pretty good shape
20:13:12 <bgorski> So the patch with requirements changes is merged already?
20:13:14 <ttx> shardy: do you think those las two will make it in hte nex thours ?
20:13:16 <stevebaker> are we considering extensions for any features that miss the boat?
20:13:22 <bgorski> If so I will rebase my patches
20:13:23 <shardy> #link https://launchpad.net/heat/+milestone/havana-3
20:13:32 <ttx> shardy: or do you plan to require exceptions for them ?
20:13:53 <shardy> ttx: I hope so, but it depends on the gate (and reviews for the vpnaas, although I've +2'd them all)
20:14:32 <shardy> bgorski: Your patches need rebasing over the trusts patch which bumps keystoneclient
20:14:35 <ttx> shardy: if all it needs is a couple more hours it's fine for FFE. It's just slightly inconvenient that they miss the H3 boat
20:15:26 <shardy> ttx: Ok, well if necessary we may need a FFE for parallel-delete and vpnaas
20:15:45 <ttx> ok noted
20:16:04 <shardy> ttx: I bumped as-update-policy as it was just getting too late
20:16:16 <ttx> shardy: ack
20:16:58 <shardy> Anyone have anything to add, or any questions?
20:17:27 <ttx> vpnaas is a no brainer since it's well contained
20:17:44 <asalkeld> bgorski, there seems to be a requiresments change needed?
20:17:44 <shardy> ttx: agree, patches all lgtm too
20:17:44 <ttx> parallel-delete is slightly more invasive but I guess it's worth it
20:17:48 <shardy> nice work bgorski
20:18:12 <ttx> as long as they merge in the next days we should be fine for FFE
20:18:13 <asalkeld> https://review.openstack.org/#/c/44892/
20:18:13 <ttx> in case they need one
20:18:25 <shardy> Nice work everyone on h3, we've got through a huge pile of bps and bugs, really great work :)
20:18:58 <stevebaker> \o/
20:19:13 <shardy> asalkeld: no it needs rebasing on my bumped keystoneclient version
20:19:27 <asalkeld> ok, cool
20:19:45 <stevebaker> we should probably do those requirements version changes in separate commits
20:20:06 <shardy> stevebaker: rather than in the commit which requires them?
20:20:30 <shardy> stevebaker: I think that happened anyway for neutronclient, but I bumped keystoneclient in the trusts patch
20:20:42 <stevebaker> well, I'm talking about the automatic requirements changes that happen just by running devstack
20:20:43 <asalkeld> https://review.openstack.org/#/c/44957/
20:20:58 <stevebaker> if it is coupled to the code, then ignore me
20:21:55 <bgorski> asalkeld: thx, I a little bit distructed but I'm trying to keep up with you guys
20:22:08 <shardy> asalkeld: Yeah, the same bump happens in the first vpnaas patch, but shouldn't conflict
20:22:22 <shardy> oh that needs a rebase anyway
20:22:33 * SpamapS o/
20:23:09 <shardy> asalkeld, stevebaker: are you in a position to pull some of these and re-propose if needed, if there are simple rebases that need to happen over the next few hours?
20:23:17 <asalkeld> sure
20:23:25 <shardy> or should we just let things slip and use the FFEs to get them in later?
20:23:31 <stevebaker> yep, we can nurse them in
20:23:44 <shardy> stevebaker: Ok, cool, probably easier if possible
20:23:46 <shardy> thanks
20:24:26 <shardy> Ok, on to open discussion, or anything remaining re h3?
20:25:00 <shardy> #topic Open Discussion
20:25:08 <shardy> Anyone have anything to raise?
20:25:19 <stevebaker> shall we talk docs next week?
20:25:20 <asalkeld> shardy, we really need deployment guide
20:25:30 <asalkeld> snap
20:25:42 <shardy> stevebaker: yup, need a docs sprint soon
20:26:06 <stevebaker> deployment guide should really be integrated with the docs.openstack.org one
20:26:08 <shardy> although the template orientated docs are already looking really good, so kudos to all who made that happen :)
20:26:10 <asalkeld> btw I am off for 3 weeks from the end of this week
20:26:33 <shardy> asalkeld: nice! :)
20:26:37 <SpamapS> I am curious about HOT templates.
20:26:41 <zaneb> stevebaker: I've been thinking about the multi-region stuff
20:26:48 <SpamapS> the heat-templates repo currently has only 2
20:26:54 <stevebaker> zaneb: yes?
20:26:55 <radix> oh no! we'll miss you asalkeld :)
20:27:01 <shardy> SpamapS: more would be good
20:27:07 <zaneb> stevebaker: I think configuring the region always makes sense, so we should go ahead with that change...
20:27:28 <radix> well we could auto convert a bunch couldn't we?
20:27:28 <SpamapS> I think as part of the test/fix/document effort we should put special emphasis on writing HOT templates.
20:27:32 <SpamapS> and using HOT in examples.
20:27:40 <zaneb> stevebaker: but, I also think the multi-region thing makes sense *provided* it's only used for stand-alone Heat installations
20:27:42 <stevebaker> SpamapS: +1
20:27:44 <SpamapS> But.. is it.. stable enough for that?
20:27:46 <randallburt> we've been working on several HOT templates. There are a couple of repos out on github we can pull from and consolodate
20:27:55 <shardy> SpamapS: I think the example templates can follow the docs (which look nearly there atm)
20:28:01 <SpamapS> I was thinking I'd start by converting tripleo-heat-templates to HOT.
20:28:07 <shardy> SpamapS: but go for it if you want to contribute some :)
20:28:09 <randallburt> They seem to be working fine so far
20:28:12 <shardy> SpamapS: cool, sounds good
20:28:27 <zaneb> stevebaker: so I'd support adding that as well, as long as it's something configured in the config file. preferably using a different middleware.
20:28:53 <stevebaker> zaneb: hmm, that sounds fine. it could either go into the auth_password middleware or something else in the standalone pipeline
20:29:16 <shardy> randallburt: Ok if you have stuff you can contribute to heat-templates that would be great
20:29:32 <stevebaker> and better yet, its *obviously* a bug ;)
20:29:57 <zaneb> stevebaker: my thoughts exactly ;)
20:30:35 <randallburt> shardy:  will do
20:31:08 <shardy> more provider template examples would be really good too
20:31:24 <stevebaker> shardy: how will heatclient know not to send credentials on create when trusts are enabled?
20:31:32 <spzala> randallburt: cool. Are those new HOT templates? or converting existing ones?
20:32:18 <shardy> stevebaker: It still sends credentials
20:32:30 <shardy> stevebaker: we just create a trust internally instead of storing them
20:32:45 <randallburt> shardy:  those might be a little broken atm wrt HOT. we're investigating now
20:32:55 <stevebaker> but it doesn't strictly need to does it? because the trust is created from the token?
20:33:02 <shardy> randallburt: Ok, pls raise bugs with details
20:33:27 <shardy> stevebaker: well you need to pass either user/pass, or token
20:33:41 <shardy> then that's used to create the trust, which we store the ID of
20:33:42 <randallburt> will do when I figure out what's going on. its in the refactored attribute/property schema conversion code somewhere I think.
20:33:48 <SpamapS> seems like a follow up to heatclient would be to try w/o creds first
20:33:49 <adrian_otto> we should consider adding a feature to suppress sending of credentials when trusts are used, and probably a hot expression to enable that so the template itself can indicate that heatclient should act that way.
20:34:24 <shardy> trusts does *not* mean heatclient works without credentials!
20:34:31 <shardy> where are people getting that from?
20:34:39 <adrian_otto> no, it does not need to send them after it's using a trust
20:34:40 <SpamapS> seems logical to me
20:34:51 <adrian_otto> so sending them when a trust is in play is redundant
20:35:01 <adrian_otto> right?
20:35:02 <shardy> adrian_otto: that's wrong, all it means is that we no longer store the username and password
20:35:13 <SpamapS> shardy: why do we keep sending it to Heat though?
20:35:17 <stevebaker> shardy: currently on create, credentials are sent to keystone, then token *and* credentials are sent to heat
20:35:27 <shardy> and that deferred operations now work with token auth, not just user/password
20:35:34 <zaneb> shardy: surely you can just send a token, not the username/pass
20:35:36 <SpamapS> shardy: shouldn't we just .. trust .. that stacks we created have a trust, and talk to heat using our heat token?
20:35:41 <stevebaker> ideally it should be credentials to keystone, then only a token to heat
20:35:59 <shardy> stevebaker: yeah, we only need the token when trusts are enabled
20:36:13 <shardy> thats the other big enhancement, over not storing creds
20:36:29 <asalkeld> is there a way to check if the cloud you are talking to supports trusts?
20:36:39 <asalkeld> (via api)
20:36:42 <SpamapS> Right so it seems to me that we should be able to try to operate with token.. and if that fails.. fall back to u/p
20:36:47 <shardy> SpamapS: you can talk to heat with whatever credentials or token you like as long as keystone will validate it
20:37:08 <shardy> what you authenticate against the heat API with has nothing to do with trusts (which we just use internally)
20:37:48 <stevebaker> so I think SpamapS is right, heatclient can attempt without creds first, then with on failure
20:37:57 <shardy> asalkeld: You could try to read the OS-TRUST path of the v3 keystone API
20:38:11 <shardy> but atm we expect deployers to enable it via a config file option
20:38:21 <radix> could heat grow an api that allows users to pass in a trust and no u/p?
20:38:37 <asalkeld> just thinking of the multicloud option
20:38:38 <zaneb> shardy: other services only allow token auth though, right?
20:38:41 <SpamapS> radix: I was hoping that was how it would work actually.
20:38:45 <shardy> stevebaker: when you say creds, you mean user/password right?
20:38:50 <stevebaker> shardy: yes
20:39:06 <stevebaker> radix: we may need something like that if we add oauth
20:39:11 <shardy> as a bearer token is a credential in my mind, which is why I'm confused
20:39:12 <SpamapS> AFAIK, trusts are behind the scene right now.
20:39:34 <SpamapS> but they certainly could be something that heatclient fetches itself from keystone, and gives to heat, right?
20:39:47 <shardy> Ok, so *yes* trusts should allow Heat to work properly, including deferred operations like AutoScaling with token-only auth
20:39:54 <stevebaker> shardy: ah, sorry.
20:39:54 <shardy> phew
20:40:45 <shardy> SpamapS: no, the user passes either a token or user/pass to heat, then *heat* creates the trust internally
20:41:09 <radix> hm. OK
20:41:11 <shardy> then we store the ID of that trust, and use it to impersonate the stack creator, e.g when we create an instance for AutoScaling
20:41:16 <SpamapS> shardy: I know that is how it works now. I am hoping that we can let the client do the trust creating and heat will never be made aware of the user/pass.. eventually. :)
20:41:42 <shardy> SpamapS: you mean pass a trust ID to heat via the API?
20:41:46 <SpamapS> Yes.
20:41:51 <adrian_otto> +1
20:41:57 <shardy> SpamapS: yes, that should be pretty easy to add now
20:42:22 <SpamapS> shardy: seems like it would require a bunch of work in heatclient and inside heat, and would be a good candidate for early icehouse :)
20:42:46 <zaneb> +1
20:42:57 <shardy> SpamapS: yeah, I was thinking pretty easy when it hits the engine..
20:42:59 <stevebaker> yo
20:43:09 <SpamapS> shardy: the only real benefit though is improved security for usernames and passwords... I think.
20:43:17 <shardy> SpamapS: Ok, I'll raise a BP and we can discuss this at summit
20:43:34 <shardy> SpamapS: why can you just pass a token?
20:43:41 <shardy> which works now?
20:43:55 <radix> trusts are revokable too, right?
20:44:02 <shardy> radix: yes
20:44:15 <SpamapS> shardy: pass a keystone-access token which enables you to create the trust? If that works, cool.. didn't think it would.
20:44:36 <shardy> SpamapS: that works now, with what was merged today
20:44:41 <shardy> (hopefully ;)
20:44:51 <SpamapS> "in theory"
20:45:03 <stevebaker> hey, I need to go now
20:45:04 <SpamapS> well then that would mean only temporary secrets being passed around.. which is a win, IMO.
20:45:04 <shardy> <disclaimer> etc ;D
20:45:18 <zaneb> stevebaker: o/
20:45:23 <shardy> SpamapS: yeah, it's a step in the right direction
20:45:26 <shardy> stevebaker: o/
20:45:37 <SpamapS> shardy: well hopefully we have all gained clarity on the situation. Thanks.
20:45:45 <radix> so is it possible to get full functionality out of heat and autoscale without giving heat a u/p?
20:45:55 <SpamapS> radix: sounds like "yes in theory"
20:46:05 <radix> great
20:46:09 <SpamapS> but that heatclient still passes u/p "because"
20:46:17 <shardy> SpamapS: cool, everyone keep firing questions at me over the next few weeks as you try this stuff out, hopefully we can gain collective knowledge and test exposure :)
20:47:27 <shardy> radix: Yes, but it's not very well tested yet as it was only merged today :)
20:47:45 <radix> sure :)
20:48:40 <shardy> SpamapS: we should add a token-only option to heatclient if one doesn't already exist
20:48:58 <shardy> anyone have anything else to raise for the last 10mins?
20:49:32 <SpamapS> I would like to raise that you are all ninjas.<EOM />
20:49:37 <radix> nup
20:49:47 <zaneb> SpamapS: rofl
20:49:57 <shardy> Ok, well we can wrap up early then
20:50:02 <shardy> great work everyone :)
20:50:15 <zaneb> woohoo!
20:50:17 <shardy> #endmeeting