20:01:06 <stevebaker> #startmeeting heat
20:01:07 <openstack> Meeting started Wed Apr  9 20:01:06 2014 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:11 <openstack> The meeting name has been set to 'heat'
20:01:19 <zaneb> here we are
20:01:26 <stevebaker> #topic rollcall
20:01:29 <tspatzier> hi
20:01:30 <mspreitz> o/
20:01:31 <shardy> o/
20:01:40 <skraynev> hello all
20:02:05 <pas-ha> o/
20:02:09 <radix> o/
20:02:12 <randallburt> hithere
20:02:13 <cyli> o/
20:02:18 <BillArnold> o/
20:02:24 <arbylee> o/
20:02:25 <stevebaker> #topic Review last meeting's actions
20:02:35 <stevebaker> zaneb to post to openstack-dev to find an actionable solution to config generation
20:02:46 <zaneb> did I do that?
20:02:49 <Michalik> o/
20:02:51 <zaneb> I think I did that
20:02:52 <sanjay_sohoni> o/
20:03:00 <stevebaker> zaneb: yes. but did you get a way forward?
20:03:17 <stevebaker> #topic Adding items to the agenda
20:03:23 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-4-08_2000_UTC.29
20:03:33 <stevebaker> I don't think there is space for much more ;)
20:03:36 <zaneb> only the same way that didn't work for me before
20:03:57 <stevebaker> :(
20:04:09 <stevebaker> any response from nova?
20:04:21 <shardy> stevebaker: I added a couple of things already, feel free to bump if we're lacking time
20:04:24 <mspreitz> If we do get time, I would not mind discussion how holistic scheduling should look through heat
20:04:26 <sdake> o/
20:04:39 <stevebaker> shardy: I moved them to the end
20:04:44 <zaneb> stevebaker: nope
20:04:48 <shardy> stevebaker: ok
20:05:04 <stevebaker> mspreitz: next week might be better
20:05:16 <mspreitz> stevebaker: yes, it looks like it
20:05:18 <stevebaker> #topic Last minute rc2 fixes
20:05:54 <stevebaker> #topic https://launchpad.net/heat/+milestone/icehouse-rc2
20:06:00 <mspreitz> I could add that note about the alarm type defined in default environment
20:06:44 <stevebaker> I think at this point those 4 bugs which do not have fixes landed are going to miss the release :/ so we'll need to document them as known issues
20:06:47 <stevebaker> #link https://launchpad.net/heat/+milestone/icehouse-rc2
20:07:12 <pas-ha> looks like this one https://bugs.launchpad.net/heat/+bug/1298350 assigned to me
20:07:13 <uvirtbot> Launchpad bug 1298350 in heat "Heat is unable to detach volumes from servers" [High,Triaged]
20:08:05 <stevebaker> I think it is unlikely there will be an rc3 unless there are major release booboos
20:08:12 <pas-ha> 've been trying to fix it the whole day, done it two ways (removed extra call to detach and rewritten the whole attach.detach tasks to use only cinder)
20:08:43 <stevebaker> pas-ha: lets take the pressure off then and aim for j-1
20:08:43 <skraynev> pas-ha: and what results?
20:08:47 <pas-ha> still have sporadic failures in my devstack, with all three variants
20:09:32 <pas-ha> 've been using the same template bug reporter suggested 2 servers 2 volumes each
20:09:34 <stevebaker> pas-ha: is the workaround to do deletes until it works?
20:10:26 <pas-ha> no, the workaround should be ask for detach only once, as otherwise it is a known source of race in cinder/nova
20:10:31 <skraynev> stevebaker: +1 for moving it in juno. need more time for testing, I suppose
20:10:57 <stevebaker> pas-ha: I mean the workaround for the known issue which won't be fixed in rc2
20:11:09 <shardy> We can backport stuff when it lands in Juno, looks like there's quite a lot of bugfixes we'll want to backport anyway
20:11:37 <sdake> ya although if volume attach is doa out of the box that is not idela
20:11:41 <zaneb> pas-ha: what you described is a fix, not a workaround
20:11:43 <pas-ha> stevebaker: mainly yes
20:11:57 <stevebaker> its only on stack delete, which is not so bad
20:12:09 <sdake> stack still deleeteable?
20:12:14 <zaneb> stevebaker: and update, which is
20:12:15 <sdake> just volume attachment leaks?
20:12:19 <shardy> sdake: agree, but that is the process, release even with bugs
20:12:33 <stevebaker> https://bugs.launchpad.net/bugs/1295536 is just a validation fix, so we can live without that
20:12:35 <uvirtbot> Launchpad bug 1295536 in heat "Heat software orchestration ignores software config is user_data_format is missing" [Medium,In progress]
20:12:42 <sdake> stevebaker is the stack still deleetable?
20:13:05 <pas-ha> sdake: only after issuing a second delete
20:13:12 <stevebaker> https://bugs.launchpad.net/bugs/1297396 has been broken forever, and asalkeld has a fix in the works
20:13:13 <uvirtbot> Launchpad bug 1297396 in heat "Nested Provider resources not found" [High,In progress]
20:13:14 <sdake> ok so workaround
20:13:15 <sdake> wfm :)
20:13:56 <stevebaker> https://bugs.launchpad.net/bugs/1301657 leads to undeletable stacks, but only if you somehow manage to delete the deployment resource first (eg, by killing heat-engine mid-delete)
20:14:00 <uvirtbot> Launchpad bug 1301657 in heat "NotFound on deployment operation returns 500 REST response" [High,In progress]
20:14:15 <stevebaker> so we can live without all 4 of those fixes
20:14:26 <zaneb> pas-ha: in the bad old days, issues like this could result in you never being able to delete the stack no matter how many times you call delete. hence the question
20:14:29 <tspatzier__> stevebaker: re #1295536 -> the last patch set that nanjj posted should be in line with all review comments. Looks like this could go in.
20:14:35 <sdake> the only one that concerns me at all is the volume attach
20:14:53 <stevebaker> tspatzier__: it could, but we're likely out of time
20:14:55 <pas-ha> sdake: attach works perfectly
20:15:23 <sdake> pas-ha just to clarify, a heat delete stackx heat deletestackx is the recommended workaround?
20:15:42 <stevebaker> #topic Icehouse release notes
20:16:09 <pas-ha> sdake: I might be confused now, which one worked on which version ..
20:16:11 <stevebaker> we need to populate https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#OpenStack_Orchestration_.28Heat.29
20:16:17 <pas-ha> will retest tomorrow to verify
20:16:27 <stevebaker> #link https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#OpenStack_Orchestration_.28Heat.29
20:16:41 <skraynev> sdake: I don't like attach, because of the old  problem with mountpoint (which does not work correctly)
20:16:59 <shardy> stevebaker: I'll write a wiki page we can link wrt upgrade notes for stack domain users
20:17:05 <stevebaker> I have some bullet points as a start here https://etherpad.openstack.org/p/heat-icehouse-release-notes
20:17:11 <stevebaker> #link https://etherpad.openstack.org/p/heat-icehouse-release-notes
20:17:34 <stevebaker> shardy: that would be great
20:18:07 <stevebaker> If you see any missing key new features then please add them
20:18:38 <radix> the abandon/adopt stack stuff is pretty unfortunate
20:18:50 <stevebaker> abandon works
20:18:51 <radix> does it at least not have any security issues left?
20:19:10 <zaneb> I wouldn't include the Proof-of-concept Docker resource
20:19:21 <zaneb> it doesn't prove any non-obvious concepts
20:19:37 <sdake> zaneb+1
20:19:40 <zaneb> but more importantly, it won't get packaged or installed by default
20:19:47 <shardy> radix: there are multiple issues remaining, unfortunately
20:20:01 <stevebaker> I think adopt needs a rethink anyway, it requires coordination between the abandoning heat and the adopting heat so that compute resources can get the new endpoints and credentials
20:20:29 <stevebaker> I think we should be quite open about the current limitations of stack-update
20:20:45 <shardy> stevebaker: +1 I think there's probably a better design we can potentially discuss at summit
20:20:53 <sdake> ya we should tell folks "if your update fails, your fked" :)
20:21:05 <pas-ha> shardy: +1
20:21:06 <randallburt> sdake:  :(
20:21:12 <stevebaker> saying something like you can use it, but you need to be able to recover from any issues by deleting your stack
20:21:15 <radix> that's going to be a big juno focus :)
20:21:18 <shardy> stevebaker: therve also correctly pointed out that all of the paths get invalidated when the stack id changes, so everything breaks in the instance atm
20:21:37 <randallburt> stevebaker:  so lets mark adopt as experimental/ WiP for Icehoust?
20:21:43 <stevebaker> lets call adopt a preview feature
20:21:46 <zaneb> sdake: unless you enabled rollback... but if *that* fails...
20:21:55 <randallburt> stevebaker:  sounds good to me
20:21:59 <zaneb> stevebaker: +1
20:22:00 <shardy> stevebaker: +1
20:22:08 <skraynev> stevebaker: +1
20:22:11 <sdake> zaneb i htink we should keep it simple
20:22:14 <pas-ha> stevebaker: +1
20:22:15 <sdake> stevebaker +1
20:22:28 <zaneb> sdake: I think we should encourage people to enable rollback ;)
20:22:33 <radix> is it documented how to enable/disable it for operators?
20:22:37 <sdake> zaneb that wfm
20:22:41 <radix> (adopt I mean)
20:22:43 <stevebaker> ok, I'll bash away on those release notes, but any help would be appreciated
20:22:59 <radix> it seems to me a preview feature shouldn't be enabled by default
20:23:01 <pas-ha> zaneb: then why make it default on stack-create?
20:23:03 <stevebaker> #topic Heat security page
20:23:10 <stevebaker> #link http://lists.openstack.org/pipermail/openstack-dev/2014-April/032046.html
20:23:17 <stevebaker> #link https://wiki.openstack.org/wiki/Security/Icehouse/Heat
20:23:21 <stevebaker> #link https://wiki.openstack.org/wiki/Security/Icehouse/Keystone
20:23:25 <sdake> would prefer that stored in git
20:23:30 <randallburt> radix:  not something Heat really supports at all (turning features on and off)
20:23:32 <shardy> radix: just disable it for everyone in the policy.json
20:23:41 <zaneb> pas-ha: I'm speaking about updates here, not about create
20:23:51 <radix> shardy: that can be used to disable adopt-stack?
20:24:14 <randallburt> radix, shardy: well, ok except for that way ;) but it still returns an unauth; the endpoint will still be there.
20:24:16 <shardy> radix: hum, actually it (ab)uses create doesn't it
20:24:20 <stevebaker> so that last link is an example of what we need to write for heat. Basically stating all the security related things about heat on a single page
20:24:29 <shardy> radix: not sure, maybe it can use a policy target rule
20:24:38 <pas-ha> zaneb: how? ther's no such option on stack-update IIRC
20:24:40 <randallburt> shardy:  yes, but I think its got its own entry in policy
20:24:42 <sdake> stevebaker was there any discussion of using git for this?
20:24:43 <skraynev> pas-ha: I don't think that changing default is good idea. Users will be surprised very much ;)
20:24:48 <sdake> that way the notes match the release
20:24:54 <zaneb> pas-ha: I believe there is
20:24:58 <shardy> randallburt: aha, Ok, then "!" then :)
20:25:01 <stevebaker> sdake: for the release notes? I don't think so
20:25:09 <sdake> stevebaker for the security page
20:25:23 <stevebaker> sdake: wiki is probably fine
20:25:25 <sdake> like a security.RST file
20:25:53 <stevebaker> once it is written it should be fairly easy to keep up to date, and there will be a new wiki page for each release
20:26:08 <sdake> cool new pwiki page per release -then wfm
20:26:15 <pas-ha> zaneb: looking on github now, doesn't seem so
20:26:23 <stevebaker> shardy: ... I wonder, could you have a crack at the first version?
20:26:30 <radix> randallburt, shardy: abandon has a thing in policy.json, but I don't see one for adopt
20:26:40 <shardy> stevebaker: sure
20:26:46 <stevebaker> shardy: since you're very much the expert ;)
20:27:08 <mspreitz> Couldn't we find some way to avoid documenting twice, once for wiki and once for git ?
20:27:26 <randallburt> radix:  k; probably follow up with vijendar.
20:27:28 <sdake> i just want it versioned, if there are separate wiki pages per release i'm good
20:28:03 <mspreitz> I like git, if there were some way to make current built version always easy to read...
20:28:06 <sdake> mspreitz given what stevebaker said, I dont see a need for git for it
20:28:10 <stevebaker> shardy: that keystone one looks like just a bunch of facts. It might be useful if we also explained all the credentials and trusts that get created, stored and propagated in various ways
20:28:42 <sdake> pretty sure once that page is written some cve's will emerge :)
20:28:59 <stevebaker> lol, better to be open ;)
20:29:03 <shardy> stevebaker: sure, I've been working on more detailed docs and blog posts etc which describe how trusts and domain users work
20:29:35 <shardy> stevebaker: working towards better stuff in our offical docs explaining it all
20:29:36 <randallburt> shardy:  you will be much loved for that.
20:30:00 <stevebaker> #topic Orchestration program and Murano
20:30:01 <shardy> randallburt: ha, unfortunately it's not as much fun as code so it takes longer ;)
20:30:06 <stevebaker> any murano folk here?
20:30:15 <ruhe> o/
20:30:17 <stevebaker> #action shardy to write first Heat security page wiki
20:30:28 <randallburt> shardy:  indeed; I've taken to dumping my doc tasks on mspreitz ;)
20:30:30 <stevebaker> #action stevebaker to start release notes etherpad
20:30:34 <shardy> randallburt: lol
20:30:59 * mspreitz looks for his invisibility cloak
20:31:19 <stevebaker> no murano?
20:31:29 <gokrokve> we are here
20:31:31 <gokrokve> Hi
20:31:31 <pas-ha> stevebaker: ruhe is here
20:31:35 <sdake> ruhe is here
20:31:37 <gokrokve> Ruhe is from murano team
20:32:27 <stanlagun> hi
20:32:38 <ruhe> stevebaker: do you want me to throw in something to discuss? or do you prefer to have heat core to continue that discussion?
20:32:54 <stevebaker> ruhe: why don't you kick of the discussion
20:33:00 <ruhe> ok
20:33:00 <sdake> rune maybe you can kick it off again since not everyone was in on that conversation
20:33:24 <ruhe> there are several reasons we wanted to have this discussion:
20:34:00 <ruhe> * murano applied for incubation. feedback from TC was that we need to communicate closer with glance and heat
20:34:20 <ruhe> * we had couple of veeeery looong threads about intersections between heat and murano
20:35:04 <ruhe> * last discussion in #heat channel raised several questions and sdake wanted to gather more heat core folks to gather their input
20:36:24 <ruhe> muranopl thread gathered a lot of input
20:36:28 <stevebaker> lets set aside glance and UI issues, since they're not our program
20:36:37 <gokrokve> If I remember correctly there were couple questions:
20:37:07 <gokrokve> workflows and their coexistence with Heat\HOT in Orchestration
20:37:33 <gokrokve> Application definitions format HOT or HOT + Murano layer
20:38:04 <randallburt> not sure what the question is around workflows
20:38:13 <sdake> zane had suggested applicaiton definitions should be HOT + workflow
20:38:14 <zaneb> gokrokve: I don't think there's any disagreement that it should be HOT + Murano layer
20:38:20 <radix> those aren't grammatically questions :)
20:38:33 <zaneb> the question for me is what the Murano layer looks like
20:38:39 <randallburt> Is the question "should the workflow service be part of the Orchestration program"?
20:39:04 <zaneb> randallburt: does it even matter?
20:39:08 <gokrokve> Yes. Thanks for rephrasing.
20:39:29 <randallburt> zaneb:  it does if we're trying to define the question we're trying to answer ;)
20:40:20 <zaneb> randallburt: lol. I meant does the answer to the question of which program to put it in even matter
20:40:26 <stevebaker> I don't think workflow has to be. it can be quite separate and it seems like we could configure any desired heat<->workflow interaction with hooks
20:40:37 <randallburt> gokrokve:  ok, in that case, that sounds reasonable.
20:40:44 <sdake> if its not in the orchestration pgorram then its not our problem, so I htikn its a fair question
20:41:11 <mspreitz> What kind of hooks, where?
20:41:31 <randallburt> zaneb:  maybe, but then what's the question around workflow and coexistence with Heat?
20:41:35 <zaneb> sdake: I think it's still OpenStack's problem, which makes it our problem, especially since we are among the better-informed to comment
20:41:56 <stanlagun> "The mission of the OpenStack Orchestration program is to create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds." This is perfect definition for Murano, Solum and workflow management
20:42:09 <zaneb> randallburt: I don't know what that's referring to either
20:42:13 <mspreitz> I mean: workflow is already in the business of calling out to things, and so it Heat, so what's new?
20:42:14 <randallburt> IMO, there's a decent case for including an OpenStack workflow service in the Orchestration program, fwiw
20:42:23 <shardy> randallburt: avoidance of wheel reinvention, and sensible integration?
20:42:41 <wirehead_> well, we probably also need to discuss Mistral then. :)
20:43:08 <shardy> I actually think it's great to get these related-but-separate projects talking
20:43:18 <sdake> zaneb why dont you share your view of how murano should be if it were implemented from scratch today
20:43:23 <stanlagun> wirehead_: yep. If Mistral is not orchestration then nobody is :)
20:43:28 <ruhe> yes, current mission statement of the orchestration program says "lifecycle" which imho includes workflows
20:43:42 <zaneb> the orchestration program vs separate program thing is just a boring bureaucratic detail relating to how OpenStack is organised, and IMO has no relevance to the discussion
20:43:43 <randallburt> shardy:  k. and agreed. one way would be to integrate it at the project level.
20:44:00 <radix> yeah, the mistral thing is another confusing elemnt
20:44:10 <zaneb> sdake: because I already did on the mailing list and it took about 100 words so my arms would get sore :)
20:44:15 <zaneb> 1000*
20:44:21 <radix> all of these words are very vague and poorly defined in relation to each other :P
20:44:22 <stevebaker> yes, I don't really see the point of discussions about what project belongs in what program, lets just solve the engineering problems
20:44:25 <gokrokve> I think sdake mentioned in ML that ALM can be a possible project in Orchestration
20:44:37 <shardy> randallburt: yeah, I guess we're still figuring out what the "program" thing means, but to me it's a way to improve communication between teams where integration is important
20:44:55 <zaneb> stevebaker: ++
20:45:37 <mspreitz> So here's a possible way to assign scope: Heat is for when we (this group of people here) can figure out how to work with models, workflow is for when the user has to be the one to do the imperative part
20:45:44 <sdake> i think we need to take it in steps, and the next logical step is workflow not ALM
20:45:48 <randallburt> fine, where it lives aside, are we trying to re-design Murano during this meeting? I thought there were some outstanding questions needing more input from core.
20:46:06 <zaneb> the program thing can be decided the day before you apply for incubation. Let's talk about what we actually want to build
20:46:14 <gokrokve> I think the real issue here is that TC has some concerns about overlap between projects. If we can show what are the borders between Heat and Murano that will be enough for TC>
20:46:41 <mspreitz> gokrokve: is the border in question the border between model-driven and imperative?
20:46:47 <ruhe> well, we could put that question different way: what parts really belong to heat. someone says - workflows can be a part of heat, others say - workflows shouldn't be in heat
20:46:52 <zaneb> gokrokve: I can't speak for the TC, obviously, but that was not the impression I got
20:47:01 <stanlagun> basically Heat, Murano and Solum address the same domain but using different approaches. All of them are important and relevant. I think that working together on team level is better here than trying to create completely independent solutions and competing with each other
20:47:07 <sdake> workflows not part of heat, part of orchestration pgoram
20:47:11 <randallburt> nor I, zaneb
20:47:19 <randallburt> sdake:  +1
20:47:25 <gokrokve> mspreitz: No. the question is what Murano does and what Heat does when user asks App Catalog to deploy and manage app.
20:47:37 <stevebaker> and it seems like heat and workflow could do a lot together, but be loosely coupled. It seems like heat templates would be a good way of representing a workflow task, so as long as the workflow engine could launch a stack an be notified of the result then we could achieve all manner of things
20:48:23 <mspreitz> gokrokve: I suggested a way to choose the answer
20:48:34 <randallburt> stevebaker:  agreed; I'd also like to be able to define a workflow in my template and heat set that up in the wf service (but not be responsible for executing said workflow)
20:48:37 <gokrokve> zaneb: If you are talking about "it is too big step to higher level...' then yes this is another TC concern
20:49:10 <zaneb> stevebaker: mostly agree, except that I don't see a reason to have a workflow resource. CloudFormation doesn't.
20:49:18 <sdake> i think the issue is murano applied for incubation without consideration for integrating with mistral
20:49:24 <stevebaker> so currently in my mind this is what a murano application is:
20:49:28 <sdake> and mistral is the next logical step, not alm
20:49:37 <randallburt> zaneb: apples/oranges as far as what Mistral proposes, though.
20:49:38 <stevebaker> 1. a collection of heat templates which represent the application
20:49:48 <stanlagun> stevebaker, it looks like you're trying to make one domain-specific language (HOT) suitable for like everything
20:49:48 <zaneb> gokrokve: what sdake just said
20:49:49 <stevebaker> 2. a collection of heat templates which represent workflow tasks
20:50:31 <stevebaker> 3. a declarative murano app definition which defines the app templates, the task templates, and the workflow which wires it all together
20:51:13 <stevebaker> stanlagun: not really. I don't think HOT should tie it all together, there needs to be something else
20:51:20 <zaneb> stevebaker: IMO (2) should be written in a Mistral DSL, not in HOT
20:51:29 <zaneb> but other than that, yes
20:51:32 <randallburt> stanlagun:  I think we're trying to avoid that actually ;)
20:51:35 <ruhe> zaneb: +1
20:51:40 <sdake> zaneb+1
20:52:03 <randallburt> Mistral is declarative zaneb. It doesn't have some sort of Turing DSL last I saw. Steps are urls to hooks.
20:52:06 <ruhe> stevebaker: nice summary with correction to (2).  and i'd add 4. UI part to manage and combine apps
20:52:25 <zaneb> randallburt: great! that sounds perfect :)
20:52:27 <gokrokve> stevebaker: This pretty much what we have right now in Murano App.
20:52:31 <ruhe> yes, Mistral is declarative
20:52:32 <randallburt> zaneb:  :D
20:52:52 <gokrokve> Except 2) we don't have HOT workflows as they do not exist and we use Murano workflows for now.
20:52:59 <stevebaker> zaneb: i thought maybe the *actual* task is written in some arbitrary compute configuration format, but the task template just brings up some temporary compute resources to do it in
20:53:13 <stanlagun> Have you ever tried to write some real-life workflow in Mistral alone?
20:53:38 <randallburt> stanlagun:  no, but those are things best discussed with the Mistral team, IMO.
20:53:51 <gokrokve> Mistral assumes that actual action will be implemented in some language like python.
20:53:58 <mspreitz> ruhe: what Mistral declares is the program that the wf engine should execute, right?
20:54:00 <gokrokve> Mistrall can call hooks via URL, MQ
20:54:03 <stanlagun> Mistral has a very different use case
20:54:05 <randallburt> its a generally tricky issue and one I'm on the "lets not invent some other language" to solve.
20:54:12 <stanlagun> it is more of TaskFlow extension
20:54:14 <zaneb> stevebaker: I think this is one of those things that shouldn't commute. You'd always go Mistral -> Heat, never Heat -> Mistral
20:54:16 <randallburt> gokrokve:  that assumption is one I support.
20:54:22 <stanlagun> And it is useless without backing python code
20:54:32 <stevebaker> zaneb: I think I'm agreeing
20:54:56 <zaneb> stevebaker: then I'm confused :D
20:55:04 <randallburt> zaneb:  I disagree, but off topic again. Assuming Mistral sticks to its current design and we're not having to execute a new language in our process space.
20:55:11 <stevebaker> yeek, 5 minutes
20:55:21 <ruhe> jfyi - we also have a cross-project session submitted by ttx http://summit.openstack.org/cfp/details/1
20:55:26 * sdake puts away the popcorn
20:55:41 <skraynev> sdake: lol
20:55:42 <randallburt> yeah, gotta run to another meeting. sorry for ducking out just when it gets good.
20:55:51 * randallburt vanishes
20:55:52 <stevebaker> there was a use case on the ML about adding type interfaces to HOT so we can query glance for templates which implement a given template. It gives a nice UI workflow for launching complex apps
20:55:55 <ruhe> would be great to have a word from stevebaker or zaneb in comments for that session
20:56:50 <zaneb> stanlagun: ironically last I heard the Mistral team were refusing to use taskflow for reasons that sound very similar to Murano's reasons for not using Mistral ("tasks are written in Python")
20:57:08 <zaneb> both of which are spurious IMHO
20:57:33 <sdake> converting a dsl to a workflow in python should be fairly easy
20:57:38 <sdake> not that I'm volunteering :)
20:57:53 <stevebaker> 3 minutes
20:57:58 <ruhe> zaneb: the latest news - is they're working close with taskflow team to adopt taskflow for mistral use-cases
20:58:08 <ruhe> i don't know what you guys think about this discussion. but i found it useful and productive :)
20:58:11 <zaneb> ruhe: good to hear, thanks :)
20:58:23 <skraynev> stevebaker: and 2 points in agenda ;(
20:58:24 <stevebaker> any thoughts on type interfaces in HOT? I'm not against it
20:58:38 <gokrokve> I suggest Ruhe to summarize: questions, concerns and proposed solutions and decisions made
20:58:44 <gokrokve> And send them to ML
20:58:49 <ruhe> gokrokve: willdo!
20:58:52 <tspatzier> stevebaker: +1 on type interfaces
20:58:58 <stanlagun> zaneb, actually Mistral is using TaskFlow (or at least trying to do so). The problem there is that TaskFlow can execute any Python task while Mistral cannot. But thats completely offtop
20:59:25 <shardy> stevebaker: any examples of what type interfaces means exactly?
20:59:32 <stevebaker> where do these tasks *actually* run?
20:59:47 <mspreitz> subject line in ML to search for? for type interfaces?
21:00:05 <ruhe> shardy: you can find it in ML thread "[Heat] [Murano] [Solum] applications in the cloud"
21:00:13 <mspreitz> thanks
21:00:17 <shardy> ruhe: ah, will catch up on that, thanks
21:00:27 <stevebaker> shardy: basically a template which only has parameters and outputs. implementing templates must have the same parameters and outputs to properly implement the "type"
21:00:38 <stevebaker> #endmeeting