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