16:06:32 <tomblank> #startmeeting Solum Team Meeting
16:06:32 <openstack> Meeting started Tue Aug 12 16:06:32 2014 UTC and is due to finish in 60 minutes.  The chair is tomblank. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:06:35 <openstack> The meeting name has been set to 'solum_team_meeting'
16:07:10 <tomblank> Ah, adrian_otto just joined...
16:07:22 <adrian_otto> sorry for the delay
16:07:33 <openstack> adrian_otto: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:08:04 <tomblank> adrian_otto:  i went ahead and started the meeting but can end and then you can restart as chair if you want
16:08:26 <adrian_otto> let's proceed, if you are willing to do the topic switching
16:08:38 <tomblank> sure...
16:08:43 <tomblank> #topic Roll Call
16:08:49 <PaulCzar> o/
16:08:49 <adrian_otto> Adrian Otto
16:08:52 <roshanagr> Roshan Agrawal
16:08:54 <tomblank> tom blankenship
16:08:56 <ravips> Ravi Sankar Penta
16:08:57 <devkulkarni> Devdatta
16:08:58 <noorul> Noorul Islam
16:08:58 <aratim> Arati Mahimane
16:09:00 <datsun180b> Ed Cranford
16:09:00 <james_li> james li
16:09:17 <julienvey> Julien Vey
16:09:53 <tomblank> #topic Announcements
16:10:06 <adrian_otto> any announcements from the team?
16:10:57 <adrian_otto> ok, let's advance
16:11:48 <tomblank> #topic Action Items
16:14:59 <datsun180b> #link http://eavesdrop.openstack.org/meetings/solum_team_meeting/2014/solum_team_meeting.2014-08-05-22.00.html last week's minutes
16:15:34 <datsun180b> looks like ravips did already submit a ticket for keeping our wiki docs in rst
16:15:52 <ravips> yes, opened bug https://bugs.launchpad.net/solum/+bug/1355523
16:15:54 <uvirtbot> Launchpad bug 1355523 in solum "Convert solum wiki pages to RST format" [Undecided,New]
16:15:56 <adrian_otto> thanks!
16:16:01 <tomblank> ravips: thanks!
16:16:18 <tomblank> #topic Blueprint/Task Review
16:16:39 <adrian_otto> #link https://launchpad.net/solum/+milestone/juno-2 Juno Development Tasks
16:16:52 <adrian_otto> I am planning on curring the .2 release today
16:16:57 <adrian_otto> *cutting
16:17:14 <adrian_otto> is there anything we should arrange to merge before then?
16:17:30 <devkulkarni> #link https://wiki.openstack.org/wiki/Meetings/Solum agenda — if anyone is looking for it
16:17:42 <devkulkarni> adrian_otto: what are the main features being released?
16:18:08 <adrian_otto> pipelines, private repos
16:18:20 <adrian_otto> I know pipelines all merged
16:18:25 <adrian_otto> did private repos get in yet?
16:18:30 <devkulkarni> no, not yet
16:18:30 <ravips> not yet
16:18:31 <datsun180b> well i'd like the logging changes for worker to get there so we can actually chase down what happens in those containers
16:18:44 <devkulkarni> +1 datsun180b
16:18:46 <datsun180b> private repos is aaaaalmost there thanks to ravi
16:18:50 <ravips> I made some more changes as per feedback from murali and Ed
16:19:07 <datsun180b> we've been testing your changes intensely ravips
16:19:09 <devkulkarni> datsun180b: could you please share the patch link for logging?
16:19:18 <adrian_otto> any chance of merging that today?
16:19:27 <ravips> we couldn't make it run on F20, james opened a bug against barbican, submitted a patch https://review.openstack.org/#/c/113404/, waiting for approval from barbiacan team
16:19:32 <adrian_otto> even if it requires putting in tech debt bugs to follow up afterward to address?
16:19:36 <datsun180b> #link https://review.openstack.org/#/c/107464/
16:19:50 <devkulkarni> adrian_otto: we might be rushing it..
16:19:57 <datsun180b> it should rebase cleanly against whatever else got in ahead of it but if not i can take care of it easily enough
16:19:58 <devkulkarni> thanks datsun180b
16:20:27 <adrian_otto> I can hold off on the release for a day or two if that would allow us to get it in
16:20:31 <gpilz> sorry i'm late
16:20:35 <adrian_otto> hi Gil
16:20:53 <devkulkarni> adrian_otto: that would help. I suggest we do that..
16:20:59 <adrian_otto> so I can cut as many releases as we want
16:21:10 <ravips> +1
16:21:11 <devkulkarni> oh okay.
16:21:18 <adrian_otto> so why don't I just cut one today with the current code, and then make a revision when we have the private repos
16:21:19 <devkulkarni> in that case you can cut one today without private repo
16:21:42 <datsun180b> sgtm
16:21:47 <devkulkarni> the next one can have private repos and Ed's logging stuff
16:21:53 <adrian_otto> right
16:22:01 <tomblank> adrian_otto: +1 for cutting another with logging and private repos
16:22:06 <devkulkarni> cool
16:22:30 <adrian_otto> #agreed Cut a release today, and a subsequent release with Logging and Private Repos added
16:22:43 <adrian_otto> tomblank: ^^ need to repeat that for the bot to notice
16:23:03 <tomblank> #agreed Cut a release today and a subsequent release with Logging and Private Repos added
16:23:32 <adrian_otto> ok, so other status about ongoing work?
16:23:50 <julienvey> I'm having some troubles with marconi in devstack
16:23:58 <julienvey> opened a bug in marconi
16:24:26 <flaper87> julienvey: we're working on that. The issue doesn't seem to be related to marconi but the openstack-common client
16:24:46 <julienvey> flaper87: oh nice, thank you :)
16:24:54 <flaper87> julienvey: mind joining #openstack-zaqar ? We'll keep you updated
16:25:06 <julienvey> flaper87: I'm on it
16:25:12 <flaper87> awesome
16:25:55 <tomblank> any other status on ongoing work?  if not, we'll move on to the next topic.
16:26:02 <adrian_otto> ok, we can switch topics to what we would all like to see included in Juno-3
16:26:10 <tomblank> #topic Feature Planning, Juno-3 (For Paris)
16:26:22 <adrian_otto> this would be anything you'd like us to be announcing in Paris.
16:26:55 <datsun180b> i bet we could swing functional tests
16:27:00 <adrian_otto> paris will be almost our 1 year project birthday
16:27:10 <julienvey> adrian_otto: we'd like to have the build farm ready
16:27:17 <devkulkarni> there was a feature roadmap that roshanagr had. are we not just following that?
16:27:34 <datsun180b> unit -> build -> functional -> deploy
16:27:40 <adrian_otto> devkulkarni: do you have a link to that handy?
16:27:45 <adrian_otto> I'm checking on it
16:27:50 <roshanagr> Did we finish everything that is currently bucketed under Jun-2 release
16:27:58 <roshanagr> https://launchpad.net/solum/+milestone/juno-2
16:28:33 <devkulkarni> roshanagr: you had a wiki as well.. do you have that link handy?
16:28:56 <adrian_otto> git, Zuul, Environmments and CI/CD events
16:29:09 <adrian_otto> those are the ones we have earmarked for Juno
16:30:02 <devkulkarni> except for git we are not there with others
16:30:30 <aratim> We can do custom language pack support
16:30:33 <adrian_otto> git push was implemented?
16:30:35 <devkulkarni> some additional things have happened instead (custom lang packs, pipelines, logging)
16:30:51 <devkulkarni> not in the sense of Solum hosting git repositories
16:31:07 <roshanagr> Roadmap wiki link: https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap
16:31:14 <devkulkarni> but more in the sense of 'users can push to their git repos' and Solum can take it from there
16:31:28 <tomblank> is Zuul integration still desired for Juno?
16:32:03 <devkulkarni> roshanagr ^^
16:32:15 <devkulkarni> my thought is, we are using Mistral
16:32:18 <devkulkarni> for workflow
16:32:40 <devkulkarni> so for now we can punt on not using Zuul for that capability
16:32:53 <tomblank> devkulkarni:  that is my thought as well but want to get other folks opinions.
16:33:26 <roshanagr> Should we run through the items parked under Juno-2 and see where we are on each
16:33:27 <adrian_otto> the reason Mistral support was added was to allow customization of the workflow
16:33:57 <adrian_otto> we would rather not duplicate functionality already present in other ecosystem projects
16:34:13 <adrian_otto> so leveraging the Mistral work to integrate Zuul would be a logical next step
16:34:54 <adrian_otto> another possibility is to show an example integration of using Jenkins for CI
16:34:58 <adrian_otto> and integrate that
16:35:46 <adrian_otto> to demonstrate that for shops that have an investment in Jenkins for CI already can leverage that, and use Solum for STI capability, and continuous deployment.
16:35:47 <devkulkarni> sure.
16:36:15 <roshanagr> STI = ?
16:36:21 <ravips> source to image
16:36:22 <tomblank> adrian_otto: on integrating jenkins.  my 2 cents is that this would be higher priority than Zuul integration.
16:36:26 <roshanagr> ok :-)
16:36:57 <adrian_otto> tomblank: +1
16:37:37 <roshanagr> + 1. Jenkins is standard in CI
16:37:43 <adrian_otto> At the time we st our sights on Zuul, we did not have something like the CI pipeline code contemplated, so we were hoping that Zuul might be an answer for that
16:37:58 <adrian_otto> I think it makes sense to swap in Jenkins for Zuul in the planning
16:38:05 <ravips> +1
16:38:11 <adrian_otto> and put Zuul back on the wishlist for now
16:38:14 <devkulkarni> +1
16:38:24 <devkulkarni> lets get an agreed on that :)
16:38:31 <adrian_otto> if someone feels strongly, and wants to bring developers to work on that, we can see about advancing the priority again
16:38:48 <adrian_otto> ok, alternate points of view before considering an #agreed
16:38:50 <adrian_otto> ?
16:39:14 <tomblank> are there other new features that anyone considers higher priority than jenkins?
16:39:33 <devkulkarni> integration with trove, lb
16:39:41 <devkulkarni> were those part of juno-2
16:39:42 <julienvey> we should be clear about what we mean by "integrating jenkins"
16:39:43 <devkulkarni> or later?
16:39:46 <PaulCzar> are we talking that we would install and run jenkins ?  or allow for an org to use their existing jenkins ?
16:39:57 <roshanagr> What "feature" would we get from Jenkins immediately?
16:39:57 <clarkb> you do get jenkins via zuul if you want to kill two birds with one stone
16:40:08 <julienvey> is it "enable already running jenkins to send notifications to solum"
16:40:17 <devkulkarni> PaulCzar: allow usage of existing Jenkins to be consumed within Solum's customizable CI
16:40:28 <julienvey> or "enable CI via Jenkins in Solum workflow"
16:40:30 <adrian_otto> roshanagr: good question. We would get the ability to add your own existing CI solution to solum
16:40:46 <adrian_otto> the feature is actually there, but this would be a way to demonstrate it
16:40:58 <roshanagr> adrian_otto: thanks !
16:41:12 <devkulkarni> clarkb: good point. imo, starting with jenkins as a first step would be easier than 'zuul + jenkins'
16:41:25 <adrian_otto> to tell the story of two CI camps: 1) I am a CI master already, let me hook up, and 2) I don't do CI yet, and I want to start.
16:41:43 <adrian_otto> most software dev shops fall into those categories today
16:42:00 <tomblank> julienvey: i think it is "enable CI via Jenkins in Solum workflow".
16:42:03 <PaulCzar> so, we would have an example mistral workflow that would call out to an external jenkins for the CI portion of the workflow for the approriate task ?
16:42:04 <roshanagr> adrian_otto: on 1) - why would an existing Jenkins CI shop want to hook up to Solum CI
16:42:16 <devkulkarni> PaulCzar: yes
16:42:34 <devkulkarni> at least thats my view
16:42:43 <PaulCzar> roshanagr: they might already be managing user/integration testing with jenkins, and want Solum to do the source->image and deploy
16:42:48 <adrian_otto> roshanagr: for continuous deployment, and creation of docker images from a hosted service
16:43:00 <PaulCzar> s/user/unit/
16:43:06 <adrian_otto> to allow portability of the output to numerous deployment targets (OpenStack, other clouds, etc.)
16:43:36 <roshanagr> adrian_otto: paulCz: thanks, get it
16:43:36 <adrian_otto> PaulCzar: exactly.
16:44:23 <adrian_otto> what about integration of APM?
16:44:48 <tomblank> any additional questions on this and are we agreed to put Zuul integration on our backlog, and replace it with a simple Jenkins integration task that shows how to connect an existing Jenkins system to Solum?
16:44:48 <adrian_otto> APM = Application Performance Monitoring. The prevailing leader here today is NewRelic
16:45:36 <devkulkarni> adrian_otto: what about it? are you asking should we pull it for Juno?
16:45:37 <roshanagr> Is APM within the scope of STI?
16:45:56 <tomblank> #agreed Put Zuul integration on our backlog, and replace it with a simple Jenkins integration task that shows how to connect an existing Jenkins system to Solum.
16:46:05 <devkulkarni> roshanagr: those two are logically two separate things, no?
16:46:22 <adrian_otto> roshanagr: no it is beyond the scope. I wonder if we might scope that out for Juno, and focus on other features.
16:46:26 <roshanagr> devkulkarni: yes, that is what I thought as well
16:46:39 <roshanagr> adrian_otto: yes
16:47:23 <devkulkarni> yes. did we have trove and load balance integration in Juno? If not, we should pull that in
16:47:34 <devkulkarni> I think that will be useful
16:47:44 <aratim> +1 devkulkarni
16:47:56 <roshanagr> Trove integration will be great.
16:48:00 <adrian_otto> devkulkarni: yes, that is listed in Milestone 2014.2.3: Juno-3
16:48:16 <devkulkarni> ok
16:48:31 <tomblank> with build farm, jenkins integration, trove, LB, CI/CD events...  that's a lot to complete prior to Juno...
16:48:53 <roshanagr> APM: my bad, the roadmap has parked it under Juno 3. I take an action item to update the roadmap wiki
16:48:55 <adrian_otto> I suggest we make a prioritized backlog of the features
16:49:00 <tomblank> but maybe i'm just being pessimestic :)
16:49:10 <PaulCzar> there’s also an interesting new project from google called cadvisor that we might want to look at integrating - https://github.com/google/cadvisor
16:49:17 <adrian_otto> and we will advance through them according to those priorities
16:49:29 <devkulkarni> tomblank: CI/CD events is a big topic. we can split it into multiple pieces and deliver them piece by piece
16:49:34 <tomblank> s/pessimestic/  Pessimistic
16:49:39 <adrian_otto> PaulCzar: let's add that to the agenda to discuss next week
16:49:57 <tomblank> devkulkarni: agreed...
16:50:07 <julienvey> have to go :( bye
16:50:11 <tomblank> adrian_otto: +1
16:50:14 <adrian_otto> ok, anyone super interested in a Juno feature that we have not yet identified?
16:50:16 <devkulkarni> PaulCzar: please give a short intro to it.
16:50:23 <devkulkarni> what is it? why we should look at it?
16:50:24 <devkulkarni> etc.
16:50:34 <tomblank> julienvey: thanks...
16:50:50 <adrian_otto> okay, we should advance to Open Discussion now
16:50:58 <tomblank> #topic Open Discussion
16:51:03 <devkulkarni> I have one topic
16:51:15 <gpilz> i have a topic
16:51:20 <devkulkarni> gpilz has been working on the CAMP API additions to Solum, which is great
16:51:38 <devkulkarni> but it requires abstractions like assembly
16:51:40 <devkulkarni> to be in place
16:51:46 <devkulkarni> I believe with pipelines
16:51:52 <gpilz> I'd like to get https://review.openstack.org/#/c/112153/ reviewed
16:51:54 <devkulkarni> we are getting rid of assembly notion
16:52:13 <adrian_otto> devkulkarni: they are mutually exclusive
16:52:16 <devkulkarni> I think gil's work won't be able to go anywhere if we get rid of assemblies
16:52:26 <adrian_otto> you don't need to use an assembly to do an STI process
16:52:39 <adrian_otto> it's for the post deployment part of the lifecycle
16:52:41 <devkulkarni> adrian_otto: yes — I would like them to be mutually exclusive
16:53:17 <adrian_otto> we should not eliminate Assemblies form the Solum API
16:53:24 <adrian_otto> but we don't need to use them for Pipelines
16:53:47 <adrian_otto> s/form/from/
16:53:58 <PaulCzar> longer term, assemblies might wrap on top of pipelines,  but I think short term we will probably need to maintain both
16:54:04 <devkulkarni> yes — as long as this is clear to everyone we should be good
16:54:33 <adrian_otto> devkulkarni: do you have suggestions on how to achieve that clarity? Are we there now, or is there more needed? What could help get there?
16:54:56 <devkulkarni> so I think we should surface this issue when asalkeld is part of the meeting
16:55:26 <gpilz> pipelines are a way of customizing how the application is built?
16:55:29 <tomblank> should we start a ML thread on this?
16:55:34 <devkulkarni> I might be wrong, but I think we all need to be on the same page with regards to pipelines and assemblies
16:55:37 <adrian_otto> #action adrian_otto to add discussion of Pipelines and Assembly to next meeting agenda
16:55:42 <PaulCzar> devkulkarni: I think the issue is that there are some people who have a vested interest in continuing to improve assembly,  even though pipline is ‘the future’
16:55:52 <tomblank> #action adrian_otto to add discussion of Pipelines and Assembly to next meeting agenda
16:55:55 <devkulkarni> PaulCzar: I disagree
16:56:01 <PaulCzar> so we need agreement from the community to continue to working on both
16:56:17 <devkulkarni> I think the notion of assembly is separate from notion of a pipeline
16:56:33 <devkulkarni> vested interest or not, they identify different levels in an application lifecyle
16:56:36 <adrian_otto> if we don't have assembly, we only have stack
16:56:46 <adrian_otto> so think on that, and we will revisit that topic next week
16:56:56 <gpilz> from a CAMP perspective an assembly represents a running application in its steady state
16:57:10 <gpilz> how it got to that steady state is not something that concerns assembly
16:57:12 <datsun180b> and we've been calling that a DU informally in solum
16:57:35 <datsun180b> at least, a deployed DU
16:57:44 <devkulkarni> personally I am more concerned with the churn
16:57:53 <adrian_otto> datsun180b: no, a du is the execution of a component of an app in the scope of a single host, not a group of hosts
16:57:54 <devkulkarni> that changes to the abstractions
16:57:56 <aratim> datsun180b: we call it an assembly
16:58:05 <roshanagr> An assembly can comprise of multiple DU's hooked together with other services
16:58:14 <adrian_otto> roshanagr: +1
16:58:16 <devkulkarni> changes to the abstractions cause in the minds of everyone
16:58:24 <datsun180b> see this is why i'm quiet
16:58:33 <gpilz> hehe
16:58:47 <adrian_otto> ok, so we have two minutes remaining for open Disucssion
16:58:57 <devkulkarni> ha ha ha
16:59:03 <gpilz> https://review.openstack.org/#/c/112153/  ?
16:59:15 <adrian_otto> gpilz: I will review it today
16:59:19 <aratim> From an end user point of view, 'solum assembly create' seems a better command than 'solum pipeline create'
16:59:21 <gpilz> do i need to get this approved before I can submit more changes?
16:59:28 <devkulkarni> +1 aratim
16:59:35 <gpilz> adrian: thanks
16:59:53 <adrian_otto> gpilz: if you want to avoid possible rework, yes
16:59:59 <adrian_otto> if you do not care about rework, no.
17:00:00 <devkulkarni> gpilz: code can be submitted before spec is merged (at least we have done that before, so should be okay)
17:00:12 <devkulkarni> submit it as a WIP
17:00:14 <adrian_otto> but leave your commits in WIP state until spec approval
17:00:16 <gpilz> i love re-work
17:00:21 <adrian_otto> thanks everyone, tom, let's end
17:00:23 <gpilz> okay
17:00:29 <tomblank> #endmeeting