16:00:00 <adrian_otto> #startmeeting containers
16:00:01 <openstack> Meeting started Tue Feb 14 16:00:00 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:06 <openstack> The meeting name has been set to 'containers'
16:00:16 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2017-02-14_1600_UTC Our Agenda
16:00:20 <adrian_otto> #topic Roll Call
16:00:24 <adrian_otto> Adrian Otto
16:00:24 <strigazi> o/
16:00:25 <Drago1> o/
16:00:28 <hieulq_> o/
16:00:31 <jasond> o/
16:00:31 <jvgrant_> Jaycen Grant
16:00:32 <tonanhngo> Ton Ngo
16:00:42 <coreyob> o/
16:01:07 <adrian_otto> hello strigazi Drago1 hieulq_ jasond jvgrant_ tonanhngo coreyob and vijendar
16:01:11 <vijendar> o/
16:03:01 <randallburt> o/
16:04:12 <adrian_otto> welcome randallburt
16:04:32 <chris_hultin> o/
16:05:01 <adrian_otto> welcome chris_hultin
16:05:12 <adrian_otto> #topic Announcements
16:05:14 <adrian_otto> 1) Reminder: We will not have an IRC team meeting on 2017-02-21 because of the Atlanta PTG event.
16:05:33 <adrian_otto> 2) I made a stable branch for magnum-ui
16:05:54 <adrian_otto> we will talk about branching magnum later in this meeting
16:06:46 <adrian_otto> when https://review.openstack.org/433203 merges, that will be the branch point
16:06:48 <adrian_otto> for magnum-ui, as the translation team needs it.
16:07:18 <adrian_otto> any other announcements from the team?
16:07:33 <adrian_otto> #topic Review Action Items
16:07:35 <adrian_otto> (none)
16:07:44 <adrian_otto> #topic Blueprints/Bugs/Reviews/Ideas
16:07:50 <adrian_otto> Essential Blueprints
16:08:01 <adrian_otto> (1/3) #link https://blueprints.launchpad.net/magnum/+spec/flatten-attributes Flatten Attributes [strigazi]
16:08:03 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/flatten-attributes Flatten Attributes [strigazi]
16:09:10 <adrian_otto> strigazi: any remarks on this?
16:09:20 <strigazi> I work on finishing the cluster implementation and transactional writes/reads on the db
16:10:07 <strigazi> ^^ cluster_template is complete but I can't push separately
16:10:12 <strigazi> that's it
16:10:23 <adrian_otto> ok, any links to reviews you want the team to focus on?
16:10:48 <strigazi> It's only one review, I haven't updared last week
16:11:17 <strigazi> Ib586adb81e4bcb7e87f9b8ccd13bbbcb7cf5501f
16:11:24 <strigazi> https://review.openstack.org/#/c/395012
16:11:39 <adrian_otto> thanks strigazi
16:11:52 <adrian_otto> (2/3) Nodegroups
16:11:54 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/nodegroups Nodegroups [Drago]
16:11:58 <Drago1> The "name as positional argument" spec has merged, and jasond is working on implementation. I've pushed a new spec for the high-level approach to changing the heat templates to work with nodegroups https://review.openstack.org/433680/
16:12:30 <jvgrant_> nodegroups and nodegroup CLI specs are still up for review as well
16:12:36 <Drago1> Please give feedback. I've tried to cover things that people have been unsure about, but may not have covered everything
16:12:43 <jvgrant_> https://review.openstack.org/#/c/425431/
16:12:55 <jvgrant_> https://review.openstack.org/#/c/425422/
16:13:02 <pc_m> looking
16:13:09 <adrian_otto> thanks Drago1, jasond, and jvgrant_
16:13:13 * pc_m sorry wrong window
16:13:23 <adrian_otto> any questions/remarks form the team on these?
16:13:32 <adrian_otto> np pc_m
16:14:01 <adrian_otto> (3/3) Cluster Upgrades
16:14:02 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/cluster-upgrades Cluster Upgrades [strigazi]
16:14:21 <strigazi> I revised the spec here: https://review.openstack.org/#/c/433728/
16:15:04 <adrian_otto> great, thanks strigazi
16:15:42 <Drago1> strigazi: You still have "Request an upgrade with the cluster-update command" although in the latest rev you're adding an upgrade endpoint
16:16:09 <Drago1> My question though is will this endpoint have the same request body as update?
16:16:27 <strigazi> In the initial implementation yes
16:17:11 <adrian_otto> does that give us a way to pass enough arguments to get the upgrade behavior that's desired by the actor?
16:17:24 <Drago1> What were the reasons that update can't be used?
16:17:59 <Drago1> I am afraid we'll have significant drift between update and upgrade and it will be confusing for users to know which to use
16:18:05 <strigazi> yes, all the attributes can be passed. With the new endpoint we can add more upgrade specific params
16:18:48 <strigazi> Also upgrade will have different levels when restricting the input
16:19:37 <strigazi> update should focus in changing the size of certain params, like node-count volume size and potentially new ones
16:19:38 <Drago1> Could you add a section comparing its intent with that of update?
16:20:02 <adrian_otto> example usage might make that more clear
16:20:09 <randallburt> +1
16:20:12 <strigazi> upgrade will focus on upgrading to higher versions only and managing versions of the cluster components
16:20:54 <Drago1> We have had a long discussion on multiple update-like commands that each operate on different attributes
16:21:00 <strigazi> eg changing a driver param, network, volume is out of its context
16:23:11 <Drago1> What do you mean by a driver param?
16:23:29 <adrian_otto> so, Drago1 to clarify your POV, you are seeking differentiation from the update command, or consolidation with it?
16:24:00 <strigazi> In that discussion we concluded that update is better for an initial implementation and it's confusing to change the node-count and the version and potentially something else.
16:24:21 <Drago1> Both
16:24:49 <adrian_otto> Sorry, I don't understand.
16:24:50 <strigazi> Also how we can add option like batch-size in the update command?
16:25:12 <Drago1> I would like to see good reasons to not have everything consolidated in update
16:25:31 <adrian_otto> strigazi just cited two
16:26:21 <strigazi> Update can mean downgrade too. The most important is to add upgrade specific parameters. At the moment we have only batch-size
16:26:27 <Drago1> Especially as hardcoded constraints and logic move out of the magnum engine and into the drivers
16:26:39 <randallburt> and they're good reasons, I think it would be good to ensure they're stated in the spec
16:26:47 <adrian_otto> how about this. For stakeholders here, let's plan to work on an etherpad that expresses the potential approaches in terms of example CLI usage
16:26:51 <strigazi> randallburt ack
16:27:01 <adrian_otto> and we can use that to express the pro/con of each
16:27:09 <Drago1> randallburt: right
16:27:21 <adrian_otto> that might speed up the spec work a bit?
16:27:42 <tonanhngo> good topic for the PTG
16:27:51 <adrian_otto> agreed, tonanhngo
16:27:53 <randallburt> maybe we're jumping off the rails a bit. I think its being asked to include these examples/justifications in the spec
16:28:15 <strigazi> I'll add both option for review
16:28:45 <strigazi> s/option/options
16:28:45 <adrian_otto> strigazi: that would be helpful. Thanks.
16:28:49 <adrian_otto> any more on this topic before advancing to the next?
16:28:53 <Drago1> From a high-level, as time goes on we have more and more attributes, some of which will not be implemented by all drivers. Then to add commands that are supposed to act on specific sets of those attributes… I think it will make magnum more confusing to use
16:29:06 <Drago1> So I'd like to make sure we think about it well
16:29:11 <Drago1> That's all I have
16:29:15 <pc_m> np
16:29:16 <adrian_otto> thanks Drago1
16:29:19 <randallburt> Drago1:  very true
16:29:38 <Drago1> thanks strigazi
16:29:45 <adrian_otto> Other Work Items
16:29:51 <adrian_otto> #link https://review.openstack.org/430071 Magnum Development Policies
16:30:09 <adrian_otto> this is an effort to write down our teams expectations for how we work together
16:30:28 <adrian_otto> I anticipate posting a revision today, and would appreciate wide input from our team
16:30:54 <Drago1> I think it's looking really good
16:31:22 <adrian_otto> we can touch on it for a moment now if you like.
16:31:32 <tonanhngo> Once it's merged, it might be worthwhile to post on the ML to share with other teams.
16:32:13 <adrian_otto> Yes, there has been definite interest to taking some of the ideas and codifying them for wider use across the OpenStack ecosystem
16:32:21 <jvgrant_> agreed, the updates since last week were good. the process for handling reverting patches is a good addition
16:32:48 <adrian_otto> jvgrant_: acknowledged. It's not perfect, but it will be improved further in the next revision
16:33:26 <adrian_otto> in the spirit of the content of this policy document, I want this to be a living document that tracks us as we change what we do. If something is not working, we'll adjust and revisit it together.
16:33:46 <jvgrant_> adrian_otto: agreed. In general i like options on handling the rare exceptions instead of lots of complicated rules and definitions of all the complexities
16:34:25 <adrian_otto> yes, I think we are approaching the point where more detail won't be any more helpful :-)
16:35:04 <adrian_otto> any more remarks on this topic?
16:35:15 <adrian_otto> #topic Changing magnum projects from cycle-with-intermediary to cycle-with-milestones
16:35:26 <adrian_otto> #link https://releases.openstack.org/reference/release_models.html
16:35:59 <adrian_otto> we are currently using a cycle-with-intermediary model for magnum, python-magnumclient, and magnum-ui
16:36:23 <adrian_otto> I propose we change it to the more traditional cycle-with-milestones style, as we have been advancing in that direction.
16:36:45 <adrian_otto> what are your thoughts?
16:37:09 <randallburt> +1 for cycle-with-milestones
16:37:13 <strigazi> IMO, in practice we do cycle-with-milestones
16:37:26 <jvgrant_> +1
16:37:51 <tonanhngo> +1
16:37:52 <yatinkarel> +1
16:37:56 <adrian_otto> yes, that's the spirit of what we have started doing, so I am confident we can meet expectations with it.
16:37:57 <Drago1> It looks like we've really been using the end-of-the-cycle style
16:38:02 <randallburt> its a bit more rigour and pestering from infra and rel management, but I think its better overall to align with the bulk of openstack
16:38:09 <Drago1> Have we really had intermediary releases?
16:38:16 <Drago1> I'm +1 for milestones
16:38:16 <strigazi> Drago1 no
16:38:24 <adrian_otto> Drago1: we have done it twice in the history of the project
16:38:42 <jasond> also +1 for milestones
16:38:45 <adrian_otto> but we have not announced those releases, so
16:39:15 <strigazi> could we release the drivers separately?
16:39:28 <randallburt> the gates will be clogged at the same times anyway so might as well :)
16:39:59 <randallburt> strigazi:  probably not without breaking them out into separate repos
16:40:09 <strigazi> That was my thinking
16:40:42 <Drago1> We have lots of common code now that lb and network was abstracted
16:40:45 <randallburt> I'd be very ok with that
16:40:46 <Drago1> Not saying that's a bad thing
16:40:56 <adrian_otto> strigazi: yes randallburt is right, drivers could each have a separate repo (with the same groups presiding over them to begin with) and could have different release models each as needed.
16:41:21 <strigazi> ok
16:41:47 <randallburt> I think we'd still have a subset that tracks with the normal cycle though. we have to have known good references
16:42:45 <Drago1> If the release models are different, what do we do about the common code?
16:43:15 <Drago1> Common library? Pushing common code to each repo when it changes?
16:43:15 <adrian_otto> Drago1: I'm not sure yet
16:43:18 <strigazi> the common code is more of a core component
16:43:39 <randallburt> right, "common code" should be the driver interface and maybe the heat-based subclass.
16:43:47 <strigazi> a driver release could be useful to update to let's say k8s 1.6
16:44:03 <Drago1> randallburt: We have common templates too
16:44:07 <randallburt> and it just means we can release bugfixes and other stuff for drivers without releasing magnum
16:44:17 <randallburt> Drago1:  that will need abstracting I think
16:44:32 <Drago1> randallburt: What do you mean?
16:44:52 <randallburt> right, we'll still be beholden to the magnum releases but aren't coupled to them for driver updates is all
16:45:20 <randallburt> Drago1:  moving common dependencies other than the driver interface out
16:45:42 <adrian_otto> ok, we will regroup on this question next week as well
16:45:46 <adrian_otto> give it some thought
16:45:48 <randallburt> good idea
16:46:03 <Drago1> randallburt: Still not sure :)
16:46:13 <adrian_otto> we have three items queued for Open DIscusstion
16:46:23 <randallburt> we might could also simply consolodate the things that share a template into a single driver
16:46:45 <adrian_otto> actually two items:
16:46:46 <adrian_otto> #topic Open Discussion
16:46:47 <adrian_otto> 1) Architecture Image is Outdated on Magnum wiki: https://wiki.openstack.org/wiki/Magnum, danil has created an image(http://imgur.com/a/af5BP) which can be reviewed and magnum wiki can be updated.
16:47:23 <adrian_otto> that link has not worked for me yet
16:47:48 <adrian_otto> although our review process is suitable for source code its not great for reviewing and collaborating on image content
16:47:52 <strigazi> for me it works but it needs a small revision
16:48:09 <Drago1> I think the whole thing should be flipped right-to-left
16:48:14 <adrian_otto> so maybe what we can do for this is use an ML thread
16:48:23 <strigazi> Drago1 why?
16:48:50 <adrian_otto> so we can have the collaboration recorded, and have a muti-party discussion about it. I do agree it needs updating for sure.
16:48:53 <Drago1> So that the user flow is left-to-right
16:49:01 <strigazi> only that?
16:49:07 <Drago1> Yes
16:49:33 <adrian_otto> The last topic queued for today is:
16:49:45 <randallburt> Drago1:  +1
16:49:49 <adrian_otto> 2) When are we planning stable/ocata branch for magnum?
16:50:04 <adrian_otto> now, for reasons I am not yet allowed to disclose I have been intentionally delaying this action
16:50:14 <adrian_otto> but I can't continue to delay any longer.
16:50:23 <randallburt> other than the secret reason, can we say "now"?
16:50:45 <adrian_otto> http://paste.openstack.org/show/BqrWsYCTQKBW0gooB6VK/ Planned stable/ocata branch point
16:50:46 <adrian_otto> that's the point at which I would like to branch
16:50:51 <Drago1> Whenever ocata is released
16:50:54 <adrian_otto> there are changes that we will need to apply to the new branch as well as master
16:51:01 <randallburt> Drago1:  we branch before then
16:51:26 <Drago1> Right. Poor choice of words. Whenever ocata is ready for release
16:51:28 <Drago1> Better?
16:51:32 <randallburt> yep
16:51:34 <adrian_otto> right, so that means duplicate reviews, and some suboptimal processing while the branch is open prior to release
16:51:36 <Drago1> *magnum ocata
16:52:04 <adrian_otto> if you are confused about what to post for review on the branch, please see me.
16:52:10 <randallburt> adrian_otto:  without knowing the secret reason, its kinda hard to talk about branching then immediately backporting
16:52:14 <adrian_otto> If I am unavailable, you may also consult strigazi for guidance
16:52:45 <adrian_otto> randallburt: I wish I could be more clear about this, but I can assure you that this confusion will be temporary
16:52:48 <randallburt> sounds like a bad idea to cut the branch knowing we plan to cherry pick from the get go
16:52:48 <adrian_otto> for now, post your reviews to master
16:53:07 <adrian_otto> and yes, I will cherry pick a selection of work to the stable branch
16:53:18 <Drago1> Whatever secret thing you're doing, would it be sufficient to tag RCs?
16:53:35 <randallburt> I think we're past RC's at this point aren't we?
16:53:42 <adrian_otto> I'd rather not tag RC1 at this time
16:53:47 <adrian_otto> but I can branch.
16:53:54 <Drago1> beta?
16:54:01 <adrian_otto> yes, I can tag a beta
16:54:18 <randallburt> assuming there's sufficient justification I guess its ok to branch now and backport stuff
16:54:28 <randallburt> but certainly sub-optimal
16:54:48 <adrian_otto> yes, my other option is just to continue delaying for a bit longer
16:55:05 <adrian_otto> but that's equally disruptive for other reasons
16:55:07 <randallburt> then I'd err on making the release train happy
16:55:21 <randallburt> and branch so infra can do its things
16:56:45 <adrian_otto> so please accept my sincere apology for the lack of explanation here. I promise to clear it up as soon as I'm allowed.
16:57:40 <adrian_otto> we have a couple of minutes remaining for other open discussion before we conclude today's meeting.
16:58:50 <Drago1> Looking forward to seeing everyone at the PTG!
16:59:01 <adrian_otto> indeed!
16:59:05 <adrian_otto> Our next team meeting will be at 1600 UTC on 2017-02-28. Thanks for attending today!
16:59:18 <adrian_otto> #endmeeting