16:00:02 <adrian_otto> #startmeeting Solum Team Meeting
16:00:04 <openstack> Meeting started Tue Apr 15 16:00:02 2014 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:07 <openstack> The meeting name has been set to 'solum_team_meeting'
16:00:19 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-04-15_1600_UTC Our Agenda
16:00:30 <adrian_otto> #topic Roll Call
16:00:34 <adrian_otto> Adrian Otto
16:00:38 <roshanagr1> Roshan Agrawal
16:00:38 <tomblank> tom blankenship
16:00:46 <devkulkarni> Devdatta Kulkarni
16:00:51 <julienvey_> Julien Vey
16:00:54 <stannie> Pierre Padrixe
16:00:54 <coolsvap> Swapnil
16:01:05 <paulmo> Paul Montgomery
16:01:22 <muralia> murali
16:01:27 <aratim> Arati Mahimane
16:01:30 <paulczar> Paul Czarkowski!
16:02:09 <datsun180b> Ed Cranford
16:03:03 <adrian_otto> Welcome everyone. Anyone else is welcome to chime in at any time to be recorded in the meeting attendance.
16:03:15 <adrian_otto> #topic Announcements
16:03:26 <adrian_otto> New Alternating Meeting Time Vote - Vote Pending
16:03:35 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Proposed_Alternate_Meeting_Time
16:03:42 <adrian_otto> #link http://doodle.com/yma2pppk2nhwwgc8 Vote Here
16:04:03 <adrian_otto> please take a moment to visit the doodle poll, and register your input
16:04:28 <adrian_otto> you can use the (Yes) voting option to indicate that you could attend at the indicated time, but that you would rather not
16:04:49 <adrian_otto> keep in mind that the whole point in alternating the meeting time is to make it possible for others to attend who are alseep at this time
16:04:59 <adrian_otto> hi rajdeep
16:05:09 <rajdeep> hi adrian
16:05:15 <james_li> James Li
16:05:28 <devkulkarni> welcome james_li
16:05:32 <adrian_otto> hi james_li
16:05:41 <gokrokve> Georgy Okrokvertskhov o/
16:06:24 <devkulkarni> adrian_otto: when does the vote close?
16:07:09 <adrian_otto> devkulkarni: as soon as I have heard from all known contributors who reside outside the US
16:07:39 <adrian_otto> I plan to consider input from core contributors highest
16:07:43 <devkulkarni> adrian_otto: got it
16:07:46 <adrian_otto> I should say core reviewers
16:07:58 <rajdeep> can you share the voting link again?
16:08:07 <adrian_otto> irc://irc.freenode.net:6667/#link http://doodle.com/yma2pppk2nhwwgc8 Vote Here
16:08:20 <devkulkarni> looks like there is not a time that is convenient for all three (Banglore, Brisbane, Paris)
16:08:25 <adrian_otto> that was a funny cut/paste
16:08:36 <adrian_otto> devkulkarni: exactly
16:08:40 <devkulkarni> I am looking here: https://wiki.openstack.org/wiki/Meetings/Solum
16:08:50 <adrian_otto> on the Meetings wiki page I put smileys
16:09:03 <datsun180b> I'm still not clear about what my vote means for this poll
16:09:04 <devkulkarni> yep!! thanks for that. it helped
16:09:12 <adrian_otto> but as discussed before there is no time that will work for everyone
16:09:20 <julienvey> it's OK for us if we can attend at least one out of 2 meetings
16:09:48 <adrian_otto> julienvey: also I recognize that you and Pierre are pretty reachable in #solum during the US business day
16:10:07 <adrian_otto> so we can probably keep you updated on those alternating weeks of key items of interest
16:10:18 <stannie> yes that will be fine for us to assist at least to one of the meeting
16:10:24 <adrian_otto> plus we will have the meeting logs
16:11:03 <julienvey> it would be great to have Angus participate in the other one :)
16:11:25 <adrian_otto> exactly
16:11:44 <devkulkarni> datsun180b: all our votes can help in deciding the times that is convenient to those who cannot attend this one. if you plan to attend meeting other than this one then you can vote the time that is convenient for you..
16:12:14 <adrian_otto> #action adrian_otto to close the voting on the New Alternating Meeting Time Vote, and send the results to the ML
16:13:39 <adrian_otto> so, if you reside in the US, and you will NOT attend the alternating week meeting time regularly, then please vote No on the proposed meeting itme
16:13:50 <adrian_otto> I will take that into consideration when selecting
16:14:17 <adrian_otto> ok, next topic
16:14:20 <datsun180b> Understood
16:14:32 <adrian_otto> #topic Review Action Items
16:14:50 <adrian_otto> adrian_otto to propose a vote for a new meeting time for our ever-other-meeting schedule. [complete]
16:15:03 <adrian_otto> adrian_otto to follow up with paulmo to determine if https://blueprints.launchpad.net/solum/+spec/logging should be marked as Implemented [complete]
16:15:40 <adrian_otto> we will be re-scoping the remaining items in new bug/BP to be carried forward, and closing this blueprint
16:16:03 <adrian_otto> ooh, I forgot one thing about announcments
16:16:26 <adrian_otto> do any team members have other announcements they would like to share?
16:16:59 <adrian_otto> ok, next...
16:17:04 <adrian_otto> #topic Environments
16:17:23 <adrian_otto> at our meeting in Raleigh, NC we discussed the concept of Environments
16:17:49 <adrian_otto> these are abstract resources that can carry certain attributes that control how a deployment will happen
16:18:09 <adrian_otto> for example, who has access to the environment, which networks it contains, etc.
16:18:36 <adrian_otto> those attributes can be inherited by the resources that become associated with the Environment resource
16:18:57 <devkulkarni> I saw roshanagr's email and julien_vey"s comments on it. I have few comments/questions
16:19:01 <adrian_otto> this concept may be useful within Solum, but may be more widely useful beyond Solum simply as a generic OpenStack resource
16:19:06 <roshanagr1> I documented an inital set of use cases to frame the discussion: https://wiki.openstack.org/wiki/Solum/Environments
16:19:16 <adrian_otto> roshanagr1: excellent!
16:19:21 <roshanagr1> Not intending for us to review and ratify the use cases, instead to have enough shared context so that we can start discussing with the following 2 goals in mind:
16:19:39 <roshanagr1> 1. Identify the openstack projects the Environment feature is dependent on, and surface that dependency with the corresponding project teams in the Atlanta summit
16:19:51 <devkulkarni> roshanagr1: in the email you mentioned something about 'who should own this piece'. could you elaborate more on it?
16:19:55 <roshanagr1> 2. Develop a POV on which program the Environments feature should live under [Solum, Heat, or elsewhere]
16:20:13 <roshanagr1> @devkulkarni: that is goal 2
16:20:28 <roshanagr1> should it live within Solum. or Heat, or elsewhere
16:21:00 <rajdeep> i had one question on policy
16:21:05 <devkulkarni> that assumes the view that an environment is a heat stack
16:21:14 <devkulkarni> which I don't think we have really agreed to
16:21:23 <rajdeep> where does the policy related to publishing to different environment lives?
16:21:28 <adrian_otto> devkulkarni: I do not view an Environment as a feature of a stack
16:21:29 <roshanagr1> @devkulkarni: we haven't agreed to anything yet
16:21:46 <julienvey> devkulkarni: there is a wiki page with a more technical point of view about what is an environment https://wiki.openstack.org/wiki/Solum/ApiModel
16:22:01 <roshanagr1> @rajdeep: don't know, TBD, probably keystone?
16:22:26 <adrian_otto> rajdeep: excellent question. For policies to work, each service within OpenStack wold need to be extended to support Environments.
16:22:41 <rajdeep> hmm -- i am not sure keystone supports that
16:22:54 <tomblank> roshanagr1: regarding goal 2.  Is it to create our program POV on what features are needed in existing OpenStack projects in order to support our program vision of enabling application developers and operators to easily support enviornments?
16:22:55 <paulczar> to me an environment is a logical construct that provides hints/rules to Solum on where stacks can be placed
16:22:55 <adrian_otto> so even if there is a nice clean way to express, store, and list policies, each service will need to respect them
16:22:58 <rajdeep> we are working on a policy framework called
16:23:02 <rajdeep> openstack congress
16:23:13 <roshanagr1> @tomblank:  yes
16:23:57 <rajdeep> https://wiki.openstack.org/wiki/Congress
16:24:01 <tomblank> roshanagr1: thanks...
16:24:12 <rajdeep> there is a DSL being written to define policies
16:24:25 <julienvey> rajdeep: good to know :)
16:24:53 <adrian_otto> rajdeep: thanks for sharing that with us. We should look at each concept to see where Stackers could work together.
16:24:54 <roshanagr1> @rajdeep: seems very relevant to this discussion. thanks!
16:25:46 <devkulkarni> rajdeep: who enforces these policies?
16:25:48 <roshanagr1> Environments feature will have a sependency on Keystone
16:25:49 <julienvey> I tend to agree with paulczar's vision, which is kind of what Angus described in his wiki
16:25:50 <rajdeep> thanks --
16:26:05 <roshanagr1> And Horizon
16:26:09 <roshanagr1> Probably Heat
16:26:19 <rajdeep> this policy can be enforced reactively or proactively
16:26:28 <rajdeep> depending on the use case
16:26:51 <rajdeep> in this case it could be proactive enforcement that flags voilations upfront
16:27:20 <stannie> in the wiki, does "lifecycle" means that we will use Environment as "promoted build" ?
16:27:46 <roshanagr1> lifecycle means an app can progress from Dev- >Test- >Prod
16:27:58 <roshanagr1> and a set of policy to manage that
16:28:01 <julienvey> stannie: That's how I see it
16:28:01 <stannie> when you push your app, it will be first available in Dev environment, then if we choose to promote the build, then it will be in Test, Staging, Prod etc
16:28:01 <stannie> yep
16:28:16 <devkulkarni> yes
16:28:19 <roshanagr1> stannie: yes
16:28:28 <stannie> however there should be a way to deploy in production, in case if you fix a security bug or whatever
16:28:50 <roshanagr1> stannie: good point.
16:28:58 <roshanagr1> So there would be a default policy
16:29:05 <roshanagr1> and a way to override it
16:29:08 <paulczar> stannie: would we not allow the developer to have their own workflow policy?
16:29:10 <adrian_otto> stannie: I imagine we can have an attribute in the Plan file that determines the target environment for a given assembly
16:29:19 <paulczar> some of us enjoy doing dev/test in production :D
16:29:41 <devkulkarni> stannie: yes, we should have a way to do manual deploys/promotes as well. In https://wiki.openstack.org/wiki/Solum/ApiModel we have identified it
16:29:50 <stannie> ok
16:30:19 <devkulkarni> adrian_otto: about that .. how do you envision plan file concept evolving to support environments?
16:30:20 <paulczar> I would imagine that will all become part of the workflow stuff … once we determin if that belongs in Solum or somewhere else in the Program
16:31:12 <julienvey> stannie: there is some discussion here also about lifecycles, artifacts, and DU https://review.openstack.org/#/c/84434/
16:31:47 <stannie> ow, thank you julienvey
16:31:52 <adrian_otto> devkulkarni: a single plan refers to one environment. A workflow could just use that one, or could be configured to advance over a number of Environments in the coarse of following a flow.
16:32:00 <paulczar> devkulkarni: for a simple app … you might have a plan that matches all your environments,  for a complex app you'd probably have a plan for each environment.
16:32:25 <adrian_otto> plans will *not* express workflows
16:32:37 <adrian_otto> we will have another approach for defining them
16:33:04 <adrian_otto> to begin with, we will have a few default workflows, and you can just ask for one by name
16:33:27 <adrian_otto> and later we can determine the best way to allow for detailed control to redefine custom flows.
16:33:48 <devkulkarni> so plan would essentially define: code/artificat and required resources, and we would have a separate thing to define workflows
16:33:57 <adrian_otto> yes
16:34:06 <adrian_otto> as both don't really belong in the same artifact
16:34:18 <adrian_otto> we tried that and it got exceedingly comlex
16:34:24 <adrian_otto> complex
16:34:46 <roshanagr1> adrian_otto: should we consider decoupling environment from the plan file itself, so that the same plan file can be used to deploy to multiple environments?
16:34:57 <rajdeep> i think trying to get into workflows will deviate us from the core use case
16:35:16 <rajdeep> we should just add hooks for workflow engines to be plugged in
16:35:17 <devkulkarni> yep, makes sense. then the question would be what could be used to define the workflows. some thoughts that asalkeld and I had discussed were zuul, mistral, jenkins.
16:35:22 <adrian_otto> roshanagr1: perhaps. Are you thinking that it would be cast as a parameter?
16:35:40 <roshanagr1> @adrian_otto: possibly
16:35:58 <roshanagr1> if I push my code+plan file from branch 1, deploy to dev
16:36:05 <adrian_otto> I suppose we could sue a parameter, with a default value
16:36:10 <roshanagr1> if push from branch 2, deploy to test
16:36:24 <roshanagr1> yes
16:36:33 <adrian_otto> s/sue/use/ my fingers are not working well this morning
16:36:47 <julienvey> devkulkarni: Jenkins has its own "Promotion" plugin. I think mistral would be a good option but we should investigate
16:37:24 <adrian_otto> ok, so let's determine what we will do next with Environments
16:37:31 <adrian_otto> should we form a working group for it?
16:37:35 <julienvey> roshanagr1: that's not a very common git workflow
16:37:45 <adrian_otto> does it make sense to do that now, or start in Atlanta?
16:37:48 <tomblank> adrian_otto: +1 on working group
16:38:01 <julienvey> +1, we can start now I think
16:38:06 <tomblank> i would suggest we start now
16:38:10 <roshanagr1> +1 for working group.
16:38:27 <roshanagr1> we need to have a POV before going to the Atlanta summit
16:38:27 <adrian_otto> ok, do we have a volunteer to chair the working group?
16:38:38 <roshanagr1> I can do that
16:38:44 <adrian_otto> roshanagr1: thanks
16:39:09 <adrian_otto> I will assign you an AI to schedule a series of meetings to get further input from contributors
16:39:16 <adrian_otto> sound ok?
16:39:19 <roshanagr1> yes
16:40:03 <julienvey> roshanagr1: agree that a POV would be good to have
16:40:07 <adrian_otto> #action roshanagr1 to propose a working group, and schedule a recurring series to get input from contributors, and iterate on a plan for adding Environments as a feature to Solum and/or OpenStack
16:40:11 <roshanagr1> please let me know who all would want to be part of the working group and  I will setup a doodle poll
16:40:26 <devkulkarni1> roshanagr1: count me in
16:40:32 <julienvey> roshanagr1: count me in too
16:40:36 <tomblank> me too...
16:40:39 <adrian_otto> roshanagr1: I will attend
16:40:45 <rajdeep> count me in too
16:40:57 <roshanagr1> thanks, will do.
16:41:00 <rajdeep> if time is suitable
16:41:02 <tomblank> and while i don't want to speak for him, i believe Angus will want to attend
16:41:13 <roshanagr1> tomblank: yes
16:41:20 <devkulkarni1> yep. I would say lets speak for him and count him in too :D
16:41:27 <adrian_otto> looks like a healthy number of Stackers, I suggest a doodle poll to schedule it, as we did with previous working groups.
16:41:51 <roshanagr1> @adrian_otto: I will setup the doodle poll
16:41:53 <adrian_otto> ok, I want to only spend a few minutes on the next tipic
16:42:06 <adrian_otto> #topic Mission Statement Review
16:42:19 <adrian_otto> has everyone had a chance to submit their thoughts in the etherpad?
16:42:26 <adrian_otto> #link https://etherpad.openstack.org/p/solum-mission Mission Drafts
16:42:38 <adrian_otto> if not, please take some time to get your thoughts in there
16:42:49 <adrian_otto> I'd like to focus us into a vote for next meeting
16:43:08 <adrian_otto> anyone think we need more discussion sessions?
16:43:28 <devkulkarni1> minor clarification/point
16:43:42 <adrian_otto> It's time to move from etherpad to wiki
16:43:44 <devkulkarni1> the etherpad link says 'solum-mission' but we are discussing program mission
16:43:45 <devkulkarni1> right?
16:43:52 <adrian_otto> we will have two missions
16:44:13 <adrian_otto> one for a program that covers an overall goal that may touch numerous projects
16:44:35 <adrian_otto> and another that focuses on project Solum to fit a more narrow set of ambitions
16:44:50 <roshanagr1> We also need to choose a name for the Program
16:44:59 <adrian_otto> another way to think of it is a Vision statement (for a Program)
16:45:04 <devkulkarni1> when do we draw the line? do we go to Atlanta with both the statements?
16:45:08 <adrian_otto> and a Mission Statement (for a Project)
16:45:50 <adrian_otto> I expect in Atlanta we will decide when it makes sense to propose an OpenStack program
16:46:09 <devkulkarni1> ok
16:46:10 <adrian_otto> one possibility is I can take our mission, and complete an applciation
16:46:26 <adrian_otto> and we can iterate on that when we regroup in Atlanta in May
16:46:42 <devkulkarni1> application for program you mean?
16:46:47 <adrian_otto> another possibility is we can start looking at this each week until then, refining it further
16:46:55 <adrian_otto> devananda: yes, for a program
16:47:11 <adrian_otto> that's the more important initiative, I think
16:47:22 <adrian_otto> as multiple projects may form under that
16:47:46 <adrian_otto> there is also a chance that some existing efforts that don't fit nicely under any existing program might prefer this one to being out in the ether
16:47:47 <devkulkarni1> my vote will be to complete the application with what we have (which has shaped up great, I feel)
16:50:21 <adrian_otto> ok
16:50:32 <adrian_otto> #topic Review Blueprints: https://launchpad.net/solum/+milestone/milestone-1
16:50:40 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/deploy-workflow Workflow outlining deployment of a DU (asalkeld/devdatta-kulkarni)
16:50:54 <adrian_otto> should this be marked as Implemented?
16:51:18 <julienvey> adrian_otto: yes
16:51:26 <devkulkarni1> yes. datsun180b has the latest.
16:51:51 <datsun180b> considering we've been successfully deploying our ghost and ex1 apps for a while i say stick a fork in it
16:51:53 <adrian_otto> it's already marked accordingly
16:52:05 <datsun180b> well there you go
16:52:18 <adrian_otto> #action adrian_otto to drop https://blueprints.launchpad.net/solum/+spec/deploy-workflow from the weekly agenda
16:52:30 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-git-pull Pull integration of Solum from an external Git repo (kraman)
16:52:33 <paulczar> it's nonfunctional in master …  but the workflow is complete
16:52:42 <aratim> This one is nearing completion. Code is in place and functional tests are working. I am just doing the end to end testing now.
16:52:52 <devkulkarni1> +1 aratim
16:53:00 <adrian_otto> This one is marked as Implemented
16:53:11 <adrian_otto> should we keep it on the weekly agenda?
16:53:24 <devkulkarni1> I would say, yes. at least for next week
16:53:28 <aratim> I think so. We can remove it next week
16:53:31 <adrian_otto> ok, next...
16:53:51 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/logging Logging Architecture (paulmo)
16:54:16 <adrian_otto> paulmo: as we mentioned earlier there are items in there that are out of scope
16:54:43 <adrian_otto> so I'd like to identify each and move them to tasks (wishlist bug), defects (bug) or another BP
16:54:54 <adrian_otto> we can work together on that, right?
16:54:57 <paulmo> Ok
16:55:05 <adrian_otto> anything you'd like input on from the team?
16:55:15 <paulmo> Nope, I'm good.
16:55:24 <adrian_otto> thanks!
16:55:30 <adrian_otto> #topic Open Discussion
16:55:52 <devkulkarni1> btw, in launchpad is there a way to filter bugs based on tags? how do we find all bugs which are for m1?
16:56:05 <devkulkarni1> or m2, etc.
16:56:14 <adrian_otto> devkulkarni1: I am working on that
16:56:20 <devkulkarni1> okay.
16:56:27 <adrian_otto> there is a way to view bugs in LP that belong to a milestone
16:56:46 <julienvey> devkulkarni1: for tags, you have a clickable list on the right side of the bug list
16:56:49 <devkulkarni1> yeah, that will help
16:56:52 <adrian_otto> and I am in the process of iterating the list, and getting each assigned to a milestone, or leaving them in the wishlist backlog.
16:57:10 <adrian_otto> you can click on them on the right column, just like tags work
16:57:17 <devkulkarni1> julienvey: okay. will try it.
16:57:20 <adrian_otto> and see a view by milestone
16:57:31 <adrian_otto> so that should start to get much more clear over the next couple of days
16:57:40 <devkulkarni1> +1
16:58:15 <adrian_otto> for those seeking work in the mean time, look for bugs marked as "High" or "Medium"
16:58:21 <adrian_otto> and work through those.
16:58:37 <adrian_otto> top priority is to solve defects
16:58:51 <paulczar> just want to touch on how important we place on using docker driver.     It's currently not functional in master due to some recent merges and I have a few reviews up to get it working again … but there's some conficts with other features …  for example Neutron vs Docker
16:59:07 <devkulkarni1> did we manage to get a  presentation slot in Atlanta?
16:59:11 <paulczar> so want to know if I should drop those reviews … or keep working on them
16:59:33 <adrian_otto> devkulkarni1: not yet, but we applied for this: https://www.openstack.org/blog/2014/03/call-for-proposals-open-source-openstack-summit/
16:59:41 <adrian_otto> we are awaiting a reply.
17:00:05 <adrian_otto> I will also propose a vbrownbag session for a demo
17:00:05 <devkulkarni1> paulczar: Nuetron client code merged in solum you mean?
17:00:13 <julienvey> paulczar: for the heat template, I think you should create a new template, and use this one when solum is configured with docker
17:00:28 <julienvey> paulczar: and stick with the actual one when using qcow2
17:00:36 <devkulkarni1> adrian_otto: thanks for the link
17:00:58 <paulczar> julienvey: that's what I did with the review …  I reverted basic heat template and added a neutron one with the neutron features
17:01:37 <paulczar> given the strong backing for making docker default method at the summit … I thought it made most sense for doing it that way
17:02:02 <adrian_otto> thakns everyone
17:02:05 <devkulkarni1> so we keep it then is what you are suggesting.. +1
17:02:07 <adrian_otto> #endmeeting