20:01:07 <sdake_> #startmeeting heat
20:01:08 <openstack> Meeting started Wed Mar 20 20:01:07 2013 UTC.  The chair is sdake_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:12 <openstack> The meeting name has been set to 'heat'
20:01:48 <sdake_> #topic rollcall
20:01:58 <sdake_> hidey ho
20:02:01 <stevebaker> o hai!
20:02:03 <asalkeld> o/
20:02:07 <shardy> o/
20:02:10 <jpeeler> hi
20:02:41 <sdake_> spamaps around?
20:03:21 <oubiwann> sdake_: I got an email from him a few minutes ago -- he should be on his way
20:03:27 <sdake_> #topic summit session review
20:03:38 <sdake_> thanks oubiwann
20:03:50 <SpamapS> sdake_: yes here
20:04:02 * SpamapS keeps getting distracted by his heat doing awesome things actually
20:04:04 <sdake_> we have 6 topics for summit for the Heat track
20:04:13 <sdake_> thats a good sign ;)
20:04:18 <sdake_> http://summit.openstack.org/cfp/topic/8
20:04:19 <asalkeld> I'll add one more
20:04:29 <sdake_> we have 7 slots so sounds like we are full :)
20:04:40 <sdake_> it is open until end of march
20:05:08 <sdake_> our schedule is 4/15 from 9:50 until 17:20
20:05:12 <asalkeld> (8 is nova)
20:05:34 <asalkeld> did you paste that link right?
20:05:36 <sdake_> asalkeld not on my ui ;)
20:05:59 <asalkeld> VM Ensembles (Group Scheduling) - API
20:06:15 <shardy> asalkeld: doesn't work for me either
20:06:17 <sdake_> odd
20:06:27 <sdake_> ok, well lets go through them individually then
20:06:40 <sdake_> #link http://summit.openstack.org/cfp/details/148
20:06:58 <asalkeld> oo, tosca
20:07:15 <sdake_> looking  for completeness, relevancy, whether should be bounced to a different track
20:07:17 <SpamapS> Interesting, who is "openiduser38" ?
20:07:25 <shardy> I saw the BP for this, seems to be driven by IBM?
20:07:52 <shardy> I'd like to know if they're proposing resources to implement, or just saying the feature would be nice
20:07:58 <sdake_> The blueprint dev is Thoms Spatzier
20:08:11 <shardy> I looked at the spec today and it's so complex I got a bit scared
20:08:37 <sdake_> looks like snafu with summit.openstack.org openid import
20:08:38 <SpamapS> Ok thats cool. HP is invested in TOSCA... so it might be something that HP folk would be interested in contributing to as well.
20:08:39 <asalkeld> well maybe he can explain it at summit
20:09:06 <sdake_> #action sdake to track down tosca openid session lead corrected in summit.openstack.org
20:09:14 <sdake_> here is my take
20:09:16 <sdake_> worth listening
20:09:22 <shardy> asalkeld: sure, I just wondered if there was IRC discussion I missed while on PTO
20:09:27 <sdake_> rather then passing judgment now
20:09:38 <sdake_> shardy new material
20:09:52 <sdake_> for those folks attending summit have a look at the tosca spec
20:10:15 <sdake_> Tosca could be interesting, or could be painful, we just don't know yet
20:10:15 <shardy> make sure you have a very large coffee ready ;)
20:10:25 <SpamapS> sdake_: right, I don't think it would be all that disruptive to HEAT as a whole too... so its worth hearing from people who are willing to step up to doing it.
20:10:28 <sdake_> ya don't forget your monster energy drink
20:10:47 <asalkeld> hah
20:11:20 <SpamapS> If anything, it would lay groundwork for pluggable parsers, which is probably a good thing.
20:11:29 <sdake_> so I'll sort out that problem and put this on short list of things since it seems like it could have big impact on heat for users and devs as well
20:11:30 <shardy> SpamapS: +1
20:11:46 <shardy> that may be a relatively big refactoring exercise tho
20:12:10 <sdake_> well i'd prefer not to rewrite heat to bring in tosca
20:12:18 <sdake_> these are all questions we can address at summit
20:12:26 <SpamapS> right, but it may be refactoring heat to allow others to plug in tosca/camp/juju/etc.
20:12:36 <asalkeld> yea
20:12:45 <sdake_> #link http://summit.openstack.org/cfp/details/136
20:13:15 <sdake_> appears relevant
20:13:52 <SpamapS> I would challenge the assumption that converting AWS::CloudFormation::Init to cloud-init would be less code than doing the few basic operations it is capable of.
20:13:56 <sdake_> asalkeld if you could put together some thoughts in etherpad.openstack.org that might get us rolling
20:14:07 <asalkeld> sure
20:14:21 <SpamapS> Would like to see some preliminary analysis of the features in cloud-init as compared to cfn-init's features
20:14:24 <sdake_> cool, well challenge it at the summit ;)
20:14:37 <shardy> asalkleld: interesting - atm cloud-init has no capability to read Cloudformation resource metadata AFAIK?
20:14:44 <shardy> so it can't replace cfn-hup?
20:14:54 <SpamapS> shardy: that would be relatively easy actually
20:15:03 <shardy> It can only read ec2 metadata IIRC
20:15:22 <SpamapS> the problem is how heavy handed it is, as it expects to be the initializer of the system, not the ongoing configurator.
20:15:41 <shardy> SpamapS: Sure, I'm just pointing out that the capability does not yet exist in upstream cloud-init, and we don't know if they would be willing to merge it
20:15:56 <sdake_> shardy the capability is in 0.7
20:16:06 <sdake_> but for cfn-hup, requires more investigation
20:16:10 <SpamapS> anyway, would like to see the analysis, I won't reject the session outright because I have not done the comparison.
20:16:20 <shardy> sdake_: what capability is in 0.7?
20:16:29 <sdake_> everything init needs
20:16:39 <shardy> It can't read resource metadata via DescribeStackResource
20:17:05 <asalkeld> shardy you can put what ever you want in the metadata (something cloud-init) can expect
20:17:14 <SpamapS> right that part is really, really easy (adding your own cloud data source).
20:17:48 <asalkeld> I think we are busy doing the session?
20:17:57 * sdake_ points at asalkeld
20:17:58 <shardy> asalkeld: but the instance metadata is not the same as the *resource* metadata, which is what cfn-hup reads, in both heat and CFN, but I suppose we can change that
20:18:14 <SpamapS> My personal preference is for cfn-init to stay as-is, and I think the effort to convert to cloud-init will be quite large compared with keeping it as-is. But again... worth somebody looking into it if they are interested in doing that conversion work. :)
20:18:45 <sdake_> #action asalkeld to write up convert cfn config into etherpad for further discussion at summit
20:18:53 <asalkeld> sure
20:19:06 <sdake_> #link http://summit.openstack.org/cfp/details/44
20:19:28 <sdake_> looks relevant
20:19:49 <sdake_> one thing I'd like thought about spamaps is the difference between scheduling with corotines vs threads
20:20:05 <SpamapS> I think we've all agreed, this is doable in the near term. We should bring our ideas and some thoughts on how difficult they will be to implement.
20:20:07 <sdake_> spamaps can you make an etherpad on the subject
20:20:35 <SpamapS> sdake_: sure thing. Not entirely sure where to go to do that.
20:21:20 <sdake_> #link https://etherpad.openstack.org/heat-concurrent-resource-scheduling
20:21:31 <SpamapS> ah cool thanks :)
20:21:47 <sdake_> asalkeld if you would follow same convention might find that helpful
20:21:55 <asalkeld> sure
20:22:07 <sdake_> #link http://summit.openstack.org/cfp/edit/86
20:22:53 <shardy> http://summit.openstack.org/cfp/details/86
20:23:04 <shardy> edit gives me forbidden?
20:23:05 <SpamapS> horrible system
20:23:13 <sdake_> are you logged in?
20:23:23 <SpamapS> I believe only the owner can do edit
20:23:33 <sdake_> ya shardy made the session
20:23:41 <sdake_> oh wrong link ..
20:23:43 <sdake_> sec
20:23:45 <shardy> I am logged in, and I created this session, so not sure what the problem is
20:24:01 <sdake_> #link http://summit.openstack.org/cfp/details/88
20:24:07 <sdake_> lets try that one :)
20:24:38 <stevebaker> I've raised blueprints for the aws resources that are backed by openstack resources
20:24:41 <asalkeld> maybe merge with the tosca one
20:24:52 <SpamapS> no please do not merge w/ the tosca
20:25:07 <sdake_> link cut and paste failing me today..
20:25:20 <sdake_> #link http://summit.openstack.org/cfp/details/86
20:25:26 <sdake_> heat credentials management
20:25:29 <SpamapS> this is a critical item and I want to make sure we are all fully understood on the end goal, and the forces driving it.
20:25:39 <sdake_> spamaps lets address that next.. :)
20:25:46 <SpamapS> yes back to 86 :)
20:26:17 <shardy> So I'm hoping to get some input from all on the way forward with this, and in particular get some keystone guys involved
20:26:19 <SpamapS> +1 for 86, I have some ideas and would love to share and hear where others think we are
20:26:29 <sdake_> shardy would you fill out an etherpad on the subject
20:26:29 <shardy> as I'm pretty sure we still need more new keystone features
20:26:30 <stevebaker> re 86, if we move to trusts, would that cause issues if we also replace heat-cfntools with aws-cfn-bootstrap?
20:27:00 <shardy> stevebaker: Thats what I'm referring to, we need the ability to create ec2 keypairs from trust tokens
20:27:00 <asalkeld> not sure
20:27:03 <sdake_> keystone needs a "sudo" but not sure best how to handle that
20:27:08 <shardy> which keystone cannot currently do
20:27:16 <sdake_> howdy azaneb
20:27:25 <asalkeld> trusts == sudo
20:27:25 <zaneb> hey, sorry
20:27:25 <sdake_> just going through summit sessions now
20:27:39 <shardy> so the answer is, yes it would cause issues, so we can't use trusts in-instance until that is figured out
20:27:41 <zaneb> lost track of the time
20:27:59 <sdake_> shardy mind filling in a etherpad on the topic to kick things off?
20:28:13 <shardy> sdake_: sure will do (be tomorrow now)
20:28:33 <sdake_> #link https://etherpad.openstack.org/heat-credentials-management
20:28:48 <sdake_> #action shardy to fill in heat credentials management etherpad
20:29:11 <sdake_> #link http://summit.openstack.org/cfp/details/88
20:29:38 <shardy> Isn't this just a resource naming issue?
20:29:39 <sdake_> abstracting aws out of heat
20:30:03 <sdake_> i am not entirely convinced - some openstack resources may have unique properties that aren't handled
20:30:04 <stevebaker> could these blueprints be attached to the session? https://blueprints.launchpad.net/heat/+spec/native-cinder-volume https://blueprints.launchpad.net/heat/+spec/native-nova-instance
20:30:07 <shardy> We previously discussed having a config file with name mappings, so the code doesn't need to have AWS resource names in it?
20:30:34 <asalkeld> http://summit.openstack.org/cfp/details/171
20:30:44 <asalkeld> just added that one ^
20:30:56 <asalkeld> still need to fill it in a bit
20:30:58 <SpamapS> going back to 88 ...
20:30:59 <stevebaker> that still leaves properties schema that are aws specific. I'd rather see native resources that are thin wrappers over openstack APIs
20:31:03 <SpamapS> Its not just resource naming
20:31:05 <SpamapS> it is wikis
20:31:05 <sdake_> seems like people interested to discuss, so definitely recommend a session at summit on the topic
20:31:06 <SpamapS> and documentation
20:31:25 <sdake_> yes it impacts everything we do as a complete project in openstack
20:31:40 <SpamapS> The concern is simple. OpenStack consumers do not want to drive users of Heat and OpenStack to AWS CloudFormation which has far more capabilities.
20:31:44 <sdake_> as an aside, I have heard significant feedback there is interest in this particular issue
20:32:09 <shardy> stevebaker: but still have the AWS resource types, subclassed from the native ones I guess?
20:32:09 <sdake_> spamaps could you fill out an etherpad on the topic?
20:32:26 <SpamapS> sdake_: yes I'll create one now
20:32:43 <sdake_> https://etherpad.openstack.org/heat-abstracting-aws-out
20:33:10 <sdake_> #action spamaps to fill out abstracting aws out of heat to kick off discussion
20:33:38 <sdake_> #link http://summit.openstack.org/cfp/details/78
20:33:39 <zaneb> SpamapS: who are OpenStack "consumers" in this context?
20:33:45 <sdake_> Rolling updates and instance specific metadata
20:35:28 <asalkeld> seems fine
20:35:42 <sdake_> ya bit of two topics in one but seems ok
20:35:49 <oubiwann> http://summit.openstack.org/cfp/details/172
20:35:54 <oubiwann> https://blueprints.launchpad.net/heat/+spec/heat-autoscaling
20:36:01 <SpamapS> zaneb: deployers would have been a better word :)
20:36:08 <oubiwann> oh, snap -- sorry guys
20:36:10 <oubiwann> wrong window
20:36:18 <sdake_> ninja topic ;)
20:36:37 <SpamapS> The reason rolling updates and instance specific metadata is together is that instance specific metadata is needed for rolling updates to work.
20:36:38 <oubiwann> totally :-/
20:36:54 <sdake_> i see
20:37:11 <SpamapS> I want to get consensus on the need for both, at the same time.
20:37:29 <asalkeld> SpamapS, you might want to metion that it is instance metadata for instancegroups
20:37:36 <sdake_> ok well same drill - same format re etherpad
20:37:56 <zaneb> oubiwann: autoscaling has been in Heat since... forever?
20:38:02 <SpamapS> asalkeld: right.
20:38:45 <sdake_> #action spamaps to create etherpad for specific metadata for rolling updates
20:39:07 <sdake_> ok looks like we had some late entrants - lets review those real quick:
20:39:23 <sdake_> #link http://summit.openstack.org/cfp/details/171
20:39:45 <sdake_> definitely need to solve this problem
20:39:57 <sdake_> asalkeld mind putting together an etherpad
20:40:04 <asalkeld> (added 5mins ago - so a bit lite)
20:40:06 <asalkeld> sure
20:40:17 <sdake_> not late, schedule ends on 30th, but late for the agenda ;)
20:40:25 <asalkeld> (lite)
20:40:42 <SpamapS> I think thats one where people should come with ideas in hand.
20:40:48 <sdake_> #action asalkeld to create etherpad for multiple heat engines in one openstack deployment
20:41:02 <sdake_> spamaps we have our original architectural ideas
20:41:07 <sdake_> those either need validating or reworking
20:41:08 <asalkeld> all sessions should be with "ideas in hand"
20:41:10 <stevebaker> I won't be there, so I'll dump my idea in the etherpad
20:41:15 <SpamapS> sdake_: cool
20:41:26 <sdake_> stevebaker which session type?
20:41:44 <stevebaker> multiple heat-engines
20:41:51 <sdake_> cool
20:41:57 <sdake_> #link http://summit.openstack.org/cfp/details/172
20:42:00 <sdake_> ok last one, :)
20:42:04 <stevebaker> no its not
20:42:15 <SpamapS> oubiwann: ^^
20:42:21 <asalkeld> I think we have all of that?
20:42:25 <SpamapS> I spoke with oubiwann at Pycon briefly about this
20:42:26 <sdake_> oubiwann we have that
20:42:31 <SpamapS> I think the idea is to have it without heat
20:42:39 <asalkeld> lol
20:42:41 <sdake_> yes, that is next on the agenda
20:42:43 <zaneb> "Autoscaling for Heat"
20:42:49 <zaneb> "Proposed by oubiwann in topic Heat"
20:43:11 <sdake_> oubiwann perhaps a better subject would be "decomposing autoscaling from heat"
20:43:15 <barefoot> he got a call, let me go track him down
20:43:17 <SpamapS> I added it to the meeting agenda because I wasn't sure we'd get a submission during session review :)
20:43:35 <fsargent> I can answer questiongs regarding oubiwann's autoscaling project
20:43:39 <asalkeld> so you want a new project?
20:43:50 <fsargent> questions* even.
20:43:55 <SpamapS> I think the question is, why would this be outside of Heat as a project?
20:44:17 <sdake_> #topic autoscaling decomposition
20:44:19 <SpamapS> I understand that it might be its own API and not want to drag heat's template language along.
20:44:22 <sdake_> (this was in agenda btw)
20:44:37 <zaneb> in AWS, Autoscaling is a feature of EC2
20:44:39 <SpamapS> But that could still live inside heat as a project and be quite happy.
20:44:49 <zaneb> so arguably it should be provided by Nova
20:44:52 <sdake_> zaneb autoscale is a separate api in aws
20:44:54 <asalkeld> SpamapS, you need the launchconfig
20:45:03 <shardy> SpamapS: what do we gain by doing this though?
20:45:06 <zaneb> oh, my bad
20:45:14 <fsargent> The launch config for AS is a nova launch config.
20:45:20 <SpamapS> shardy: I don't know, thats why oubiwan is proposing. :)
20:45:22 <fsargent> with a load balancer
20:45:40 <shardy> We could implement the API and leave the AS logic in the engine if people want the AWS separate-API for AS
20:45:59 <SpamapS> To me, its declarative vs. imperative all over again.
20:46:06 <sdake_> the rationale behind this seems to be autoscaling as a unique service, without orchestration features which heat provides
20:46:23 <sdake_> little history
20:46:28 <SpamapS> And no matter how awesome your declarative API is (heat templates), people will want an imperative way to operate it.
20:46:37 <asalkeld> well cloud watch is an issue
20:46:49 <sdake_> when we started heat, we had two huge dependencies that we needed solving - 1 was cloudwatch 2 was autoscaling
20:46:56 <sdake_> we merged them into one code base
20:47:01 <asalkeld> we need monitoring (been added to ceilometer)
20:47:13 <shardy> SpamapS: sounds like you're proposing a new service for openstack (which heat could use instead of an internal implementation)
20:47:17 <asalkeld> a tad early for this imo
20:47:18 <SpamapS> *I* am not
20:47:30 <fsargent> The API we have for Autoscaling entirely abstracts monitoring out of the system.
20:47:32 <stevebaker> or a new service in heat
20:47:33 <sdake_> oubiwann is propsing
20:47:34 <shardy> but we don't have the monitoring infrastructure etc as asalkeld points out
20:47:37 <SpamapS> I am merely introducing oubiwan to you guys :)
20:48:06 <shardy> SpamapS: ok, noted, sorry ;)
20:48:11 <asalkeld> fsargent, but you still need an implemetation there
20:48:13 <SpamapS> Since oubiwan is busy, can we move on and come back, or is this the last item we have for today?
20:48:13 <sdake_> fsargent, oubiwann will you both be at summit?
20:48:18 <fsargent> The Autoscaling API will setup webhooks per policy, that monitoring will hit.
20:48:20 <stevebaker> #link http://summit.openstack.org/cfp/details/90
20:48:27 <fsargent> sdake_: Yup.
20:48:44 <sdake_> stevebaker that is a horizon topic
20:48:54 <sdake_> here is my take
20:48:55 <stevebaker> but its heat related
20:49:06 <SpamapS> fsargent: It sounds like you guys already did this, without looking at whether or not it was doable in Heat itself.
20:49:10 <SpamapS> which, IMO, it is.
20:49:16 <sdake_> worth having a design session, willing to put it into the heat track - since atm heat does the autoscaling around here ;)
20:49:25 <shardy> If it's already done, where is the code?
20:50:13 <asalkeld> maybe someone if finding a link?
20:50:14 <fsargent> We're working on something.
20:50:28 <asalkeld> on github?
20:50:41 <fsargent> Yes, but its in a private repo currently.
20:50:46 <zaneb> asalkeld: +1 :)
20:50:46 <asalkeld> urg
20:50:49 <shardy> fsargent: Having a summit discussion about your yet-to-be-unveiled solution will not be worthwhile IMHO
20:51:14 <fsargent> Understood.
20:51:19 <asalkeld> yea don't be afraid - make it public
20:51:33 <asalkeld> we can provide feedback
20:51:44 <SpamapS> Or, don't, and just plug the same API into heat.
20:52:17 <asalkeld> muliple projects does make deployment more of a pain
20:52:41 <sdake_> our job isn't to worry about deployment, our job is to worry about making openstack spectacular and well decomposed
20:53:03 <SpamapS> well, my job is to worry about deployment, but my job in heat isn't .. ;)
20:53:11 <sdake_> precisely ;)
20:53:22 <asalkeld> but if some wants autoscale but not heat, then this might make it easier
20:53:34 <fsargent> I won't go on about how we're intending to submit autoscaling, but it is modular and cross functional.
20:53:41 <SpamapS> that said, IMO, heat is the place to do this, as it is the thing that operates on the other services from an automation point of view.
20:53:50 <fsargent> heat can call it, and it'll run everythingin that environment, or outside of it.
20:54:16 <SpamapS> and autoscaling, cloudwatch, etc, can just be implemented as api calls.
20:54:18 <sdake_> yes feature sounds interesting - but tbh approach is wrong - ping me after meeting for some advice
20:54:27 <fsargent> Will do sdake_ thanks.
20:54:31 <SpamapS> lets move on
20:54:33 <SpamapS> 6 min
20:54:42 <sdake_> well wanted to get through some blueprints today
20:54:55 <sdake_> but we can hardly get started in our time allotted
20:54:59 <stevebaker> heh, not a chance
20:55:04 <sdake_> so I'll switch to open topics at the moment
20:55:09 <sdake_> #topic open topics
20:55:35 <stevebaker> well done on rc1 everyone
20:55:45 <sdake_> stevebaker took my line ;)
20:55:49 <SpamapS> \o/
20:56:04 <sdake_> So, first off, everyone doing a spectacular job
20:56:15 <sdake_> we have had a big impact in OpenStack over the last year
20:56:35 <sdake_> We started in March 2012 - look what we accomplished - full integration with a great feature set that makes OpenStack better
20:56:56 <sdake_> high high performance team - keep up the good work ;)
20:57:37 <SpamapS> ^5 to all, humbled to have joined such a fine tribe. :)
20:57:38 <uvirtbot> SpamapS: Error: "5" is not a valid command.
20:57:48 <sdake_> ^help
20:57:50 <uvirtbot> sdake_: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
20:58:00 <sdake_> have to probe that later ;)
20:58:17 <sdake_> ok thanks all
20:58:18 <sdake_> anything else?
20:58:24 <asalkeld> nope
20:58:43 <sdake_> one last thing
20:58:48 <sdake_> if your presenting a session
20:58:57 <sdake_> please send me the days you have booked in your schedule for Monday
20:59:03 <sdake_> rather times on Monday
20:59:11 <sdake_> so that I don't double-book a session
20:59:29 <sdake_> thanks!
20:59:31 <sdake_> #endmeeting