16:00:29 <adrian_otto> #startmeeting containers
16:00:31 <openstack> Meeting started Tue Feb 28 16:00:29 2017 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:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:35 <openstack> The meeting name has been set to 'containers'
16:00:50 <adrian_otto> #link  Our Agenda
16:00:55 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Weekly_Containers_Team_Meeting Our Agenda
16:01:02 <adrian_otto> #topic Roll Call
16:01:04 <randallburt> o/
16:01:04 <adrian_otto> Adrian Otto
16:01:08 <swatson_> Stephen Watson
16:01:14 <mkrai_> Madhuri Kumari
16:01:18 <juggler> Perry Rivera
16:01:19 <tonanhngo> Ton Ngo
16:01:25 <yatinkarel> Yatin Karel
16:01:25 <strigazi> Spyros Trigazis
16:01:25 <jvgrant__> Jaycen Grant
16:01:27 <coreyob_> Corey O'Brien
16:01:41 <Drago> o/
16:01:54 <adrian_otto> welcome randallburt swatson_ mkrai_ tonanhngo yatinkarel strigazi jvgrant__ coreyob_ Drago and lakerzhou
16:02:58 <adrian_otto> #topic Announcements
16:03:09 <adrian_otto> 1) Fedora Atomic will be making a release tomorrow to address a kernel CVE.
16:03:23 <juggler> and juggler too? :)
16:03:37 <adrian_otto> welcome juggler!!
16:03:41 <vijendar> o/
16:03:45 <adrian_otto> sorry I missed you
16:03:47 <juggler> ok, just checking..heh
16:03:52 <adrian_otto> welcome vijendar and jasond
16:04:05 <jasond> o/
16:04:12 <adrian_otto> Dusdy Mabe joined us at the PTG from the Fedora Atomic team
16:04:18 <adrian_otto> *Dusty
16:04:50 <adrian_otto> so we were able to build stronger ties with them, and he was kind enough to let us know about the upcoming release
16:05:03 <adrian_otto> any Atomic Host quesitons?
16:05:05 <coreyob_> adrian_otto will the images for ocata and newton be rebuilt to include the CVE fix?
16:05:13 <yatinkarel> So we also need to update the image
16:05:41 <strigazi> Ocata uses a stock image
16:05:50 <strigazi> so we just point to the new one
16:05:55 <adrian_otto> yes, we will need to rebuild the Mitaka one
16:05:58 <strigazi> For newton we need a rebuild
16:06:10 <adrian_otto> and Newton
16:06:34 <strigazi> pointer to the CVE?
16:06:50 <adrian_otto> not yet
16:07:00 <adrian_otto> I'll have pointers to two CVE's at our next meting
16:07:08 <strigazi> ack
16:07:08 <adrian_otto> *meeting
16:07:35 <adrian_otto> ok, so strigazi if you have a moment to reach out to dustymabe he can help get us sorted before then.
16:07:45 <strigazi> ok
16:08:02 <adrian_otto> any more discussion on this announcement?
16:08:16 <adrian_otto> 2) We have a new policy document:
16:08:18 <adrian_otto> #link https://docs.openstack.org/developer/magnum/policies.html
16:08:27 <adrian_otto> This document details our development philosophy, links to our guiding principles and community code of conduct, as well as details about how we make decisions and manage our team. If you have not reviewed the final version yet, I ask that you please do so, as we are all expected to conform to it. Some key takeaways are: that we value incremental iterative improvement, and a willingness to merge code before it's perfect in the
16:08:27 <adrian_otto> interest of continued forward advancement. Unanimous consent is not required to reach Team Consensus. Our PTL decides when Team Consensus is reached as needed.
16:08:50 <adrian_otto> thank you to everyone who assisted with this.
16:08:54 <Gideon> Is it the forum to ask about Magnum <> Kuryr integration? Whether it planned?
16:09:03 <adrian_otto> I expect this to help us maintain a higher pace of advancement during our Pike cycle
16:09:26 <adrian_otto> Gideon: yes, we can address that in a moment during the Open Discussion section of the agenda. I will call on you.
16:09:46 <Gideon> thanks
16:10:10 <adrian_otto> Any questions about the policy document? Note that the first amendment to our policy doc will be simple rules for amending it.
16:10:56 <adrian_otto> I'm planning to make it adjustable by using a simple majority of the core reviewers using a rollcall vote, and ratification by the PTL by setting workflow+1. Thoughts on this?
16:11:11 <jvgrant__> i think that is reasonable
16:11:35 <juggler> sounds feasible
16:11:46 <adrian_otto> we could also allow a 3/4 super majority of cores to allow changes without the PTL's ratification.
16:12:34 <swatson_> Do we want a pure democracy or a republic? :)
16:12:35 <adrian_otto> if you have more ideas, you are welcome to discuss them with me and the team, in either public or private depending on your comfort level.
16:13:05 <adrian_otto> swatson_: in the spirit of the openstack governance, we are not setting up a representative democracy.
16:13:34 <adrian_otto> we are doing our best to write down unspecified expectations
16:14:22 <adrian_otto> and although not everything needs to be written down, important things that affect our team behavior should be.
16:14:31 <adrian_otto> swatson_: does that help?
16:14:46 <swatson_> adrian_otto: I'm good with that
16:14:58 <adrian_otto> so technically speaking, we have a blend of both a democracy and a republic.
16:15:18 <adrian_otto> where all decision makers are either elected, or appointed by an elected representative.
16:15:47 <adrian_otto> that concludes prepared announcements. Any more announcements from the team?
16:16:06 <strigazi> one minor
16:16:55 <adrian_otto> ok
16:16:56 <strigazi> I'll present our discussion in the PTG later today in the OpenStack France user group https://www.meetup.com/OpenStack-France/events/237544811/
16:17:19 <adrian_otto> thanks strigazi for representing us!!
16:17:30 <strigazi> people are waiting for features :)
16:17:41 <yatinkarel> Great strigazi
16:17:56 <adrian_otto> and features we plan to deliver.
16:18:18 <tonanhngo> maybe they can help prioritize
16:18:19 <adrian_otto> #topic Review Action Items
16:18:21 <adrian_otto> (none)
16:18:33 <adrian_otto> #topic Blueprints/Bugs/Reviews/Ideas
16:18:49 <adrian_otto> Essential Blueprints
16:18:53 <adrian_otto> before I ask for status on these, a few remarks...
16:19:11 <adrian_otto> these three subjects are the ones we spent the bulk of the PTG working on together as a team
16:19:45 <adrian_otto> we also performed a team retrospective, and one of the takeaways of that was that we might adjust this list
16:20:01 <adrian_otto> so that critical items were getting updates regularly every week or two
16:20:24 <adrian_otto> and items not getting updates may be downgraded if they are not truly essential
16:20:49 <adrian_otto> so here they are:
16:20:55 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/flatten-attributes Flatten Attributes [strigazi] (1/3)
16:21:25 <adrian_otto> this feature is about decoupling cluster templates from cluster resources so that you can create clusters without a template.
16:21:46 <strigazi> I picked up yesterday again, so updates next week
16:21:52 <Drago> adrian_otto: Sorry, in another meeting so I'm a bit late on this. Is there an etherpad for the retrospective?
16:21:53 <adrian_otto> ClusterTemplates act more like rubber stamps after this is done, as a convenience to users.
16:22:16 <adrian_otto> Drago: no, I did not assign a note taker, and I was on my feet that whole time
16:22:35 <adrian_otto> but I can sum it up in Open Discussion
16:23:00 <juggler> adrian_otto: please do
16:23:09 <adrian_otto> maybe we can make a retroactive etherpad then so those who were present can be sure each takeaway is recorded for posterity.
16:23:27 <yatinkarel> +1
16:23:30 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/nodegroups Nodegroups [Drago] (2/3)
16:23:56 <Drago> We didn't talk a whole lot about nodegroups, to be honest. It was mostly about hashing out cluster upgrades
16:24:02 <Drago> *at the PTG
16:24:17 <adrian_otto> yes, we focused primarily on the prerequisites
16:24:31 <adrian_otto> and on how we would handle a migration from api v1
16:24:38 <jvgrant__> Drago: we spent 3 hours on it but yeah, cluster upgrades became the higher priority
16:24:52 <strigazi> And that we start nodegroups from the backend
16:24:54 <adrian_otto> Drago: want to summarize our intent for backward compatibility in v1?
16:25:16 <Drago> Sure
16:25:44 <Drago> So we decided that until we find something that is truly backwards-incompatible with v1, we will keep adding things to v1
16:27:01 <Drago> jvgrant__: anything to add?
16:27:06 <adrian_otto> so the idea WRT nodegroups was to offer them in the v1 magnum api to the extent possible.
16:27:08 <yatinkarel> So no v2 right now?
16:27:20 <Drago> Correct
16:27:25 <jvgrant__> Drago: nope you got it
16:27:50 <yatinkarel> Drago, Ok
16:28:05 <adrian_otto> any questions about Nodegroups before I advance to the big one: Cluster Upgrades?
16:28:11 <jvgrant__> The goal for Pike was to get the backend of Nodegroups in place for existing v1 non-nodegroup clusters
16:28:30 <adrian_otto> yes.
16:28:44 <jvgrant__> if we get to it then we will start to add nodegroup api's as experimental to begin with
16:29:13 <strigazi> sounds good to me
16:29:35 <adrian_otto> any more remarks on nodegroups?
16:29:53 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/cluster-upgrades Cluster Upgrades [strigazi] (3/3)
16:30:04 <adrian_otto> now this one is the big feature for Pike
16:30:20 <randallburt> huge
16:30:24 <Drago> yuge
16:30:32 <adrian_otto> the idea is that Magnum will allow drivers to upgrade clusters in place
16:30:33 <randallburt> bigly
16:30:42 <strigazi> For this one, we will add with jvgrant__ one more bp that introduces a new resource  named Driver
16:31:22 <adrian_otto> so we designed an interface, and agreed on clear lines of demarcation for what would be global to all drivers, and what drivers own.
16:31:30 <strigazi> It will be a versioned Resource similar to what we discussed for versioned CTs
16:32:19 <strigazi> The main difference is that this is a more flexible resource
16:32:23 <adrian_otto> yes, just like strigazi explained, we will have a new API resource called Driver that will allow for different verisons of a COE to be supported by a single driver plugin (what we currently call a driver)
16:32:32 <Drago> Confusingly, you can see some details on the nodegroups etherpad https://etherpad.openstack.org/p/magnum-ptg-pike-nodegroups
16:32:49 <adrian_otto> and when a driver supports multiple versions, then it can support upgrades between them.
16:32:54 <strigazi> that allows drivers to be significantly different one to each other
16:33:00 <adrian_otto> sorry we did not make a "Driver" etherpad
16:33:11 <adrian_otto> but we will make a spec for it that makes the idea clear
16:33:17 <Gideon> Adrian I must leave, so I'll try later
16:33:26 <adrian_otto> ok Gideon
16:33:41 <yatinkarel> It looks like something on the line of Template Version spec that was earlier proposed
16:33:54 <adrian_otto> yatinkarel: astute observation!!
16:34:02 <adrian_otto> it's similar, yes.
16:34:18 <strigazi> Another important addition is the version number in cluster with a descriptive reason
16:34:49 <adrian_otto> we reached an epiphany that cluster templates really don't have anything to do with Driver versions.
16:35:15 <adrian_otto> and that the conflation of the two was making it hard for us to accept the previous proposal
16:35:41 <yatinkarel> adrian_otto, strigazi Ok
16:35:47 <adrian_otto> so this is a pivot on that idea that keeps the best of it.
16:36:27 <adrian_otto> we also had an intermediate idea that we set aside in favor of a more elegant, simpler design.
16:37:08 <adrian_otto> any questions about that?
16:37:29 <Drago> One very important difference between the Cluster Template Versions spec and the Driver resource is that Drivers can accept a config which constrains/determines which attributes can be specified during a cluster-create
16:38:18 <adrian_otto> yes, that can be unique in each driver version
16:38:22 <Drago> As opposed to simply specifying values in the Template
16:39:03 <adrian_otto> we also anticipate shrinking the current number of template attributes to a shorter list in the future
16:39:36 <Drago> adrian_otto: *cluster attributes
16:39:51 <adrian_otto> yes, cluster attributes, and corresponding template k/v pairs.
16:39:53 <Drago> Although they'll really be the same set, either way
16:40:49 <adrian_otto> any more discussion on the Cluster Upgrades feature?
16:40:49 <Drago> The idea is that with Driver configs determining the attributes exposed during a cluster-create, drivers should be able to specify what attributes they accept in general
16:41:09 <Drago> No more apiserver_port in all drivers, for instance
16:41:19 <yatinkarel> Thanks Drago adrian_otto for the summary, it looks interesting now and may be much it would be much clear when spec comes online.
16:42:01 <adrian_otto> yes, I'll also make a point about spec granularity when we get to the retrospective note taking section of our agenda
16:42:22 <adrian_otto> I saved an agenda item from last week as a reminder:
16:42:27 <adrian_otto> Other WOrk Items
16:42:34 <adrian_otto> Changing magnum projects from cycle-with-intermediary to cycle-with-milestones
16:42:49 <adrian_otto> #link https://releases.openstack.org/reference/release_models.html
16:42:59 <adrian_otto> I was seeking input on whether we should change release models. Nobody opposed that change.
16:43:19 <adrian_otto> has anyone raised any concerns about this since? If not, we can submit the patches to change this.
16:43:31 <jvgrant__> no concerns here
16:43:48 <strigazi> sounds good
16:43:55 <adrian_otto> also, I've spoken with strigazi about taking on a delegated responsibility as our release manager for Pike
16:44:15 <adrian_otto> that means he will create the release reviews, and I'll vote on them
16:44:49 <adrian_otto> but that we can make a release without my action, as needed.
16:45:09 <adrian_otto> is danil here today?
16:45:28 <adrian_otto> #topic Ocata Retrospective Note Recording
16:46:26 <adrian_otto> #link https://etherpad.openstack.org/p/magnum-ptg-pike-ocata-retrospective
16:47:55 <adrian_otto> ok, let's take a moment to build in our notes from the memory of this discussion while it is still fresh
16:49:00 <strigazi> folks, unfortunately I have to leave to make it on time for the meetup I mentioned
16:49:09 <Drago> strigazi: Good luck!
16:49:20 <juggler> take care strigazi
16:49:32 <strigazi> thanks, I'll do it in English ;-)
16:49:35 <adrian_otto> thanks strigazi !!
16:50:36 <adrian_otto> randallburt: you came up with a continue item
16:50:42 <adrian_otto> do you remember what it was?
16:52:51 <adrian_otto> I remembered. It was the format of the team meetings. ;-)
16:53:11 <adrian_otto> #topic Open Discussion
16:54:21 <Drago> adrian_otto: Was spec review meetings one?
16:54:49 <adrian_otto> it was in idea from Friday, not the retrospective
16:54:53 <adrian_otto> but I can add it here
16:55:32 <Drago> Okay, I couldn't remember
16:55:46 <adrian_otto> I added that to the start column.
16:56:01 <adrian_otto> so we have just under 5 mins remaining for Open Discussion
16:56:08 <swatson_> I wanted to bring up the topic of python-magnumclient deprecation for an openstackclient plugin solution.
16:56:21 <swatson_> I spoke to yatinkarel the other day about it and he suggested a team discussion
16:56:36 <Drago> We discussed the OSC at the PTG too
16:57:23 <swatson_> IIRC, yatinkarel brought up the idea that we might want to maintain a magnum client specifically for users while maintaining the OSC plugin
16:57:42 <adrian_otto> yes, I'm tempted to follow the patterns of several other openstack projects where we treat the OSC client as our primary one (once ready). Our very own swatson_ has graciously agreed to work on this.
16:57:46 <swatson_> I'm not sure what use cases were brought up at PTG or whether the general consensus is for deprecating python-magnumclient entirely or not
16:58:16 <adrian_otto> we should deprecate it when it becomes a burden to continue maintaining.
16:58:30 <Drago> swatson_: Our discussion wasn't around deprecating magnumclient, but how to approach OSC. All I can really remember was we decided to ask the OSC folks for guidance on what noun to use since "cluster" is taken
16:58:31 <adrian_otto> but our intent is for the osc client to be our primary
16:58:55 <swatson_> adrian_otto: OK, so bring our OSC client up to speed as it were, and maintain until it becomes painful
16:59:16 <swatson_> Drago: I spoke to dtroyer the other day in #openstack-sdks and came up with using "infra" as something of a prefix. e.g. "openstack infra cluster list"
16:59:17 <adrian_otto> swatson_: yes.
16:59:23 <yatinkarel> Yes we should move to osc as i think it is one of the openstack mission
16:59:30 <adrian_otto> I will ass this to next weeks agenda for further explaration
16:59:33 <adrian_otto> *add
16:59:34 <yatinkarel> Yes we should move to osc as i think it is one of the openstack mission
16:59:48 <adrian_otto> time for us to wrap up today
16:59:50 <Drago> "infra" doesn't sound like magnum to me
17:00:10 <adrian_otto> our next team meeting will be on 2017-03-07 at 1600 UTC in #openstack-meeting-alt
17:00:12 <swatson_> Drago: We can talk about it in #openstack-containers
17:00:16 <Drago> k
17:00:16 <juggler> wraptime
17:00:20 <yatinkarel> deprecating can be think later
17:00:21 <adrian_otto> see you there. Thanks everyone for attending.
17:00:26 <adrian_otto> #endmeeting