21:59:56 <adrian_otto> #startmeeting Solum Team Meeting
21:59:57 <openstack> Meeting started Tue Aug 19 21:59:56 2014 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:59:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:00 <openstack> The meeting name has been set to 'solum_team_meeting'
22:00:07 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-08-19_1600_UTC Our Agenda
22:00:11 <adrian_otto> #topic Roll Call
22:00:15 <adrian_otto> Adrian Otto
22:00:19 <asalkeld> o/
22:00:24 <tomblank> tom blankenship
22:00:32 <datsun180b> Ed Cranford
22:00:34 <james_li> james li
22:00:35 <PaulCzar> o/
22:00:39 <devkulkarni> devdatta kulkarni
22:00:44 <roshanagr> Roshan Agrawal
22:01:51 <adrian_otto> feel free to chime in at any time to be recorded in our attendance.
22:02:00 <adrian_otto> #topic Announcements
22:02:00 <gpilz> gil pilz
22:02:34 <adrian_otto> First, I wanted to give you all a heads-up that a project around containers in OpenStack is forming
22:02:38 <ravips> Ravi Sankar Penta
22:03:14 <adrian_otto> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/043113.html Announcement of OpenStack Containers Service
22:03:38 <devkulkarni> is this specific to Docker or any type of container?
22:03:39 <adrian_otto> it will be initially formed in Stackforge, and moved into the OpenStack Compute program once it takes form
22:03:44 <adrian_otto> any containers
22:03:46 <adrian_otto> including Docker
22:04:05 <adrian_otto> so anyone interested is encouraged to participate.
22:04:14 <adrian_otto> any other announcements from the team?
22:04:35 <adrian_otto> ok, moving right along
22:04:39 <adrian_otto> #topic Review Action Items
22:04:45 * adrian_otto adrian_otto to add discussion of Pipelines and Assembly to next meeting agenda (adrian_otto, 16:55:37)
22:04:56 <adrian_otto> status: complete. We will discuss that next
22:05:08 <adrian_otto> that was the only action item
22:05:18 <adrian_otto> #topic Pipelines and Assemblies
22:05:53 <adrian_otto> the purpose of this discussion is to drive clarity about what Pipelines will be for, and what an Assembly is for
22:06:24 <adrian_otto> the first point of confusion the team raised in our last team meeting was the rumor that we should eliminate the Assembly
22:06:57 <adrian_otto> My response to that was that a Pipeline is useful for pre-deployment and an Assembly is useful for ALM post-deployment
22:07:11 <adrian_otto> are there alternate points of view to explore and discuss?
22:07:12 <ravips> pipeline just tells the workflow from source to image but assembly holds running state of the deployed app
22:07:23 <adrian_otto> ravips: correct
22:07:28 <asalkeld> adrian_otto, i think they should be seperate
22:07:43 <adrian_otto> asalkeld: yes, we agree on taht
22:07:49 <adrian_otto> we should not conflate the two
22:08:06 <roshanagr> I have the same understanding as what Adrian and Ravi stated
22:08:10 <asalkeld> but are you suggesting we create assemblies from the pipeline?
22:08:11 <devkulkarni> not an alternate point of view, but we should discuss the relationship, if any, between the two
22:08:20 <adrian_otto> the purpose of the Assembly is to have a logical representation for a collection of components for the running applicaiton so they can be individually managed
22:08:34 <adrian_otto> the Assembly is that collection
22:09:03 <adrian_otto> whereas a Pipeline is something we use to express the process that we use to bring an application through its lifecycle
22:09:18 <asalkeld> adrian_otto, it is going to be a bit weird mixing native and camp concepts
22:09:42 <asalkeld> personally i'd rather we deal directlly with heat/murano
22:10:00 <devkulkarni> you mean heat/mistral?
22:10:25 <PaulCzar> asalkeld: so you’re suggesting that murano and heat would handle the ALM on behalf of solum ?
22:10:39 <asalkeld> devkulkarni, create mistral pipelines that talk to heat or murano
22:10:49 <asalkeld> PaulCzar, yeah
22:10:53 <asalkeld> but people can make what ever pipelines they want
22:11:32 <asalkeld> so i don't mind really as long as we don't *require* an assembly
22:11:37 <adrian_otto> you can decide to make a Pipeline that does not result in an Assembly.
22:11:50 <adrian_otto> in which case you can do exactly what you mentioned, asalkeld
22:12:01 <asalkeld> yip, this is the power of the pipeline
22:12:10 <asalkeld> you can bend it to your will
22:12:24 <devkulkarni> asalkeld: creating a pipeline to define the CI steps is fine.. the main concern for me is that the final state when an 'app' is running is not a pipeline .. but an assembly
22:12:42 <asalkeld> devkulkarni, it's not currently
22:12:47 <PaulCzar> if pipeline creates a heat stack and a murano app … then the assembly would describe the heat stack and murano app that is attached to the ‘application’  no ?
22:12:48 <asalkeld> it's a heat stack
22:12:49 <devkulkarni> well it is..
22:12:58 <tomblank> asalkeld: are you equating a heat stack with an assembly (defined above)?
22:13:00 <devkulkarni> the app url is in the pipeline
22:13:25 <asalkeld> tomblank, an assembly wraps a heat stack
22:13:31 <gpilz> the assembly resource is just a way of surfacing things
22:13:44 <asalkeld> devkulkarni, it's just in the output of one of the jobs
22:13:59 <asalkeld> it's like saying jenkins is an assembly
22:14:13 <asalkeld> because i use jenkins to start an assembly
22:14:40 <gpilz> assembly is meant to represent something that is (more or less) continually running
22:14:41 <asalkeld> devkulkarni, you see the difference?
22:15:13 <gpilz> until you do something to it - like stop it
22:15:13 <asalkeld> gpilz, sure - like a heat stack:-O
22:15:19 <gpilz> sure
22:15:41 <gpilz> what's underneath the API is irrelevant to the API
22:15:46 <adrian_otto> a Heat stack is a grouping of cloud resources. An Assembly is a grouping of application management interfaces, which may be above and beyond the Cloud Resources that make up the Heat stack.
22:16:15 <adrian_otto> if you don't have a use for an Assembly, then you don't need to create one in our Pipeline.
22:16:23 <asalkeld> adrian_otto, totally
22:16:26 <adrian_otto> s/our/your/
22:16:40 <asalkeld> sounds like we are all in agreement?
22:16:46 <asalkeld> devkulkarni,
22:16:50 <asalkeld> you happy?
22:16:57 <devkulkarni> asalkeld:
22:17:02 <devkulkarni> one question still..
22:17:03 <adrian_otto> but to suggest that we should not proceed with the project vision of ALM, and to yield that to Murano is a departure from what most contributors are expecting from Solum
22:17:13 <roshanagr> can someone summarize what we agreed on
22:17:36 <devkulkarni> in the situation that we do need an assembly, what would the last stage of a pipeline define in your view/
22:18:01 <adrian_otto> devkulkarni: who are you asking?
22:18:09 <devkulkarni> sorry
22:18:13 <devkulkarni> that was for asalkeld
22:18:15 <asalkeld> it would be a mistral plugin that talks to solum
22:18:24 <asalkeld> and creates an assembly
22:18:41 <asalkeld> (updates too)
22:19:02 <devkulkarni> and git triggers would go to assembly or a pipeline?
22:19:12 <adrian_otto> to a pipeline
22:19:12 <asalkeld> pipeline
22:19:16 <asalkeld> snap
22:19:18 <devkulkarni> probably to the first stage of a pipeline
22:19:29 <devkulkarni> okay..
22:19:43 <asalkeld> adrian_otto, I don't mind what the entity is that finally deploys and looks after it (alm) as long as it is configurable
22:19:44 <devkulkarni> roshanagr: yeah, we should summarize this.. adrian_otto you want to take a stab at it??
22:20:15 <adrian_otto> I would summarize with a set of definitions and a disposition
22:20:55 <asalkeld> for instance tripelO *might* be interested in using solum for their ci/cd at somepoint and then they would want a tuskar final stage
22:20:56 <adrian_otto> one moment and I will put up a straw man for your consideration
22:21:03 <adrian_otto> starting an etherpad to fiddle with
22:22:13 <adrian_otto> #link https://etherpad.openstack.org/p/solum-pipeline-and-assembly Pipeline and Assembly Relation Etherpad
22:22:46 <asalkeld> assembly and pipeline are getting a pad together:)
22:22:47 <devkulkarni> thanks adrian_otto .. question for all .. once adrian_otto has a etherpad, what about we work through it over the week and point out any concerns/questions and circle back on this point in the next meeting?
22:24:17 <datsun180b> sounds good
22:24:37 <datsun180b> if it's etherpad don't forget to name yourself
22:25:29 <adrian_otto> Okay, I'd consider that a pretty concise summary of the subject
22:25:31 <datsun180b> seriously, i see six "unnamed" in the top-right user list
22:27:08 <PaulCzar> for the source-to-image portion of the workflow …  does it make sense to continue working on both the plan+assembly stuff as well as the pipelines ?    This is mostly a question about the readiness of Mistral,  esp for anyone that wants to build out POC infrastructure based on solum and may not want to take on the burden of more than one very-very-pre-release projects
22:28:52 <asalkeld> PaulCzar, in my very humble opinion we need to morf assemble to it's true intennt
22:28:53 <adrian_otto> PaulCzar: that's a fair question. I have been struggling with that ever since Atlanta when we decided to pursue Mistral as a way to instrument a pluggable pipeline
22:29:16 <asalkeld> alm: not what it does now
22:29:20 <asalkeld> which is a mix
22:29:48 <asalkeld> the current state of it makes it difficult to move forward
22:29:51 <devkulkarni> adrian_otto: and what are your current thoughts?
22:30:31 <adrian_otto> I think we should further refine Solum to separate the Pipeline and Assembly resources
22:31:14 <adrian_otto> It might not require a lot of Mistral specific work to achieve that vision, although that's one approach… one that I'm currently worried about.
22:32:02 <adrian_otto> we used Assembly to hang a few things that we did not have a better place for
22:33:24 <asalkeld> adrian_otto, here is a plan:
22:33:35 <asalkeld> we make a new camp assembly
22:33:44 <asalkeld> fully camp compat
22:33:49 <devkulkarni> so starting work on separating the two resources is a good suggestion.. while that is happening though where would stuff that hangs on Assembly go while pipelines are not yet there..
22:33:52 <asalkeld> and use this for the pipeline
22:34:40 <devkulkarni> asalkeld: could you please elaborate more..
22:34:44 <asalkeld> devkulkarni, at some point we have to kill our weird version of assembles
22:35:05 <asalkeld> our assembly does tasks
22:35:10 <asalkeld> it shouldn't
22:35:15 <asalkeld> it should just deploy
22:35:37 <asalkeld> so we could (with gpilz help)
22:35:41 <adrian_otto> asalkeld: I don't see why that would not just be a sequence of iterative changes to tie code to where it best belongs
22:36:01 <adrian_otto> we are in full agreement about where task execution belongs
22:36:01 <asalkeld> make a new camp assemble
22:36:10 <devkulkarni> okay.. we define a new pipeline-assembly and do tasks there,
22:36:14 <PaulCzar> I was thinking along the lines of we keep `plan create’ and `assembly create` and extend them into being our CAMP API,  assembly create should at some stage ( post juno? ) start utilizing pre-defined piplines rather than doing the work itself,  the output of the pipeline in this case is an assembly ( heat + ALM )
22:36:18 <devkulkarni> is that the suggestion?
22:36:43 <adrian_otto> PaulCzar: yes, I like that.
22:36:53 <asalkeld> PaulCzar, that's the other way around
22:37:01 <adrian_otto> same outcome
22:37:38 <PaulCzar> asalkeld: so we have two interfaces to using solum ‘pipelines’ and ‘camp’, the latter is a wrapper around piplines
22:37:52 <asalkeld> shrug, I don't mind that
22:37:54 <ravips> +1 PaulCzar
22:38:03 <asalkeld> as long as have access to pipelines
22:38:18 <devkulkarni> yeah, I like that as well
22:38:23 <gpilz> one question: my spec says I'm going to create CAMP-compliant "assembly resource" that lives below "../camp/v1_1/" in the URL tree
22:38:27 <datsun180b> makes sense to me
22:38:30 <gpilz> should I still plan on doing that?
22:38:47 <adrian_otto> gpilz: yes.
22:38:52 <gpilz> cool
22:39:09 <PaulCzar> maybe when mistral approaches incubation stages is when we’d cut over to mistral doing the hard work and swap assembly back to being just a wrapper API
22:39:24 <devkulkarni> asalkeld: you said that was other way around.. what is your view??
22:39:26 <adrian_otto> ok, so I feel like we arrived at a point of clarity with this discussion. Do the other team members feel that way?
22:39:47 <asalkeld> devkulkarni, personally i am more interested in what pipelines can do
22:39:57 <asalkeld> not so interested in assembly
22:40:37 <adrian_otto> devkulkarni: the current tasks executed under assemblies today would be broken out into canned pipelines
22:40:38 <asalkeld> PaulCzar, the problem with that approach is the code will "rot" if no one is using it
22:40:49 <adrian_otto> so that assembly is not a workflow, and that Pipelines are.
22:41:21 <datsun180b> i think that warrants an #agreed
22:41:22 <devkulkarni> adrian_otto: sure. I thought asalkeld meant something else
22:41:35 <devkulkarni> but probably it was just that..
22:41:43 <asalkeld> devkulkarni, I did suggest some thing different
22:41:54 <asalkeld> but i am ok with this suggesting
22:42:05 <asalkeld> suggstion
22:42:10 <asalkeld> ga
22:42:11 <adrian_otto> I'm going to attempt to draft an #agreed in our etherpad
22:42:25 <devkulkarni> asalkeld: cool..
22:42:27 <adrian_otto> let's check it there before proceeding here on that
22:42:30 <devkulkarni> adrian_otto: sounds good
22:44:12 <asalkeld> go to go do the school run, later
22:44:28 <PaulCzar> if we were to move the current non-mistral workflow to pipeline and make it a configuration item solum.pipeline.workflow = legacy|mistral …and make assembly move quickly to not doing any work itself
22:44:33 <devkulkarni> later asalkeld
22:44:48 <PaulCzar> I say this, but haven’t really dug into the pipeline stuff to know if that would even make sense
22:45:19 <adrian_otto> ok, what about the draft #agreed in the etherpad?
22:45:25 <roshanagr> What would be an example of tasks that an assembly executes requiring invocation of a pipeline
22:45:30 <devkulkarni> PaulCzar: that was how it was being done.. one of the pipeline's stages would call into assembly_handler
22:45:46 <adrian_otto> roshanagr: creation of a Heat stack
22:46:01 <adrian_otto> termination of a Heat stack
22:46:10 <adrian_otto> update a heat stack
22:46:13 <datsun180b> use of the word "customer" is surprising there
22:46:31 <adrian_otto> datsun180b: adjusted
22:47:00 <roshanagr> adrian_otto: creation of a Heat stack happens prior to creation of an assembly. Updates makes sense. Thanks
22:47:00 <devkulkarni> adrian_otto: question..
22:47:01 <PaulCzar> adrian_otto: unit tests, builds, func tests would all be actioned by pipelines as well .. right ?
22:47:27 <adrian_otto> PaulCzar: yes
22:47:33 <devkulkarni> what if we separate the two points — assembly vs. pipeline and camp resources
22:47:57 <adrian_otto> devkulkarni: like that?
22:48:51 <PaulCzar> roshanagr: I think creation of the heat stack happens /during/ the creation of an assembly
22:49:00 <devkulkarni> adrian_otto: yes. also I was going suggest that we get an agreed only on the first one right now (since that was the main point for today's meeting)
22:49:16 <adrian_otto> so Solum might end up with a v2.0 API that is the CAMP one, if Solum's users prefer it.
22:49:55 <adrian_otto> devkulkarni: ok, any objections to the first #agreed in the etherpad? If not I'm happy to record that, and move through the remaining agenda items.
22:49:58 <roshanagr> PaulCzar: correct
22:50:05 <datsun180b> the second statement does seem to imply solum reserves the right to retract its camp implementation, as opposed to deprecating it
22:50:17 <adrian_otto> #vote #agreed Solum should implement tasks using Pipelines. The Assembly shall trigger Pipelines when it requires a task execution.
22:50:19 <datsun180b> oh and you've already rephrased
22:50:36 <devkulkarni> datsun180b: we are not targetting agreed for second one right now
22:50:47 <datsun180b> comprends
22:50:49 <PaulCzar> LGTM
22:50:50 <adrian_otto> devkulkarni: correct
22:50:58 <devkulkarni> adrian_otto: LGTM
22:51:10 <adrian_otto> ok, last chance to oppose
22:51:17 <datsun180b> no quarrel, looks good
22:51:28 <gpilz> +1
22:51:29 <adrian_otto> #agreed Solum shall implement tasks using Pipelines. The Assembly shall trigger Pipelines when it requires a task execution.
22:51:57 <adrian_otto> I substituted a should for a shall, hope that was ok.
22:52:15 <adrian_otto> #topic Blueprint/Task Review
22:52:28 <devkulkarni> Lets try to get ravips's patch merged..
22:52:30 <adrian_otto> any team members what to surface specific work items for discussion?
22:52:47 <adrian_otto> devkulkarni: please #link it for reference.
22:53:16 <ravips> last week blocker got merged, current blocker https://review.openstack.org/#/c/115122/ needs review/merge
22:53:17 <devkulkarni> #link https://review.openstack.org/#/c/105605/     https://review.openstack.org/#/c/115122/
22:53:38 <adrian_otto> ok, only one link per #link line please
22:53:57 <devkulkarni> #link https://review.openstack.org/#/c/105605/
22:54:07 <adrian_otto> do #link url desc (optional description goes after the url)
22:54:27 <devkulkarni> ok. #link https://review.openstack.org/#/c/105605/ (the patch)
22:54:35 <adrian_otto> ok, I have a backlog of reviews to process, but I will be sure to get to that
22:54:41 <devkulkarni> #link https://review.openstack.org/#/c/115122/ (dependency)
22:54:50 <adrian_otto> thanks devkulkarni
22:55:02 <adrian_otto> any others ?
22:55:08 <devkulkarni> there were bunch of patch for oslo config, db changes, etc.
22:55:16 <devkulkarni> these are hard to review.
22:55:26 <adrian_otto> #topic Open Discussion
22:55:30 <devkulkarni> someone want to give a short summary/description about them
22:55:48 <devkulkarni> s/patch/patches/
22:56:12 <devkulkarni> in open discussion, what are our current thoughts on mid-cycle meetup?
22:56:51 <ravips> need review for https://review.openstack.org/#/c/114704/
22:57:03 <datsun180b> oh yeah that one
22:57:04 <roshanagr> devkulkarni: I think we discussed and decided against a mid cycle meetup this time
22:57:11 <adrian_otto> devkulkarni: unless I hear suggestions to the contrary, we are planning to punt
22:57:26 <adrian_otto> as we felt sufficiently aligned and engaged.
22:57:40 <devkulkarni> ok
22:58:00 <devkulkarni> another point was, merging specs
22:58:00 <gpilz> need review on https://review.openstack.org/#/c/112153/
22:58:22 <devkulkarni> we are getting into situations where code is getting merged and the specs are not
22:58:30 <devkulkarni> noorul had raised this concern sometime back
22:58:38 <devkulkarni> as well
22:58:48 <adrian_otto> #link https://review.openstack.org/#/c/112153/ Approved Spec for CAMP API
22:58:53 <james_li> ravips: can you split Closes-Bug: #1357539, #1348759 in your commit msg as the 2nd one has no link
22:59:03 <adrian_otto> gpilz: that is in the merge process now.
22:59:07 <devkulkarni> gpilz: that will require understanding of the CAMP spec
22:59:23 <gpilz> adrian: excellent
22:59:25 <devkulkarni> does the references point to the current spec?
22:59:28 <datsun180b> seems the easiest way to enforce that the spec comes first is to -1 the Workflow of the code
22:59:30 <adrian_otto> ok, thanks for attending everyone
22:59:34 <ravips> james_li: both bugs are related and one needs another
23:00:03 <adrian_otto> next meeting is 2014-08-26 at 1600 UTC
23:00:07 <adrian_otto> #endmeeting