20:00:05 <stevebaker> #startmeeting heat
20:00:05 <openstack> Meeting started Wed Dec 18 20:00:05 2013 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:09 <openstack> The meeting name has been set to 'heat'
20:00:26 <stevebaker> #topic rollcall
20:00:28 <sdake> o/
20:00:29 <asalkeld> o/
20:00:32 <jasond> o/
20:00:33 <shardy> o/
20:00:36 <lakshmi> o/
20:00:38 <pshchelo> o/
20:00:41 <jdob> o/
20:00:45 <bgorski> o/
20:00:49 <jpeeler> o/
20:00:50 <funzo> o/
20:01:14 <zaneb> \o
20:01:30 <spzala> Hi
20:01:47 <arbylee> o/
20:01:47 <stevebaker> #topic Review last meeting's actions
20:01:51 <andersonvom> o/
20:01:58 <stevebaker> asalkeld to raise a bp for migrating to oslo.messaging
20:02:20 <asalkeld> looking for it
20:02:54 <stevebaker> #topic Adding items to the agenda
20:02:55 <asalkeld> oops
20:03:01 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282013-12-18.29
20:03:44 <stevebaker> anything to add for anybodies?
20:04:24 <SpamapS> o/
20:04:30 <stevebaker> asalkeld: should I re-add that action? ;)
20:04:56 <asalkeld> it's odd, I can't add it 'cos it think it's there
20:05:02 <asalkeld> but I can't find it
20:05:41 <shardy> stevebaker: maybe discuss instance-users if we have time
20:05:59 <stevebaker> shardy: ok
20:07:11 <stevebaker> asalkeld: I've got no launchpad mail mentioning oslo messaging
20:07:29 <asalkeld> ok, well I am doing it now
20:07:33 <stevebaker> #topic Postponing meetings over new year
20:07:43 <zaneb> +1
20:07:50 <shardy> +1
20:07:51 <sdake> +1 i'll be out ;)
20:07:56 <stevebaker> So I'm assuming there is no objections to not having the next meeting
20:07:57 <bgorski> +1
20:08:13 <shardy> I vote we skip two weeks
20:08:27 <zaneb> yep
20:08:32 <stevebaker> I'm not back till the 6th, so would be happy to skip 2 meetings
20:08:38 <zaneb> next two are xmas day and new year's day
20:08:53 <zaneb> so I definitely think we should skip 2
20:08:58 <andersonvom> +1
20:09:16 <asalkeld> stevebaker, https://blueprints.launchpad.net/heat/+spec/oslo-messaging-for-rpc
20:09:23 <stevebaker> #agreed Cancel heat meetings for December 25th and January 1st
20:09:36 <jdob> +1, I'll be out too
20:09:42 <jdob> (and apparently late to vote)
20:09:50 <stevebaker> done!
20:10:10 <stevebaker> #topic Inclusive meeting times
20:10:35 <zaneb> heh, there's a deep irony in discussing this at the meeting
20:10:47 <pshchelo> zaneb: :)
20:10:52 <stevebaker> So it is obvious that our contributors in Asia are getting a raw deal out of our current meeting time
20:11:32 <stevebaker> There is no single meeting time that everyone can attend, so we can only mitigate
20:11:47 <asalkeld> ceilometer alternates
20:12:03 <asalkeld> (two different times)
20:12:07 <zaneb> asalkeld: yeah, can you explain how that works?
20:12:31 <asalkeld> so you get one time that's frendly to you and one that sucks)
20:12:47 <asalkeld> we could use doodle to poll on times
20:12:47 <stevebaker> For one thing, we should be having major discussions and decisions on the mailing list, so this meeting is more for real-time discussions and project admin
20:13:03 <asalkeld> http://doodle.com/
20:13:39 <pshchelo> +1 for doodle
20:13:46 <andersonvom> or just figure it out using the actual timezones: http://www.timeanddate.com/worldclock/meetingtime.html?iso=20131218&p1=24&p2=33
20:13:48 <asalkeld> stevebaker, ml is exausting and really slow
20:14:18 <stevebaker> so the most common approaches to meeting times seem to be:
20:14:18 <asalkeld> (not the fastest way to have a design discussion)
20:14:20 <stevebaker> - different times on alternate weeks
20:14:22 <stevebaker> - keep a single weekly meet and add a monthly meeting at an alternate time
20:14:32 <sdake> advantage of mailing list is it gives people a chance to think before they type ;-)
20:14:55 <SpamapS> wait
20:14:57 <sdake> asalkeld that is why you find it exhausting :)
20:15:01 <SpamapS> we're supposed to think before we type?
20:15:13 <sdake> I read that in an abc's of typing book SpamapS
20:15:18 <jdob> someone should put that on a wiki somewhere
20:15:44 <sdake> yes, openstack needs a quotes page, I elect jdob
20:16:09 <jdob> that's probably a smart move, I say enough dumb stuff that I need to be able to limit the amount of times I find myself on that page
20:16:38 * jdob goes back into his corner so we can get back to talking about meeting times
20:16:45 <stevebaker> so should we consider alternating times like ceilometer?
20:17:12 <sdake> stevebaker wfm, as long as we can get something reasonable for the us (eg not 3am)
20:17:16 <stevebaker> because zaneb misses his midnight meetings
20:17:22 <shardy> lol
20:18:01 <shardy> I think we should at least consider if we can make alternating meetings without losing too many attendees
20:18:02 <andersonvom> stevebaker: I think that's a fine approach, I'd suggest two different not so sucky times, as opposed to one really sucky time every other week
20:18:27 <asalkeld> +1
20:18:37 <pshchelo> +1
20:18:40 <sdake> one problem is the openstack meeting channel is booked nonstop :(
20:18:45 <zaneb> stevebaker: dammit, I just emigrated to avoid those meetings!
20:18:48 <SpamapS> Sounds to me like the alternation just needs to be a few hours apart
20:19:00 <shardy> sdake: Isn't there an alternate meeting channel?
20:19:00 <asalkeld> else we might miss our ptl every alternate week
20:19:11 <sdake> shardy yup we could use that as well
20:19:14 <stevebaker> andersonvom: a non sucky time for you will always be a sucky time for someone else
20:19:17 <SpamapS> right just go 8hours east of PTL one time, and 8 hours west of PTL the other.
20:19:37 <asalkeld> har
20:19:48 <stevebaker> I think we should keep this time as alternate 1
20:20:12 <stevebaker> I'll post a doodle poll for the other time.
20:20:15 <asalkeld> it seems to work for most people
20:20:28 <stevebaker> btw, don't google "post a doodle"
20:20:36 <asalkeld> lol
20:20:55 <jdob> ha.
20:21:01 <SpamapS> doh
20:21:19 <sdake> day of week in doodle poll too, or shooting for wednesday?
20:21:19 <stevebaker> #action stevebaker start a doodle.com poll to find an alternate meeting time for every second week
20:21:24 <asalkeld> http://editorial.designtaxi.com/news-postittable1506/2.jpg
20:21:33 <asalkeld> I want a desk like that
20:21:45 <stevebaker> sdake: good question, I'll have to look for actual slots in the meeting rooms
20:22:19 <stevebaker> #topic Ratify changes to heat-core nomination process
20:22:25 <stevebaker> #link https://wiki.openstack.org/w/index.php?title=Heat%2FCoreTeam&diff=38037&oldid=28589
20:23:05 <stevebaker> +1 on that change
20:23:43 <zaneb> +1 obvs, since I wrote it ;)
20:23:43 <shardy> stevebaker: +1
20:24:12 <jpeeler2> +1 looks good
20:24:14 <asalkeld> +2
20:24:53 <stevebaker> sdake, SpamapS any opinions ^
20:25:07 <zaneb> iirc randallburt gave his +1 in #heat last week
20:26:21 <stevebaker> I think we can say agreed on that
20:26:34 <stevebaker> #agreed ratified https://wiki.openstack.org/w/index.php?title=Heat%2FCoreTeam&diff=38037&oldid=28589
20:26:55 <stevebaker> #topic Autoscaling design
20:26:56 <SpamapS> stevebaker: reading
20:27:25 <SpamapS> +1
20:27:57 <stevebaker> so possibly radix nor therve are here, but therve mentioned yesterday that autoscaling dev had stopped because there were unresolved questions about the design.
20:28:26 <shardy> stevebaker: What unresolved questions?  I didn't see anything on the ML recently?
20:28:29 <zaneb> that's... worrying
20:28:36 <stevebaker> I had assumed progress was being made, so I just wanted to make sure any lingering issues could be unblocked
20:28:48 <zaneb> yes, I was about to ask, have these unresolved questions been asked on the ML?
20:28:50 <stevebaker> therve isn't here - meeting time isn't convenient ;)
20:29:28 <zaneb> pffft, it's only 9pm there ;)
20:29:46 <stevebaker> the french need their beauty sleep
20:30:42 <stevebaker> oh well, lets talk in #heat or the ml to find out the status
20:31:09 <stevebaker> #topic Software config POC
20:31:39 <stevebaker> I sent out an email at the end of last week
20:32:05 <radix> hello
20:32:09 <radix> stevebaker: I'm here, sorry I'm late
20:32:20 <stevebaker> radix: no problem
20:32:33 * stevebaker pushes rewind
20:32:35 <stevebaker> #topic Autoscaling design
20:32:57 <radix> there are some unresolved questions, but they're not blockers for initial work. I haven't been able to get back to that in a while unfortunately but I should be able to start kicking it soon
20:33:18 <stevebaker> ok, let us know if there is anything we can help with
20:33:56 <radix> at least I'm going to submit some patches to just add stub "autoscaling" API and engine processes
20:34:03 <radix> and then gradually implement the API
20:35:03 <stevebaker> that sounds fine
20:35:22 * stevebaker pushes ff
20:35:29 <sdake> stevebaker sorry was in an email at the time, yes +1 looks good
20:35:30 <stevebaker> #topic Software config POC
20:36:22 <stevebaker> So I realise architecture reviews are the hardest kind, but that is what is needed before this POC can be fleshed out
20:36:24 <stevebaker> #link https://review.openstack.org/#/q/topic:bp/hot-software-config,n,z
20:36:27 <zaneb> just as a general PSA, if you have unresolved questions about a design, post them to the mailing list
20:37:25 <stevebaker> Fundamentally it comes down to this new REST API, the rest is just details that we can chew over in later reviews https://review.openstack.org/#/c/58878/8/heat/api/openstack/v1/__init__.py
20:38:39 <zaneb> stevebaker: "" is "/"?
20:39:02 <SpamapS> stevebaker: I'm going to start needing the software config stuff so that we can do different OpenStack topologies .. so I will try to get going on these reviews soon.
20:39:05 <stevebaker> zaneb: yes, its /{tenant_id}/software_configs
20:39:21 <zaneb> oh, I see
20:39:24 <zaneb> thanks
20:39:57 <zaneb> it's hard to argue with that API :)
20:40:15 <stevebaker> good!
20:41:01 <stevebaker> I'll let you all review that offline, but I also wanted to discuss cloud-init config in templates
20:41:48 <stevebaker> I had some intrinsic functions for formatting multi-part mime, but I've gone off that idea https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/cloud-init-resource,n,z
20:42:40 <zaneb> good ;)
20:43:00 <stevebaker> I'm now thinking that cloud-init could benefit from being backed by real resources, specifically subclass of SoftwareConfig
20:43:26 <stevebaker> so the software config resource relationship is currently config<-deployment->server
20:44:09 <stevebaker> for boot-only config I'd like to add a new server property user_data_config, which would also allow this relationship config<-server
20:44:33 <zaneb> that's not dissimilar for how volumes work now
20:44:40 <zaneb> s/for/to/
20:44:49 <stevebaker> yes, I suppose
20:45:30 <shardy> stevebaker: and user_data_config would take a ref to any type of SoftwareConfig resource?
20:45:44 <stevebaker> anyway, I'll code something up and append it to the bp/hot-software-config reviews
20:45:59 <stevebaker> shardy: correct. maybe it should take a list of refs
20:46:10 <shardy> stevebaker: +1 sounds good
20:46:47 <stevebaker> or a single ref, and its up to the author to aggregate using a multipart config resource (which I'm writing)
20:47:24 <shardy> stevebaker: That will get interesting for cloud-init configs, because only recent versions allow sane merging of multiple cloud-config sections
20:47:40 <shardy> I imagine the list of refs will be similarly challenging with other tools
20:47:47 <zaneb> do we care about non-recent versions?
20:47:49 <stevebaker> shardy: its up to the template author to know what their image's cloud-init can do
20:47:49 <shardy> but good if we can make it work
20:48:16 <stevebaker> I don't understand how to specify merge strategies yet though
20:48:23 <shardy> zaneb: They won't work with multiple configs in a sensible way, you only get the most recent cloud-config mime part
20:48:23 <SpamapS> zaneb: we care less after April which is when 0.7 will ship in an Ubuntu LTS
20:48:42 <sdake2> zaneb we care if we care about ubuntu 12.04 guests in heat
20:48:54 <SpamapS> very temporary problem
20:49:02 <SpamapS> also it sounds like it will work, just not well, right?
20:49:06 <shardy> SpamapS: Ok cool, that's good to know
20:49:10 <stevebaker> correct
20:49:18 <SpamapS> as in, 12.04 users will just be limitted to 1
20:49:22 <zaneb> I think by the time this is released and in widespread use, it will no longer be an issue
20:49:38 <shardy> we have a new enough version in Fedora/RHEL now so we should be good if Ubuntu will soon ship with >= 0.7.2
20:49:50 <sdake2> SpamapS won't people still use 12.04 ubuntu after the next lts ships?
20:49:59 <stevebaker> #topic Instance users
20:50:03 <stevebaker> 10 minutes
20:50:20 <shardy> So I wanted to ask for review/feedback on this wiki page:
20:50:34 <shardy> https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers
20:50:36 <stevebaker> #link https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers
20:51:02 <shardy> I've got some feedback from ayoung and am currently thinking we go with something similar to option (2)
20:51:13 <shardy> stevebaker: Did you have an alternative idea to add?
20:51:32 <ayoung> shardy, I owe you more feedback...been tilting at other windmills
20:51:51 <ayoung> X509 is option 2, though
20:52:00 <shardy> basically I'd like to get everyone's suggestions dumped into the wiki, then I'll start a ML thread so we can discuss if needed and agree what will be implemented
20:52:11 <shardy> ayoung: In the wiki, it's option 4 ;)
20:52:13 <ayoung> is just a better way to authenticate  per instance users
20:52:29 <shardy> ayoung: If you can add something to that section, describing how it would work, and status in keystone, that would be great
20:52:45 <zaneb> oooh, I like the domain separation idea
20:53:05 <shardy> zaneb: Yeah, it's also a fairly incremental step from what we do now
20:53:15 <stevebaker> I do intend to add an option 5, which is:
20:53:17 <stevebaker> - store a fake keypair with the resource
20:53:19 <stevebaker> - use keystoneclient instead of ec2token API to validate signed requests
20:53:21 <stevebaker> - write some middleware and an engine rpc call to create a real token from a request signed with the fake keypair
20:53:27 <shardy> we just create the instance_users in heat_keystoneclient in a different domain to the one we do now
20:53:27 <zaneb> I mean, they're all filthy hacks to work around the shortcomings of keystone
20:53:35 <stevebaker> but 2. and 4. show promise too
20:53:45 <ayoung> shardy, I think it is "in addition to" not something you can do by default.  More like "If a cloud deployment supports x509, then it is the preferred method of authenticating the per instance users"
20:54:14 <ayoung> zaneb, our entire profession is built on a foundation of filthy hacks
20:54:16 <shardy> ayoung: Ok, but we can still start with option (2) using randomly generated passwords right?
20:54:17 <stevebaker> ayoung: are there any plans for a native equivalent of request signing?
20:54:23 <ayoung> anyone who says differently is selling something
20:54:29 <shardy> then potentially add x509 support later?
20:54:30 <zaneb> ayoung: quite right :)
20:54:44 <shardy> stevebaker: There has been something for oauth signed requests posted
20:54:49 <ayoung> stevebaker, with what shall you sign it dear liza dear liza
20:54:53 <zaneb> but domain separation seems like a pretty tidy filthy hack
20:55:02 <shardy> but the oauth patches seem to be stalled, or at least taking many months to review
20:55:07 <ayoung> zaneb, its a bucket, dear henry
20:56:10 <shardy> Ok, so nobody's super-opposed to the domain separation approach then?
20:56:23 <ayoung> shardy, I endorse it
20:56:29 <shardy> If so that's good, as it seems the most viable approach to me right now
20:56:36 <shardy> ayoung: you would, it was your idea ;)
20:56:49 <ayoung> shhh
20:56:49 <stevebaker> its worth a crack. I'll also enter option 5. Any thoughts on what I said above?
20:56:55 <ayoung> that makes it harder to sell
20:57:28 <shardy> stevebaker: Can you add it to the wiki with more detail, but basically it sounds more complex and has more missing bits to implement
20:57:38 <stevebaker> *action <redacted> to propose solution <redacted>
20:58:08 <stevebaker> #topic open discussion
20:58:15 <ayoung> so option one is based on a flase assumption:  you can';t dpo a trust without first authetnicating
20:58:17 <stevebaker> 100 seconds
20:58:32 <zaneb> shardy: I don't know about a project-per-stack. Suspect we want project-per-project
20:58:35 <ayoung> so really, the only options there are 2 and 3
20:58:44 <ayoung> option 4 is really option 2
20:59:02 <shardy> ayoung: You can create an ec2-keypair with a trust token, which can be used to authenticate with our API via ec2tokens
20:59:02 <ayoung> and option 2 works today, option 3 does not
20:59:39 <ayoung> shardy, I think we've established the problems with ec2 keypairs, though, right?
20:59:50 <shardy> ayoung: but I agree, option 2 seems the only one which should work without abusing trusts and without adding lots of new stuff e.g middleware
20:59:55 <shardy> ayoung: haha, yeah..
21:00:05 <stevebaker> #endmeeting