20:01:37 <stevebaker> #startmeeting heat
20:01:38 <openstack> Meeting started Wed Dec  4 20:01:37 2013 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:41 <randallburt> please don't start a Marketing Committee meeting
20:01:42 <openstack> The meeting name has been set to 'heat'
20:01:45 <stevebaker> #topic rollcall
20:01:45 <adrian_otto> hah
20:01:50 <radix> hello
20:01:50 <shardy> o/
20:01:51 <tspatzier> hi
20:01:51 <randallburt> heyya
20:01:52 <jasond> o/
20:01:52 <sdake_> o/
20:01:54 <skraynev> o/
20:01:57 <kebray> o/
20:01:57 <tims> o/
20:02:02 <lakshmi> o/
20:02:08 <vineethv> hi  o/
20:02:13 <kwhitney> hi
20:02:13 <pafuent> hi
20:02:19 <mspreitz> hi
20:02:20 <pshchelo_> hi
20:02:42 <sdake_> irc.freenode.net just crashed from o/
20:02:46 <stevebaker> #topic Review last meeting's actions
20:03:04 <stevebaker> #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-11-27-20.00.html
20:03:13 <stevebaker> Randall to publish use cases for heat template catalog
20:03:25 <tims> \o/
20:03:37 <stevebaker> we have template catalog on the agenda, lets talk about that later
20:03:47 <randallburt> k
20:03:49 <stevebaker> #topic Adding items to the agenda
20:04:02 <stevebaker> Any items to add?
20:04:10 <SpamapS> o/
20:04:15 <stevebaker> #linkg https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda
20:04:18 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda
20:04:38 <topol> o/
20:04:43 <stevebaker> #topic * icehouse-1 release
20:04:50 <stevebaker> SpamapS: you made it !1
20:05:06 <sdake_> no quorum without spamaps ;)
20:05:14 <stevebaker> #link https://launchpad.net/heat/+milestone/icehouse-1
20:05:16 <SpamapS> if that were true... there would be no quorum ;)
20:05:23 <stevebaker> we're looking pretty good
20:05:35 * stevebaker checks if we've actually branched yet
20:05:43 <sdake_> green is good
20:05:45 <randallburt> wow, that looks pretty good.
20:06:10 <shardy> bumping all the non-green-things ftw! ;)
20:06:12 <SpamapS> it did not look so good yesterday.. :)
20:06:26 <sdake_> can always do tomorrow what can't be done today ;0
20:06:27 <adrian_otto> damn, that's awesome
20:06:30 <stevebaker> SpamapS: I just kicked all the things to i-2 ;)
20:06:33 <SpamapS> right
20:06:36 <stevebaker> https://github.com/openstack/heat/tree/milestone-proposed
20:06:58 <stevebaker> we can still get bug fixes into i-1
20:07:22 <jasond> stevebaker: this is merged, but not listed in the i-1 list https://blueprints.launchpad.net/heat/+spec/rackconnect
20:07:26 <stevebaker> by tagging the bug with...
20:07:30 <jasond> maybe it needs to be approved?
20:07:32 <stevebaker> does anybody know?
20:07:37 <stevebaker> milestone-proposed?
20:07:46 <shardy> stevebaker: yea
20:08:07 <shardy> stevebaker: Or actually, you just propose them by the backport process (same as stable)
20:08:15 <stevebaker> jasond: fixed
20:08:17 <shardy> but the branch you propose to is milestone-proposed
20:08:25 <jasond> stevebaker: thanks
20:08:27 <shardy> don't necessarily have to tag the commit
20:08:53 <stevebaker> ok, what shardy said.
20:09:20 <stevebaker> we got a lot of blueprints in, way better than grizzly-1
20:09:35 <sdake_> more community members ftw!
20:09:39 <shardy> stevebaker: Anyone can propose them in theory, but normally I think the PTL monitors the bugs merged between branch and release, and propose as needed
20:09:50 <shardy> or at least that's what I did
20:10:10 <stevebaker> yeah, anything that gets fixed in the next few days I'll evaluate for milestone-proposed
20:10:24 <stevebaker> well, the next day and a bit
20:10:30 * randallburt yells at tests to hurry up and work
20:10:36 <stevebaker> #topic * Template catalog use cases
20:10:49 <randallburt> tims: commence the link spam ;)
20:10:51 <stevebaker> randallburt: shoot!
20:10:55 <tims> https://blueprints.launchpad.net/heat/+spec/heat-template-repo
20:11:00 <tims> https://wiki.openstack.org/wiki/Heat/htr
20:11:15 <tims> \o/
20:11:33 <stevebaker> shouldn't that be HeaTR?
20:11:35 <randallburt> we basically added them to the existing bps and spec. We're still working on specs and don't want to spend much time there until everyone has a chance to review the use cases
20:11:39 <sdake_> shardy your wish is tims command :)
20:11:41 <randallburt> stevebaker:  I like
20:11:52 <tims> haha
20:12:17 <randallburt> so there will also be a follow up ML post after the meeting to continue refining/consensus if that's cool with everyone.
20:12:21 <tims> randallburt had to tell me what HTR stands for
20:13:01 <randallburt> maybe HOTTeR?
20:13:07 <adrian_otto> oh, my
20:13:13 <sdake_> my money is on heat template repository
20:13:24 <stevebaker> heattr
20:13:32 <shardy> tims: So will this be a new orchestration project, not something we add via the existing heat API?
20:13:47 <tims> shardy: well that's up for debate
20:13:49 <randallburt> shardy:  that's the plan ATM.
20:13:49 <SpamapS> Has there been any evaluation of existing API driven things for managing a catalog of documents?
20:14:15 <SpamapS> Like, what makes HOT special that it needs a new one?
20:14:39 <shardy> Ok, my position has always been that we shouldn't be storing templates via the orchestration API, but I can see the value in some other service related to heat, provided we don't reimplement git in the process ;)
20:14:41 <stevebaker> yes, surely the CMS crowd has solved this problem many times
20:14:51 <randallburt> SpamapS:  some, but we still need to dig a bit more into your Glance proposal; I still need to see if it will actually work
20:15:12 <tims> shardy: There are lots of cool things that we could do if it were part of existing heat api
20:15:19 <shardy> tims: such as?
20:15:21 <SpamapS> Glance doesn't have versioning and it may never have it. So I accept Glance isnt necessarily the answer (though adding versioning to glance would probably make some image deployers very happy..)
20:15:35 <tims> but I haven't clearly defined those things atm which I why I'm not super passionate about it
20:15:36 <randallburt> shardy:  we've talked a bit about HTR using git as a backing store and alternate means of management, but still need to document that as well
20:15:43 <tims> things that require engine parsing the template
20:15:51 <SpamapS> I worry that there is a default position of building rather than consuming.
20:16:10 <stevebaker> tims, randallburt: I have a use case which would be nice to add:
20:16:13 <stevebaker> As a template author I want to add and manage templates in the repository using git
20:16:15 <tims> that may not do Heat things but we would not want to duplicate the parsing logic
20:16:18 <sdake_> SpamapS could you expand on that point?
20:16:51 <SpamapS> For instance, cgit has search, tagging, versioning.. why not just add keystone token auth to cgit?
20:16:56 <randallburt> stevebaker:  yup sounds good to me and something tims and I discussed yesterday quite a bit. we still just need to put those thougts into the associated wiki
20:17:15 <tims> stevebaker: agreed
20:17:21 <shardy> tims: I may need a little more detail to really understand what you're proposing
20:17:35 <randallburt> SpamapS:  fair point, but we've tried to step back and "do the right thing" here and just talk general use cases and get consensus around the service iteself
20:17:44 <shardy> tims: Can you add a section to the wiki with the arguments for keeping the two things together?
20:17:48 <tims> shardy: Yes I'm working on a formal proposal
20:17:53 <tims> good idea
20:17:54 <SpamapS> randallburt: fantastic, the use cases look realy solid actually.
20:18:09 <shardy> tims: Just a quick brain-dump into the wiki is fine for now
20:18:18 <tims> shardy: will do
20:18:23 <sdake_> randallburt the approach seems right for a contentious change ;)
20:18:24 <randallburt> tims did all the heavy lifting. I just do reviews and go on vacation.
20:18:46 <randallburt> and vineethv too
20:19:05 <SpamapS> " A service maintainer would like to have a repository in which he can manage Heat templates and maintain associated keywords and metadata."
20:19:12 <SpamapS> can we please use non-gender-specific pronouns?
20:19:26 <randallburt> SpamapS:  sure
20:19:27 <stevebaker> tims, randallburt, so another issue is the apparent overlap with the scope of Murano. I think you guys really need to get together and find some common ground. The TC is only going to allow one template catalog into OpenStack. https://wiki.openstack.org/wiki/Murano
20:19:31 <tims> SpamapS: yeah I started going back through and fixing that stuff
20:19:34 <tims> but I haven't finished
20:19:44 <SpamapS> cool
20:20:28 <randallburt> stevebaker:  agreed. tims or I can reach out to them. They originally posted a comment on the BP a while back and I think they may be complementary when I read what they proposed, but I'll go see where they're at.
20:21:11 <stevebaker> randallburt: chances are they would be more than happy to use heattr as their cataloging layer
20:21:27 <tims> shardy: an initial idea is parsing the template to retrieve the "planned stack" resources based on parameters
20:21:45 <tims> so we know exactly what resources are created before stack instantiation
20:21:47 <randallburt> stevebaker:  my thoughts exactly
20:21:59 <tims> the argument I'm having with randallburt is whether thats a feature of Heater or Heat
20:22:04 <kebray> stevebaker my understanding is Murano is a 3rd party (sell your stuff) Application Catalog.  and, HTR is a template catalog for Heat templates.
20:22:14 <shardy> tims: You mean like a template cost estimate or something?
20:22:14 <stevebaker> randallburt: and maybe https://github.com/stackforge/murano-dashboard can be the start of a horizon frontend to heattr
20:22:23 <randallburt> tims shardy but that is a different bp imo and may belong in heat api proper, but its another issue to discuss
20:22:31 <tims> shardy: more or less
20:22:36 <randallburt> stevebaker:  oh cool. I'll check that out.
20:22:53 <tims> randallburt: agreed but it could have ramifications on the discussion about putting Heater in Heat proper
20:23:12 <randallburt> tims: oh, right. yeah, thats going to be a fun one ;)
20:23:34 <SpamapS> kebray: Sell your stuff or give your stuff away, sounds _very_ related.
20:23:39 <shardy> tims: Ok, maybe we could have an API call which validates a template and returns a list of resources or something
20:23:49 <randallburt> FWIW, lets get mailing list consensus on the UC/scope of Heater before we dive in to those waters.
20:23:57 <stevebaker> kebray: ah. that sounds they are a layer above heattr. They should be strongly encouraged to get involved
20:24:02 <sdake_> tims: Heat is a component of the Orchestration program, so hopefully the ramifications won't be overblown
20:24:03 <kebray> SpamapS agreed... will connect with the Murano folks more.  That project keeps changing.  One day it's windows, the next it's an app store.
20:24:03 <SpamapS> Make sure the Murano folk have seen everything.
20:24:18 <SpamapS> kebray: agreed, that may be enough reason to stay away ;)
20:24:22 <tims> shardy: :) yes I have thoughts about the validate endpoint too
20:24:30 <randallburt> shardy:  yeah, IMO its a tangental use case in which the user wants to know before they create a stack just how many of which resources would be created; not sure that's a Heater thing.
20:24:40 <stevebaker> so if there is some POC code that already exists, lets get it into stackforge with a new gerrit core team
20:24:48 <kebray> Yeah, they knew about HTR before they switched Muran's definition.  The answer I got was they are doing something different.  but, we will def reach out to them again.
20:25:03 <shardy> tims: So IMO we could add some calls to support this, but I still remain very unconvinced that we should expose a template store via the heat (*orchestration*) endpoint
20:25:14 <randallburt> stevebaker:  about that, there is, but is having it in the Orchestration *program* still on the table?
20:25:22 <stevebaker> If it eventually gets proposed to being part of the orchestration program, the gerrit team will become heat-core
20:25:28 <randallburt> shardy:  fwiw I agree.
20:25:30 <tims> sdake_ shardy point taken and I am in general agreement
20:26:20 <randallburt> stevebaker:  because IMO, it belongs in the program and if we have a proposal for it now, I'd rather avoid the double work of getting it in stackforge and then moving it.
20:26:29 <kebray> shardy randallburt , I think tims and I are in opposition with you guys... will definitely be good to understand each other's sides. More discussion to be had.
20:26:38 <adrian_otto> fwiw, I took a good look at Murano, and I don't think it's similar enough to be a fit for this.
20:26:41 <kebray> ok, maybe it's just me :-)
20:26:44 <tims> as long as the proposed schema for heater has not valid use for Heat
20:26:55 <tims> kebray I have some conditions in my agreement ;)
20:26:58 <SpamapS> one thing about a program..
20:27:03 <kebray> hehe.. sure sure tims .
20:27:05 <adrian_otto> I agree with randallburt they are complimentary
20:27:11 <SpamapS> is that programs can reach across to other projects and programs to achieve their mission.
20:27:35 <SpamapS> programs are specifically _not_ silos.
20:27:46 <stevebaker> randallburt: moving from stackforge -> openstack isn't a huge deal. I don't know the process but I think a new source tree still needs some form of incubation even if it is part of the orchestration program from the start
20:27:46 <sdake_> SpamapS +1
20:27:53 <adrian_otto> +1
20:28:10 <randallburt> Yeah, my real question is "Can we develop this under github.com/openstack/heat-repository from the get go"?
20:28:13 <stevebaker> #action stevebaker find out the incubation process for new projects in existing programs
20:28:28 <randallburt> as part of the orchestration program
20:28:37 <sdake_> stevebaker that sounds like a popcorn-filled conversation :)
20:28:43 <SpamapS> randallburt: yes
20:28:50 <adrian_otto> I don't think there is a process yet
20:29:06 <SpamapS> we've added lots to openstack/xxx in TripleO
20:29:09 <randallburt> SpamapS:  k. certainly something we can explore more on the ML
20:29:20 <stevebaker> randallburt: we probably could, but it would most likely mean being owned by heat-core from the start. You might make quicker process with a new -core team, which would imply stackforge for now
20:29:25 <SpamapS> integration into the release is what the incubation process brings, but the program gives you "officialness"
20:29:37 <SpamapS> thats a word
20:29:39 <SpamapS> I swear
20:30:06 <adrian_otto> stevebaker: what's wrong with using the current head-core for it?
20:30:09 <stevebaker> another possible solution is to grow heat-core, which we should anyway
20:30:14 <adrian_otto> s/head/heat/
20:30:14 <randallburt> stevebaker:  true and good point which we've of course discussed before. Just want to make sure we're all aware of the actual options.
20:30:16 <stevebaker> reviews! reviews! reviews!
20:30:26 <randallburt> :3 pages:
20:30:32 <sdake_> need moar reviewers -> more heat core !!
20:30:36 <shardy> adrian_otto: If most of the folks working on it aren't heat-core, they may get frustrated when we're slow reviewing their stuff ;)
20:30:45 <adrian_otto> shardy: I see
20:31:03 <shardy> adrian_otto: I guess there are advantages to either approach
20:31:04 <SpamapS> stevebaker: we can create sub-teams that are not heat-core but have access to a different openstack/xxxx repo
20:31:18 <SpamapS> yeah we do actually need more reviewers
20:31:19 <stevebaker> SpamapS: do tripleo do that?
20:31:35 <stevebaker> SpamapS: with all your many many repos?
20:31:37 <SpamapS> http://russellbryant.net/openstack-stats/heat-openreviews.html
20:31:49 <SpamapS> stevebaker: we have talked about doing so for tuskar
20:31:57 <SpamapS> stevebaker: but ultimately we just encouraged tuskar folk to review everything ;)
20:32:05 <shardy> Average wait time: 1 days, 1 hours, 20 minutes
20:32:19 <shardy> not too bad in comparison to some other projects IME
20:32:27 <sdake_> unfortunately I spend 2 hours a day doing reviews
20:32:34 <sdake_> would be nice to trim that to 1 hour :)
20:32:41 <stevebaker> shardy: but that could be spread over way more reviewers
20:32:48 <stevebaker> http://russellbryant.net/openstack-stats/heat-reviewers-60.txt
20:32:53 <randallburt> sdake_:  only 2!!??
20:33:00 <shardy> stevebaker: I agree, and I think there are some potential candidates coming along :)
20:33:09 <sdake_> I haven't had the willpower to do any reviews since thanksgiving :(
20:33:10 <SpamapS> Right I think we're doing well because we're all committed to doing well... but we could use more reviewers
20:33:25 * SpamapS notes  ----> Open Discussion as we are OT
20:33:49 <pshchelo_> hi all
20:34:10 <pshchelo_> can we create a topic in openstack-dev specifically for heat?
20:34:19 <stevebaker> randallburt: so you should start a ML thread to talk about new project, where to host, who to be -core etc?
20:34:32 <randallburt> stevebaker:  that's the plan
20:34:39 <stevebaker> sounds good
20:34:43 <stevebaker> lets move on
20:34:43 <tims> one more thought: if Heater is separate from Heat as just a template store that's fine, the problem is we are defining additional schema for Heater which may be useful to templates or users not interfacing with Heat via Heater. so when looking at the proposed schema maybe some of it goes in the template and then Heater is literally crud operations on templates?
20:35:03 <tims> we can discuss on ml
20:35:13 <sdake_> tims details on ml I think are better
20:35:19 <tims> got it
20:35:43 <SpamapS> yeah and also the schema-for-packaging is contentious
20:35:45 <stevebaker> tims: we can add things to the HOT schema. Most potential additions would probably be useful to things other than heater
20:36:17 <stevebaker> #topic open discussion
20:36:47 <pshchelo_> sorry for offtopic above - couldn't wait..
20:37:08 <sdake_> we have a [heat] tag on openstack-dev ml already?
20:37:15 <SpamapS> stevebaker: should I not have approved https://review.openstack.org/#/c/59577/5 ?
20:37:19 <randallburt> pshchelo_:  the way it generally works is we have [heat] prefix for our subjects
20:37:21 <pshchelo_> yes, but you can not subscribe to it
20:37:30 <SpamapS> stevebaker: or will the branch just be made off some commit that is already there?
20:37:33 <randallburt> there's only one openstack-dev
20:37:39 <pshchelo_> only filtering
20:37:52 <sdake_> pschelo_ thats what mail filters were invented for :)
20:37:53 <prasadv> can we discuss autoscaling api in this open discussion, I have a question on the load balancer member
20:37:56 <shardy> pshchelo_: That's what the tags are for ;)
20:38:33 <pshchelo_> you can subscribe to specific topics on openstack-dev, but heat is not one of them
20:38:46 <stevebaker> SpamapS: milestone-proposed is already branched, so we're open for features again I think
20:38:50 <SpamapS> pshchelo_: contact Stefano about that, he can and should add it.
20:38:52 <sdake_> pschelo_ do you have a link as an example?
20:38:55 <SpamapS> stevebaker: ok cool
20:39:11 <pshchelo_> filters I know, but still receiving the whole list
20:39:32 <pshchelo_> which is a bit overwhelming
20:39:33 <stevebaker> prasadv: ask away
20:39:33 <sdake_> mark all read ftw ;)
20:39:47 <prasadv> can the load balancer member be non IP based
20:39:48 <pshchelo_> that's a solution for now
20:40:10 <prasadv> there are cases where the autoscaling can be done on a neutron port or mac address
20:40:44 <prasadv> in that case it would be a custom LB
20:40:53 <prasadv> i mean non neutron LB
20:41:05 <stevebaker> prasadv: it seems reasonable for a member to be a port UUID instead of an IP
20:41:18 <sdake_> ideally we dont want to reimplement neutron's load balancer
20:41:23 * radix reads backlog
20:41:36 <sdake_> but if people use heat in that way, I don't think we should be in a position to stop them
20:41:53 <prasadv> i assume one can configure any load balancer right?
20:41:57 <pshchelo_> when you log in to your mailman subscription manage page for openstack-dev
20:41:59 <pshchelo_> http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev
20:42:14 <radix> prasadv: are you referring to the idea for a PoolMember resource?
20:42:17 <prasadv> not just Lbaas
20:42:24 <SpamapS> Right Heat should be enabling the Neutron LB the way Neutron users want it to work. So if it allows adding port UUID members, then Heat should do that.
20:42:26 <sdake_> pschelo_ contact the list manager at the bottom of the page - he can add heat there I suspect
20:42:26 <prasadv> radix: yes
20:42:43 <radix> prasadv: presumably PoolMember will match the pool member API in whatever it accepts
20:42:46 <pshchelo_> sdake_: thanx
20:43:07 <sdake_> pschelo_ nobody here knows the list admin password :)
20:43:23 <prasadv> radix: thanks
20:43:35 <radix> prasadv: I don't know if that answers your question, I'm having a hard time understanding it
20:43:39 <stevebaker> prasadv: how would a FloatingIP become a pool member?
20:44:10 <pshchelo_> wasn't sure if I'm not missing smth
20:44:35 <prasadv> stevebaker: I dont understand the question? Are you talking about non neutron LB?
20:45:20 <prasadv> radix: Load balancing in some scenarios can be based on port, particularly related to service chaining
20:45:45 <stevebaker> prasadv: for neutron LB, should we support adding a FloatingIP to a LB pool?
20:46:16 <prasadv> radix: autoscale is one important component of service chaining
20:46:24 <adrian_otto> I think he might be asking if you could use a pool as an inventory of floating IPs
20:47:17 <prasadv> stevebaker: generally floating IP is external and it is mapped to internal IP addresses. One could get away with using internal IP addresses. I think
20:47:34 <stevebaker> I think what I'm referring to is this bug https://bugs.launchpad.net/heat/+bug/1256836
20:47:35 <uvirtbot> Launchpad bug 1256836 in heat "associate vip with floating ip" [Medium,Triaged]
20:48:13 <prasadv> stevebaker: I will look at the bug. Dont have the context on that
20:48:40 <stevebaker> prasadv: ok, feel free to comment on it, especially if you think it is not valid
20:48:57 <stevebaker> anything else, should we wind up the meeting?
20:49:00 <arbylee> anyone interested in talking a bit about the sync/convergence feature: https://blueprints.launchpad.net/heat/+spec/stack-convergence?
20:49:23 <sdake_> lets wind up!
20:49:51 <arbylee> we're working through initial implementations and have been trying to work through some scenarios: https://etherpad.openstack.org/p/heat-convergence
20:50:29 <stevebaker> arbylee: it looks like zaneb has started working on https://blueprints.launchpad.net/heat/+spec/update-failure-recovery which may be tangentially related
20:50:30 <randallburt> arbylee:  is that a duplicate bp? I thought we discussed convergence at the summit, but it might have been a result of another bp. Just want to make sure they're linked.
20:51:25 <shardy> randallburt: not duplicate, but related I think
20:51:33 <arbylee> we didn't see a blueprint raised out of the summit for sync/converge.  There was one for auto-retry on create failures
20:51:43 <shardy> one is about restarting a failed update, or updating from a failed state
20:52:02 <shardy> rather than updating from a complete state and inspecting all the resource states
20:52:10 <randallburt> shardy, arbylee ok, cool. just wanted to row the ducks if needed ;)
20:52:17 <asalkeld> oops, bit late
20:52:27 <asalkeld> howdy
20:53:00 <stevebaker> arbylee: would you like to target heat-convergence to icehouse-2 or icehouse-3?
20:53:49 <andersonvom> stevebaker: icehouse-2 sounds like a good target so far
20:54:02 <stevebaker> done, and approved
20:54:06 <randallburt> and IIRC, we discussed there being two separate operations 1. tell me what the differences are and 2. Make the stack match the template if it doesn't.
20:54:57 <stevebaker> https://etherpad.openstack.org/p/icehouse-summit-heat-convergence
20:55:09 <arbylee> randallburt: right, our initial WIP commit produced a diff.  there were concerns about the scalability of that operation though
20:55:47 <arbylee> the resulting vision seemed to be to provide the two actions: 1) make my local stack reflect the real world resources and 2) Make the stack match the template if it doesn't.
20:56:21 <randallburt> arbylee:  ah, cool, though 1 sounds a little tricky when you get to instance configuration stuff
20:56:47 <shardy> randallburt: we could have an update which just aligns the resource states with the state of the underlying resource
20:57:15 <randallburt> shardy:  sounds simple enough in that case.
20:57:20 <andersonvom> shardy: that's our current development right now
20:58:01 <shardy> andersonvom: Cool, that's the first step IMO, then the next is to actually update the resource to e.g align from FAILED to COMPLETE state
20:58:14 <shardy> the second step will probably be the difficult bit ;)
20:58:34 <randallburt> 2 min
20:58:36 <andersonvom> shardy: agree. and agree. =P
20:58:51 <arbylee> shardy: we've been having some debate on that first bit even.
20:59:13 <randallburt> arbylee:  sounds like a good ML discussion then ;)
20:59:18 <shardy> andersonvom: That second step may end up being related to the restart-from-failed work which zaneb is looking at
21:00:12 <arbylee> randallburt: then ML discussion it shall be
21:00:21 <andersonvom> shardy, randallburt: true. we'll bring it up on the ML and sync up with zane to see what parts may be 'shared'
21:00:30 <shardy> andersonvom: +1
21:00:43 <asalkeld> endofmeeting?
21:00:48 <stevebaker> whoops
21:00:48 <randallburt> seems so
21:00:52 <stevebaker> #endmeeting