20:00:38 <stevebaker> #startmeeting heat
20:00:39 <openstack> Meeting started Wed Jul 10 20:00:38 2013 UTC.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:43 <openstack> The meeting name has been set to 'heat'
20:00:53 <stevebaker> #topic rollcall
20:00:59 <randallburt> hi
20:01:05 <asalkeld> hi
20:01:31 <stevebaker> shardy, jpeeler on pto
20:01:31 <timductive> Hi
20:01:39 <therve> Hi!
20:01:42 <tspatzier> Hi
20:01:45 <bgorski> Hi
20:01:56 <sdake> o/
20:02:05 <andrew_plunk> hey!
20:02:08 <zaneb> o/
20:02:19 <stevebaker> #topic review last weeks actions
20:02:33 <stevebaker> shardy to organize docs sprint during h3
20:02:34 <fsargent> Hi!
20:02:37 <stevebaker> he not here
20:02:41 <kebray> hello
20:02:45 <jasond> o/
20:02:50 <stevebaker> kebray to put on RS backlog testing of RS Database Resource against generic Trove, and consider rename/refactoring of provider to use Trove for naming.
20:02:53 <m4dcoder> o/
20:03:20 <SpamapS> o/
20:03:22 <kebray> stevebaker  Work has begun on that backlog item.
20:03:30 <asalkeld> cool
20:03:40 <kebray> So, WIP.
20:03:54 <stevebaker> ...and finally, SpamapS to reply to m4dcoder's ML question
20:04:40 <SpamapS> done
20:04:49 <stevebaker> sweet
20:05:01 <stevebaker> #topic h2 bug/blueprint defer or deploy decisions
20:05:10 <stevebaker> https://launchpad.net/heat/+milestone/havana-2
20:05:16 <stevebaker> #link https://launchpad.net/heat/+milestone/havana-2
20:05:35 <stevebaker> we have 4 blueprints in-flight
20:06:00 <m4dcoder> yes, thank you SpamapS for replying.  but the as-update-policy spec points to the AWS description.  so not sure what the spec for heat should be.
20:06:10 <therve> 1 week to go
20:06:16 <stevebaker> EOD Tuesday is when milestone-proposed will be branched
20:06:38 <SpamapS> m4dcoder: we can discuss later in the meeting :)
20:06:50 <therve> Looks tight for 2 of them
20:07:01 <stevebaker> SpamapS blueprint native-in-instance-tools is odd, by some definitions it is done?
20:07:42 <stevebaker> by others it is not associated with the heat release at all
20:08:03 <SpamapS> stevebaker: 66%.. no cfn-signal replacement yet
20:08:14 <stevebaker> ok, i'll defer
20:08:19 <kebray> randallburt mentioned in a huddle that he would probably have his BP code complete, but not sure that it will have had time to be reviewed by community and merge accepted by Tuesday.
20:08:33 <SpamapS> stevebaker: it isn't really tied ot the release anyway, and there's the issue of native API calls as well. :)
20:08:48 <randallburt> kebray:  I got no worries. the bulk of the work has been done by asalkeld.
20:08:49 <therve> The review queue filled up pretty quickly :/
20:08:58 <SpamapS> stevebaker: what I have still uses cfn
20:09:01 <kebray> randallburt excellent!
20:09:13 <randallburt> I have one more review to submit and that should be done today/first thing tomorrow.
20:09:26 <stevebaker> if you think it has a chance getting in, then leave it in h-2 for now
20:09:53 <stevebaker> sdake: how about gzip-userdata?
20:11:09 <sdake_> ppl complaining about feature
20:11:25 <sdake_> gold plating test case atm ;)
20:11:30 <asalkeld> it's on review
20:12:04 <sdake_> some folks think there is no value in compressing userdata
20:12:20 * randallburt looks about innocently
20:12:44 <stevebaker> ok, can we all keep on top of reviews related to any bug, and those blueprints?
20:12:48 <sdake_> from a technical perspective, the test cases are a bit painful because part_handler.py is not a class so that needs to be sorted out
20:12:50 <zaneb> sounds like a good feature to me, why wouldn't you want to compress it?
20:13:28 <SpamapS> "why would you?"
20:13:29 <asalkeld> https://review.openstack.org/#/c/34476/
20:13:38 <sdake_> zaneb I think there is some confusion that that blueprint leads to a different blueprint of loading the instance tools into the metadata
20:13:48 <sdake_> even though they are orthogonal imo
20:14:06 <sdake_> we compress, we can handle more complex blobs
20:14:21 <SpamapS> The answers to "why would you?" are valid.. though I'm still dubious at the approach.. userdata is "provide enough to get the instance working" not "upload tools"
20:14:38 <sdake_> that is a separate blueprint spamaps
20:14:44 <sdake_> not part of this blueprint
20:15:01 <asalkeld> sdake_ maybe remove that from the commit message
20:15:03 <randallburt> I admit to that assumption as well. I don't have issue on the face of it, its just low-return val imo based on how much compression we get vs. real-world injection limits
20:15:04 <sdake_> when it is submitted for review folks can complain on that review :)
20:15:05 <SpamapS> Right but the extra complexity of compression demands a reason.
20:15:13 <sdake_> asalkeld yes i already have in my local repo ;)
20:15:48 <sdake_> the reason is simple - we can handle 10x as much metadata with compression as without
20:16:28 <stevebaker> seems useful
20:16:44 <SpamapS> sdake_: with a really big door on my house, I can handle 10x more elephants than I can right now.. but.. what are the elephants for?
20:17:01 <sdake_> are they pink? :)
20:17:03 <zaneb> lol
20:17:06 <randallburt> lol
20:17:27 <sdake_> atm some of our larger templates are coming close to bumping against the userdata limits
20:17:29 <zaneb> I can easily imagine wanting to pass e.g. a whole puppet manifest
20:17:31 <SpamapS> My point is, if it simplifies something, +2. If it complicates in support of something else that is also complicating.. -1.
20:17:36 <zaneb> and 16k is a really small limit
20:17:46 <stevebaker> shall we move this discussion to the review?
20:17:53 <SpamapS> sdake_: why would template size increase userdata size?
20:17:54 <sdake_> agree
20:18:04 <zaneb> yah, sorry, my bad for dragging this off topic ;)
20:18:20 <SpamapS> How is it off topic?
20:18:27 <SpamapS> h2 blueprints is the topic.. :p
20:18:46 <zaneb> "h2 bug/blueprint defer or deploy decisions"
20:18:50 <SpamapS> and we gather here to have more bandwidth to discuss issues.. :)
20:18:58 <asalkeld> well we could just bump to h3
20:19:09 <asalkeld> and think about it a bit more
20:19:13 <asalkeld> we have the code
20:19:19 <asalkeld> it's ready to go
20:19:54 <sdake_> its blocking native nova instance
20:20:02 <asalkeld> not really
20:20:02 <sdake_> i dont want to think about it more
20:20:10 <SpamapS> wha?
20:20:16 <stevebaker> is it?
20:20:20 <SpamapS> blocking native nova?
20:20:29 <sdake_> thenative nova blueprint
20:20:33 <sdake_> its all tied up in the same code base
20:20:44 * SpamapS steps back
20:21:00 <SpamapS> clearly there is more going on here than I have context for. Lets indeed take this up outside the meeting. :)
20:21:08 <sdake_> sounds good :)
20:21:25 <stevebaker> #topic h3 blueprint milestone and priority
20:21:42 <stevebaker> #link https://launchpad.net/heat/+milestone/havana-3
20:21:58 <stevebaker> 26 blueprints! holymoly!
20:22:26 <asalkeld> well the ceilometer one is nearly done
20:22:34 <stevebaker> so there has been a change in how blueprints are scheduled and prioritised
20:22:45 <SpamapS> Yeah I think the "abstract away aws" one can drop off H3. I know I am not going to get to that.
20:22:56 <stevebaker> From now on we can ignore the Series goal, a script handles that
20:23:09 <sdake_> SpamapS I think I may pick that one up
20:23:16 <SpamapS> sdake_: sweet!
20:23:40 <stevebaker> The author/assignee should choose a Milestone target that they think can be achieved
20:23:59 <stevebaker> so y'all and all-y'all should do that for your assigned blueprints
20:24:22 <asalkeld> stevebaker, moved to texas?
20:24:26 <SpamapS> Also https://bugs.launchpad.net/heat/+bug/1160052 is, IMO, a lot higher priority than "Low" .. as without it any stack creation or update that has any hiccups becomes a dead stack. :-/
20:24:33 <uvirtbot> Launchpad bug 1160052 in heat "Need a way to retry creation" [Low,Triaged]
20:24:37 <SpamapS> I do intend to work on it and get something ready for H3
20:24:38 <zaneb> y'all *and* all-y'all?
20:24:41 <stevebaker> and finally, heat-core need to decide how much they want each blueprint by setting the priority
20:24:55 <stevebaker> zaneb: and youse
20:26:26 <sdake_> we have some unowned blueprints
20:26:31 <stevebaker> SpamapS: I guess any core member can set any priority they think appropriate
20:26:56 <kebray> SpamapS: Abstract away AWS namespaces out of heat is important to me… quite possible I might be able to put someone on that for H3.
20:27:02 <therve> I can take the instance resize one
20:27:30 <sdake_> kebray i've assingned it to myself so point them at me - can work together on that
20:27:41 <stevebaker> actually when broken down by assignee, we could get a decent amount of those done
20:28:00 <kebray> sdake_  no worries.. and, if you crank it out, all the better ;-)
20:28:06 <SpamapS> kebray: sweet
20:28:19 <randallburt> wasn't shardy already working on snapshotting?
20:28:24 <asalkeld> yip
20:28:36 <asalkeld> (mostly done by the looks of it)
20:28:46 <randallburt> thought so, that was another unassigned one
20:30:01 <asalkeld> we don't have documentation as a bp
20:30:21 <asalkeld> I guess we will just have to squeeze that in
20:30:51 <stevebaker> #action asalkeld, stevebaker to raise some documentation blueprints
20:31:06 <randallburt> kebray, asalkeld: we also want to pitch in with https://blueprints.launchpad.net/heat/+spec/multiple-engines if you need/want it.
20:31:16 <SpamapS> randallburt: how is open-api-dsl doing?
20:31:20 <asalkeld> ok cool
20:31:31 <SpamapS> oh yes multiple-engines is Critical
20:31:41 <randallburt> SpamapS:  my nefarious plan is to declare victory with the progress we make by h3.
20:32:19 <asalkeld> really?
20:32:25 <stevebaker> anything else h-3 before we move to open discussion?
20:32:26 <SpamapS> randallburt: you fiend
20:32:34 <randallburt> IMO, we've lain the groundwork and are at a good place for progress. I'd like to move forward by taking a page from zaneb's book and propose very specific changes moving forward
20:32:52 <asalkeld> yip
20:32:57 <sdake_> randallburt would like to see an autoscaling example out of that work
20:33:12 <sdake_> it is missing from the example review
20:33:18 <sdake_> imo seems critical to see how that fits in
20:33:31 <randallburt> sdake_:  roger that. though IMO, its a resource like any other.
20:33:31 <zaneb> I should write a book
20:33:53 <sdake_> writing a book is overrated
20:33:53 <stevebaker> #topic Open discussion
20:34:06 <SpamapS> m4dcoder: you wanted to talk about UpdatePolicy ?
20:34:10 <m4dcoder> yes
20:34:12 <stevebaker> so I've got some local tempest tests which will have to pass before h-2 can go out the door, including an autoscaling one https://review.openstack.org/#/c/36367/
20:34:52 <m4dcoder> what's as-update-policy h3 priority for folks here?
20:35:15 <m4dcoder> specs and ML reply is not clear what i should implement for it
20:35:34 <SpamapS> m4dcoder: I don't really care about AWS compatibility. I do intend to implement rolling updates, though slightly different than AWS's and slightly different than the spec I originally wrote.
20:36:07 <m4dcoder> if you can clarify that, i can help with the implementation.
20:36:16 <kebray> Open discussion topic:  Heat mission statement. The wiki seems outdated, and it seems we need one for the TC.
20:36:29 <SpamapS> I'd like to be able to have stack updates move forward using a waitcondition as feedback for whether to wait/go forward/rollback.
20:36:38 <stevebaker> kebray: +1
20:36:38 <SpamapS> m4dcoder: I will fix up the spec.
20:37:06 <kebray> TC request:  http://osdir.com/ml/openstack-cloud-computing/2013-07/msg00051.html
20:37:15 <m4dcoder> SpamapS: thanks!  should we put focus on it for h3?  if not, i can work on other higher priority bp/bugs.
20:37:31 <stevebaker> #action heat-core to write a mission statement
20:37:56 <SpamapS> m4dcoder: rolling-updates is targetted at h3
20:38:08 <zaneb> World Domination
20:38:22 <asalkeld> kebray, we just need to clean the aws out
20:38:23 <zaneb> done.
20:38:24 <stevebaker> do all the things
20:38:36 <mrodden> viagra for your private cloud
20:38:36 <randallburt> talk about scope creep
20:38:49 <mrodden> (heat makes it rise right...)
20:39:03 <m4dcoder> SpamapS: got it. if you can just put some outlines around your thoughts, i can pitch in.
20:39:34 <SpamapS> m4dcoder: yeah, there's a spec attached to that bp, but it is way out of date.
20:39:36 <asalkeld> stevebaker, maybe you can take an action to send that email out
20:40:15 <stevebaker> ok, I'll write a straw-mission to start
20:40:29 <stevebaker> #action stevebaker to start mission discussion on list
20:41:14 <therve> I was wondering about the neutron renaming
20:41:18 <therve> How are we going to handle that?
20:41:18 <m4dcoder> SpamapS: you mean https://wiki.openstack.org/wiki/Heat/Blueprints/RollingUpdates.  should we collapse the as-update-policy bp with the rolling updates bp into one?
20:41:29 <sdake> therve there is already a review up for it
20:41:46 <therve> Oh I missed it
20:41:48 <sdake> i believe it is blocked on the client not being done yet
20:41:54 <SpamapS> m4dcoder: They are different things, but I think one should probably follow the other
20:42:37 <kebray> asalkeld: I can explain Heat's capabilities, I can also explain the why use Heat vs. talk direct to the infrastructure.  Once I get past all that, ppl get stuck on what capabilities will go in Heat vs. capabilities they need to build on top of Heat.  That's where mission statement will really help bring some clarity me thinks.
20:42:48 <stevebaker> i think there is a desire that we do the neutron rename before h-2
20:42:59 <therve> Ah yeah it's not verified, I filtered it out
20:43:34 <sdake> the patch looked correct - got my +2 - just depends on that update to the client
20:43:46 <therve> The current patch seems to be seriously backward incompatible
20:44:14 <asalkeld> isn't renaming a project backwards incompatible?
20:44:15 <stevebaker> can we register the quantum plugins as both ::Quantum and ::Neutron for now? breaking all the templates seems bad
20:44:31 <asalkeld> +1 stevebaker
20:44:31 <m4dcoder> SpamapS: i guess my original confusion was with the spec under the as-update-policy since i signed up for it.  so i'll review the rolling-updates bp and figure what to do.
20:44:34 <zaneb> +1 for backwards compatibility
20:45:08 <sdake> probably worth commenting on the review then if you feel we need backwards compat ;)
20:45:10 <therve> stevebaker, Yeah that sounds like a good step
20:45:12 <zaneb> just register them all twice with different names
20:45:24 <therve> sdake, This was mentioned
20:45:32 <sdake> oh, haven't seen the review lately
20:45:52 <sdake> been on vac ation :)_
20:45:52 <stevebaker> hey, I need to go, shall we endmeeting?
20:45:58 <bgorski> I have a question about Heat support for multi region. I am working on it and I will write a blueprint about it in near future. Anybody is working on or thinking about it also?
20:46:07 <SpamapS> m4dcoder: yeah, lets talk in a bit in #heat
20:46:22 <m4dcoder> SpamapS: ok
20:46:34 <asalkeld> stevebaker, you can give us power then we can endmeeting
20:46:46 <sdake> #chair
20:46:50 <SpamapS> bgorski: I think the folks behind HOT have it as a long term goal to have Heat even be multi-cloud
20:48:00 <stevebaker> #chair asalkeld
20:48:01 <openstack> Current chairs: asalkeld stevebaker
20:48:09 <randallburt> SpamapS:  I'd say that's a fair statement
20:48:10 <stevebaker> sweet, later
20:48:13 <asalkeld> later
20:49:00 <therve> Having a multi region blueprint would be a good start
20:49:00 <andrew_plunk> bye
20:49:49 <asalkeld> if anyone has any thoughts about this bp: https://blueprints.launchpad.net/heat/+spec/user-visible-logs feel free to comment
20:49:57 <asalkeld> not very urgent
20:50:14 <asalkeld> just was having a think about it
20:51:03 <randallburt> asalkeld:  a couple of folks on my team would def be interested in that
20:51:13 <asalkeld> ok
20:51:13 <timductive> I would be interested in that
20:51:17 <kebray> asalkeld  I care about that one too.  doh, randallburt beat me.
20:51:25 <randallburt> we've kicked it around for Horizon stuff too
20:51:27 <kebray> Tim's the man!
20:51:34 <timductive> :)
20:51:35 <asalkeld> well it needs heap of discussion
20:51:37 <zaneb> asalkeld: doesn't using Marconi preclude your goal of having the same logs available to different users in different languages?
20:51:51 <asalkeld> zane not really
20:52:02 <asalkeld> as it is in a mechanical format
20:52:13 <asalkeld> that could be localized
20:52:22 <asalkeld> it is just a message
20:52:39 <zaneb> true, but where would the translations come from?
20:52:42 <randallburt> can Marconi localize at request time?
20:52:57 <randallburt> wouldn't we have to send i18n data along with every log message?
20:53:06 <asalkeld> I think you would need something on top of merconi
20:53:58 <asalkeld> heat stack-tail-messages
20:54:48 <zaneb> i-interesting
20:54:55 <asalkeld> :)
20:55:01 <asalkeld> yea nutty
20:55:28 <asalkeld> so yea, I should really post a discussion on the ml
20:55:49 <asalkeld> I don't see nova doing this
20:56:18 <asalkeld> but seems neat to see what is going on in your request
20:56:37 <therve> Debugging nova problems is not nice though
20:57:11 <asalkeld> and users don't seem to have access to rpc notifications
20:57:14 <zaneb> I'm a big fan of the idea
20:57:24 <asalkeld> 3 mins
20:58:12 <asalkeld> anything else
20:58:24 <asalkeld> #endmeeting