19:59:39 <stevebaker> #startmeeting heat
19:59:40 <openstack> Meeting started Wed Oct 30 19:59:39 2013 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:59:43 <openstack> The meeting name has been set to 'heat'
20:00:01 <stevebaker> #topic rollcall
20:00:02 <asalkeld> o/
20:00:04 <shardy> o/
20:00:05 <spzala> Hi
20:00:16 <jpeeler> hi
20:00:19 <jasond> o/
20:00:22 <lifeless> :q
20:00:26 <MikeSpreitzer> lurking briefly
20:00:31 <tspatzier> hi all
20:00:40 <vijendar> hi
20:01:16 <stevebaker> no actions from last week, only one agenda item, this might be a short one
20:01:18 <stevebaker> https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:01:19 <zaneb> o/
20:01:29 <kebray> hello
20:01:31 <stevebaker> #topic Summit preperation
20:01:39 <randallburt> o/
20:01:41 <stevebaker> speling?
20:02:02 <topol> o/
20:02:02 <zaneb> preparation
20:02:12 <m4dcoder> o/
20:02:34 <stevebaker> so this IBM preso which was on 5:20 thurs is now 3:10 friday http://openstacksummitnovember2013.sched.org/event/d021c726f6fbe4d1fc7ade0a72a6ae2a#.UnFlvnUW3qU
20:02:43 <lakshminarayanan> yes
20:02:49 <stevebaker> so now we can all go and heckle ;)
20:03:04 <tspatzier> looking forward to see you all there :-)
20:03:10 <lakshminarayanan> We would love to have you all and your questions
20:03:31 <stevebaker> design schedule has been published http://icehousedesignsummit.sched.org/overview/type/heat
20:03:32 <sdake_> o/
20:03:59 <zaneb> ugh, now it's up against the OpenShift presentation
20:04:18 <timductive> o/
20:04:20 <stevebaker> From now on we can be considering what to talk about in our placeholder session http://icehousedesignsummit.sched.org/event/4ef1f2f4238851d490f0e14c58423189#.UnFmGXUW3qU
20:04:21 <topol> can I be the guy in the back of the room saying just finalize this stuff so we can go grow the heat/HOT ecosystem? :-)
20:04:31 <zaneb> that's unfortunate because stuff we learn at the IBM one is going to be directly useful for the OpenShift one
20:04:47 <randallburt> walkie talkies?
20:05:47 <stevebaker> zaneb: that is unfortunate, but not as bad as a clashing design session
20:05:55 <zaneb> true
20:06:28 <stevebaker> anything else summit related that anybody wants to raise?
20:06:48 <asalkeld> if we have time user-loging
20:06:51 <zaneb> but there's like two talks about Heat in the whole (non-Design) Summit... and they're on at the same time
20:07:08 <spzala> since heat design sessions are not before Thursday, what's the best way to find heat team - find them? twitter?
20:07:32 <zaneb> spzala: yeah, I was going to bring that up
20:07:45 <zaneb> how about we all meet on Tuesday at some point?
20:07:46 <spzala> zaneb: cool
20:08:03 <lakshminarayanan> +1 to meet on tues
20:08:10 <zaneb> a lot of the important discussions happen on the sidelines
20:08:19 <zaneb> no point waiting until thursday
20:08:33 <kebray> anyone up for a sideline conversation with Solum folks?  I may be able to set that up.
20:08:34 <tspatzier> and at the parties in the evening ;-)
20:08:46 <tspatzier> +1 kebray
20:08:48 <stevebaker> lakshminarayanan, zaneb, if you want to negotiate another schedule change then you can email pete@FNTECH.COM, cc lauren@openstack.org
20:08:57 <zaneb> kebray: +1
20:09:20 <spzala> kebray: yes, I am up
20:09:32 <lakshminarayanan> stevebaker: thanks for suggestion. I think we are open for another change.
20:09:33 <kebray> k. I'll try to set something up.
20:09:48 <lakshminarayanan> zaneb: do you have another time slot in mind?
20:09:54 <stevebaker> lakshminarayanan: OK, I'll leave it to you
20:09:55 <asalkeld> yeah, kebray I am interested too
20:10:17 <stevebaker> lakshminarayanan: it looks like there are other slots on friday with only 3 presentations
20:10:43 <lakshminarayanan> kebray: I am also interested in meeting with Solum folks.
20:10:46 <lakshminarayanan> kebray +1
20:10:50 <zaneb> lakshminarayanan: no particular one, so long as it doesn't clash with the design summit sessions
20:10:51 <stevebaker> lakshminarayanan: 11:50, 17:00
20:10:57 <shardy> Doh, I've just noticed Healing and Convergence clashes with a Tempest session prompted by a patch I submitted and was planning to attend :(
20:11:29 <tspatzier> so if possible, I would like the earlier slot and not let it slip towards the end of the summit
20:11:35 <sdake> need better scheduling system imo :)
20:11:46 <asalkeld> need time machine
20:11:56 <lakshminarayanan> stevebaker tsaptzier: I agree 11:50 would be better
20:12:04 <stevebaker> shardy: I could swap convergence with something else
20:12:16 <asalkeld> tspatzier, friday == everyone sleeping
20:12:24 <zaneb> lakshminarayanan: I'll leave it to up you, but 11:50 sounds good to me
20:12:54 <stevebaker> shardy: maybe swap convergence with abandon/adopt at 2:40
20:13:02 <shardy> stevebaker: Ideally I'd rather not miss any Heat sessions, I'll speak to the Tempest PTL and see if there's any chance of them swapping their sessions around
20:13:05 <tspatzier> asalkeld, then we have to be as entertaining as possible to keep people awake. Maybe we threaten to ask the audience questions.
20:14:07 * radix is here finally
20:14:09 <lakshminarayanan> zaneb: I will check with others and will email
20:14:30 <zaneb> lakshminarayanan: thanks, much appreciated :)
20:14:38 <stevebaker> shardy: tempest has lots of slots on wed and fri, chances are they can swap
20:15:12 <shardy> stevebaker: yeah was thinking it may be possible as there's plenty of slots which don't overlap with Heat
20:15:39 <stevebaker> when should we meet on tuesday? lunch?
20:15:41 <tspatzier> lakshminarayanan, 11:50 would be ok with me. So will you email pete and lauren?
20:16:34 <zaneb> stevebaker: either at lunch or right after the IBM keynote imo
20:16:40 <lakshminarayanan> tsaptzier: yes I can email pete and lauren.
20:16:53 <randallburt> lunch sounds good
20:16:56 <zaneb> stevebaker: but a working lunch sounds
20:16:58 <zaneb> good
20:17:06 <randallburt> agreed
20:17:23 <kebray> should I invite the solum folks to lunch too, or should that be a separate meet-and-greet?
20:17:26 <stevebaker> ok, lets announce on the ML and #heat on the day
20:17:33 <randallburt> kebray:  separate, IMO
20:18:07 <stevebaker> #topic open discussion
20:18:22 <shardy> So the 63 character thing..
20:18:25 <zaneb> maybe we can come up with a plan at lunch on Tuesday for more sideline meetings throughout the week
20:18:31 <stevebaker> I don't have anything that can't continue on the ML or IRL
20:18:58 <shardy> Several folks have complained about the hard-limit, do folks have any strong opinions about me proposing an alternative, one of:
20:18:59 <sdake> while your at it beat zookeeper into submission for me pls :)
20:19:00 <asalkeld> zaneb, very little on tuesday
20:19:38 <shardy> squash the names into something semi-readable, or just name all the instances heat-<resource short random id>
20:19:39 <stevebaker> shardy: we just need to do the rest of the fix, which shortens any arbitrary physical name to be under the limit of that resource type
20:19:46 <asalkeld> so +1 to, just make tuesday an unoffical heat day
20:20:22 <shardy> stevebaker: Yeah, thats what I was planning, but an even easier approach is just to use the existing resource unique/random ID and a fixed prefix
20:21:05 <zaneb> shardy: how about if we just shorten the names of nested stacks
20:21:15 <zaneb> shardy: by removing the parent stack name, for example
20:21:33 <shardy> zaneb: humm, yup that's not a bad idea
20:21:40 <stevebaker> shardy: fixed prefix looses a lot of useful context, we could do better than that - it would still be easy-ish
20:22:12 <zaneb> it's multiple levels of nested stack that really drive things out of control
20:22:59 <shardy> I'll raise a bug and take a look tomorrow, unless anyone beats me to it overnight ;)
20:23:14 <stevebaker> zaneb: I was thinking of a shortening algorithm which does something like
20:23:17 <stevebaker> mystack-theresource-anestedstack-fooserver-kjho978as
20:23:19 <stevebaker> shortens to:
20:23:21 <stevebaker> my-th-an-fo-kjho978as
20:23:45 <stevebaker> shardy: I'm fairly certain a bug already exists
20:23:56 <zaneb> sounds like a recipe for accidental profanity :D
20:24:08 <shardy> Just dropping everything except the immediately owning stack will be much more readable
20:24:18 <shardy> stevebaker: didn't we close that as part of the Havana release?
20:24:19 <stevebaker> zaneb: challenge accepted!
20:24:36 <stevebaker> shardy: I think another was raised for this issue
20:24:49 <shardy> stevebaker: Ah, k, must've missed that
20:25:03 <shardy> been distracted beating keystone stuff into shape
20:25:43 <kebray> I have one topic for open discussion:  template catalog functionality, https://blueprints.launchpad.net/heat/+spec/heat-template-repo ...
20:26:11 <kebray> I'd like to offer to staff resources to implement this for Icehouse.. if, the community will have it in the Heat source tree.
20:26:22 <stevebaker> shardy: even with dropping parent stacks, it is not hard to exceed 63 with stackname + resourcename + random. A shortening strategy could work with any physical name
20:26:48 <asalkeld> kebray, hasn't marono claimed that now;)
20:27:16 <kebray> asalkeld:  They claimed the world, IMO, in that statement.  PaaS and SaaS and market place.
20:27:16 <asalkeld> murano
20:27:38 <asalkeld> someone is getting excited
20:27:44 <stevebaker> kebray: lets talk about this in person. It might best be done with a horizon UI over solum
20:27:49 <asalkeld> kebray, +1
20:28:17 <asalkeld> kebray, I know melbourne university what that too
20:28:20 <randallburt> lol, glad solum is the new dumping ground
20:28:29 <kebray> stevebaker happy to talk in person, or by whatever means.  I've thought a lot about this, and have reasons I believe Horizon should consume the catalog service via an API instead of implement it.
20:28:34 <stevebaker> takes the heat off us ;)
20:28:40 <kebray> I want to reuse that service across non Horizon UIs.
20:29:12 <kebray> ... would certainly build it so Horizon can consume it though :-)
20:29:14 <randallburt> stevebaker:  indeed
20:29:18 <tspatzier> kebray, I think that would also be a good place for provider templates to live
20:29:23 <zaneb> kebray: why not just bung them in swift? what else is there for the service to do?
20:29:25 <asalkeld> I think we need an independent catalog/sharing system
20:29:40 <stevebaker> kebray: the thing is, a template shouldn't go into a catalog unless it is first managed with full revision control (git) and validated that it actually works (jenkins)
20:29:54 <shardy> kebray: can you summarise, what will this template store actually give folks, which they can't already get with git (plus some UI integration on top)
20:30:09 <zaneb> shardy: ++
20:30:18 <kebray> zaneb:  the service provides a service provider sanitized list of deployable template options.
20:30:25 <randallburt> shardy:  a thin layer over that strategy that is consistent for everyone
20:30:43 <randallburt> well, thin-ish ;)
20:30:50 <zaneb> kebray: wait, the *service provider* supplies the templates?
20:30:51 <stevebaker> kebray: not to mention that we would often want custom golden images associated with a template in the catalog
20:31:17 <kebray> yeah, pretty thin... the backends could be plug able (swift, git, whatever).  But, it's a consistent way for folks to get a list of stored templates, and then tell Heat go deploy this one from the list.
20:31:50 <kebray> stevebaker that's another use case I hadn't thought of, but yes, something like golden image associations could be implemented in a catalog.
20:31:53 <asalkeld> it would be good to have a global instance global too
20:32:08 <asalkeld> (a replacement to heat-templates)
20:32:12 <kebray> I view the catalog as sort of a "Glance for HOT" as randallburt described it.
20:32:24 <shardy> well AWS just stick them on a web-site, I don't see why static service provider sanitised examples can't be provided that way, then users get to manipulate stuff through git
20:32:25 <randallburt> asalkeld:  +1
20:32:42 <shardy> can't we just enable python-heatclient to list stuff from the heat-templates repo?
20:32:47 <tspatzier> I like the idea. And if this is a service that comes with openstack, it avoids having to setup up a repo on your own. Just using a git on the internet can be a problem behind firewalls ...
20:32:56 <shardy> heat template-examples-list
20:33:18 <asalkeld> shardy, it lets people share
20:33:40 <randallburt> shardy:  assuming we do the work to make sure those templates are up-to-date and working
20:33:42 <asalkeld> so it can grow in a community
20:33:55 <kebray> shardy, we could go that route, and build our "website catalog service" independent of Heat.   But, I think a standard way for Horizon, private OpenStack cloud distributions (with custom UIs), and public cloud UIs to consume catalog would be nice.
20:33:55 <asalkeld> and all those warm fuzzy terms
20:34:06 <stevebaker> unless the catalog is integrated with CI, in many cases what is being shared will be of low quality
20:34:12 <zaneb> asalkeld: what you're talking about is not an OpenStack service though, it's a website
20:34:14 <shardy> randallburt: well fragmenting it so every service provider maintains their own template catalog is not going to help
20:34:19 <tspatzier> shardy, I know of many private cloud deployments where there is no internet access, so heat-templates would not work
20:34:39 <asalkeld> zaneb, horizon?
20:34:44 <shardy> tspatzier: having a tarball release, or local mirror/clone is trivial
20:34:59 <tspatzier> shardy, yes, that would be an option
20:35:08 <randallburt> shardy:  I don't disagree, but having the service available as both a public repo as well as something anyone else can set up and manage their own repo aren't mutually exclusive
20:35:30 <shardy> randallburt: git+github already enable all of that
20:35:36 <zaneb> asalkeld: the number of people you can share with in Horizon is limited, at best
20:35:50 <shardy> the only thing missing is the ui integration
20:35:50 <kebray> I'm not so worried about the list of sanitized templates at the moment as I am the interface (service) to store and list them.. Each service provider or OpenStack operator may want to create their own sanitized list.  Not everyone who uses Heat in an OpenStack installation should have to set up a git repo and point their catalog at that.
20:36:48 <zaneb> kebray: so this is about having a list to pick from in Horizon?
20:36:57 <asalkeld> zaneb, ok well I think kebray is after something different
20:37:04 <shardy> kebray: so everyone just has to point at some other service instead?
20:37:06 <kebray> zaneb any UI, not just Horizon.
20:38:09 <stevebaker> shall we continue this discussion in 5 days?
20:38:10 <kebray> If Heat, as a service, provided a way for the Heat administrator to configure where (the backend) that sanitized templates come from, Horizon (or any other non Horizon UI they are using on top of OpenStack) could just consume the standard service API call to get the sanitized template list.
20:38:16 <kebray> stevebaker sure.
20:38:31 <kebray> Just wanted to get people thinking more about it :-)
20:38:32 <randallburt> preferably over drinks
20:38:32 <zaneb> kebray: so, I would be very -2 on having this in the Heat *project*. But I'm open-minded about having it in the Orchestration *program*, though I currently remain unconvinced
20:39:12 <kebray> zaneb agreed it should not be a required operational API of Heat... but, I do think it belongs within the Heat source tree, kind of like AutoScale, as an optional API endpoint that can be enabled.
20:39:20 <stevebaker> anything else before the endmeeting?
20:39:31 <shardy> kebray: When we meet, I'd very much like to hear specific on what this gives us that having e.g a configurable git repo won't
20:39:39 <shardy> specifics
20:39:41 <kebray> shardy sure.
20:39:45 <zaneb> kebray: I would vote for separate repo, it's a completely different service with no shared code
20:39:58 <randallburt> zaneb: def agree there.
20:40:02 <shardy> zaneb: +1
20:40:03 <kebray> zaneb k, your vote is recorded.
20:40:17 <zaneb> lol :)
20:40:32 <asalkeld> so we all meeting up on tuesday?
20:40:41 <zaneb> asalkeld: yes, at lunch
20:40:43 <stevebaker> provisionally at lunch
20:40:50 <asalkeld> o
20:40:58 <kebray> Tuesday sounds great.
20:41:04 <stevebaker> I'll order some bouncers to keep a big table clear
20:41:06 <asalkeld> there is nothing much in the moring
20:41:42 <stevebaker> ending meeting in 3...
20:41:43 <zaneb> asalkeld: keynotes, TOSCA session
20:41:53 <stevebaker> 2..
20:42:03 <asalkeld> ok, was only looking at dev sessions
20:42:08 <stevebaker> 1.
20:42:15 <stevebaker> #endmeeting