Tuesday, 2018-01-16

openstackgerritLingxian Kong proposed openstack/governance master: Qinling: Function as a Service in OpenStack  https://review.openstack.org/53382700:04
*** kumarmn has joined #openstack-tc00:06
openstackgerritLingxian Kong proposed openstack/governance master: Qinling: Function as a Service in OpenStack  https://review.openstack.org/53382700:07
*** kumarmn has quit IRC00:07
*** kong has joined #openstack-tc00:24
*** kumarmn has joined #openstack-tc00:24
*** kumarmn has quit IRC00:28
*** kumarmn has joined #openstack-tc00:29
*** kumarmn has quit IRC00:30
fungithat's mostly the position the infra team has taken on the matter in the past as well. we don't discourage people from running jobs. we do tend to zero in on disproportionate use of specific resources (usually not test node count but things like log archival) and try to help teams increase efficiency in their use of those resources00:43
*** kumarmn has joined #openstack-tc00:47
*** liujiong has joined #openstack-tc01:10
*** kumarmn has quit IRC01:27
*** liujiong has quit IRC01:39
*** liujiong has joined #openstack-tc01:41
*** kumarmn has joined #openstack-tc03:21
*** kumarmn has quit IRC03:26
*** liujiong has quit IRC03:27
*** liujiong has joined #openstack-tc03:28
*** kumarmn has joined #openstack-tc03:40
*** liujiong has quit IRC03:55
*** liujiong has joined #openstack-tc03:56
*** rosmaita has quit IRC04:23
*** SamYaple has quit IRC04:24
*** SamYaple has joined #openstack-tc04:24
*** kumarmn has quit IRC04:29
*** liujiong has quit IRC06:45
*** liujiong has joined #openstack-tc06:46
openstackgerritVasyl Saienko proposed openstack/governance master: Add networking-generic-switch-tempest-plugin under ironic  https://review.openstack.org/53418008:32
ttxTracker updated @ https://wiki.openstack.org/wiki/Technical_Committee_Tracker08:49
*** cdent has joined #openstack-tc08:49
openstackgerritMerged openstack/governance master: Remove the extra-atcs section for trove  https://review.openstack.org/53186008:56
openstackgerritMerged openstack/governance master: show deliverables in the order listed in the projects file  https://review.openstack.org/53297708:56
ttxtc-members: office hour starts09:00
cdentaw, beat me to it09:00
ttxcdent: sorry you didn't make it to the Board. The election system is quite unfavorable and random09:00
*** jpich has joined #openstack-tc09:00
cdent"disappointed but not surprised" is my current state of mind09:01
ttxspeaking of polls...09:01
cdentI agree that the election system is biased in various ways09:01
ttxwhat's the general feeling on the S poll ? mordred suggested to run it as a public poll09:01
ttx(on CIVS)09:01
cdentI think that would be fun and interesting in a way09:01
cdentthere's no particular reason why it shouldn't be public09:02
ttxHistorically we ran it on Launchpad, which was semi-public09:02
cdentbut we'll need to protect against Sooty-McSootface09:02
cdentand variants09:02
ttxcdent: ballot stuffing is the only reason not to, but as mordred said risk is limited09:02
ttxwe have safeguards in place already09:02
ttxbasically we use the vote results as long as there is no good reason (legal, marketing) not to09:03
ttx"Stupid" for example would be legal but marketing could make a good case that it's hard to market09:04
persiaIf all the options have been chosen in such a way that any is acceptable, then ballot stuffing doesn't matter.  To my mind, the best sort of election is one where it doesn't matter which is chosen, as one needs care less about ensuring the electorate makes the correct choice.09:04
ttxpersia: the list includes everything that fits the criteria. The vetting hapepns after the vote to limit the legal cost of clearing names.09:05
persiattx: Right, but from past polls, I had the impression that nearly any result would satisfy most of the polity (although some might grumble their favourite didn't win).  If Legal/Marketing needs to move to second choice due to collision, I imagine folk would grumble but accept it, etc.09:06
ttxOK, I'll propose a couple wording changes to https://governance.openstack.org/tc/reference/release-naming.html09:06
persiaThis is vastly different from the sort of poll where if the electorate votes wrong, the head of government is expected to resign.09:07
ttxAnyone interested in coordinating that ? mordred was suggesting punting to election officials but we already put a lot on their plate09:08
cdentI'm simply too far behind on everything to take on another thing :(09:09
* persia suggests calling for volunteers on the mailing list, as folk in this channel are a narrow bunch (and it's probably ideally not a current TC member)09:09
ttxbah, I'll find someone -- it's a nice/easy opportunity for someone to step up09:09
ttxstep 1 - wording change to allow public poll, 2- volunteer09:10
ttxcdent, cmurphy: any preferences in the goal list ? I think it's safe to say that the Storyboard one won't make it, but the other 3 are nice09:11
cmurphyI'm a fan of the mox one09:11
cmurphyhaving had to write mox tests for django-openstack-auth09:11
cmurphynot fun09:11
ttxyes that one is a good tech debt one09:12
persiaOn storyboard: while migrating in one cycle is unlikely, deferring past the point where the LP bug counter reaches 2000000 will cause issues with the current implementation.09:12
ttxthe other 2 are more user-visible, so that makes a good mix09:12
ttxpersia: i like dhellmann's idea of tracking the goals in SB, will force a bit of everyone to use it09:12
* persia also09:12
ttxthat can't be more painful than the current system of tracking progress through governance changes09:13
cdenti think I prefer the pagination one to the upgrade one for reasons I'll write about on the upgrade one when I get around to reviewing them for real09:13
ttxwould selecting all 3 be just too much ?09:14
cmurphythey are somewhat big goals09:15
cmurphybigger than the two we have now09:15
ttxso maybe mox+pagination would be enough. The other two are likely to be selected for S, and I'd advise the work gets started during R09:18
cdentwe could perhaps query the PTLs, see which they would prefer?09:22
cdenteven if that is just adding them to the reviews09:22
ttxcdent: yes, that's the next step. Pre-select things that we think would make good candidates, present the list and ask feedback (not just to PTLs)09:22
cdentsure, but what I mean is that we're already at a small enough set to do that09:23
ttxI would present all except the SB one09:23
cdentwe don't need to narrow further09:23
ttxthe other 3 are doable and good09:23
persia+1 on not narrowing: the SB one (and likely the upgrade one) are better removed in ML discussion from the larger list, so everyone has context about why.09:23
ttxso it's more a question of urgency and work capacity09:23
persiaTo my mind, the main reason for presenting the SB one (and then immediately arguing against) is that it was posted as the only suggested goal for some time, so many folk are aware it was nominated.09:24
ttxok. I'09:24
ttxI'll coordinate with EmilienM so that something RFC is sent to the list presenting the goals and giving a bit of context09:25
ttxIn other news, Qinling was proposed for addition to the Rocky cycle09:27
cdentvaguely related to that: have we considered what the impact of the expanded foundation focus (kata, etc.) has on project applying to be official? Do we know when/if we should be pointing applicants elsewhere in the foundation?09:30
ttxcdent: yes. I expect some things that were traditionally proposed for "OpenStack" because that was the only thing to now be proposed elsewhere09:36
ttxThe canonical example being Stackube09:36
ttxwhich, while related to openStack, was clearly not OpenStack09:36
ttxbut more of a Kubernetes distribution glue to run on top of openstack components09:37
cdentIs "uses keystone" a reasonable proxy for "being OpenStack"? I sometimes think it is, and other times think it is too broad.09:37
ttxI generally think it's too broad.09:38
cdentIn general I think if we have friendly places to direct people, we should be more rigorous in our vetting09:38
ttxIn particular we tolerated a number of "adjacent technology enablers" to be developed as a part of openstack, while it's clearly gateways to other systems09:39
ttxand imho would benefit from being seen as "on top of" openstack09:39
ttxeverything that reuses openstack components should not be called openstack imho09:40
ttxopen infrastructure can be build from Kuberenetes bits and openstack bits09:40
ttxSo if the "container infrastructure" strategic focus area picks up, I would recommend Stackube to be added there09:41
ttx+ maybe Kuryr/Fuxi09:41
ttxmoved there09:41
ttxas those are the same things: enabling container/k8s-centric deployments to make use of isolated openstack components09:42
cmurphywhat's the defining line between openstack and not openstack?09:42
cmurphyit's not clear to me why containery things are not openstack09:42
ttxWe had that discussion when Tacker was proposed. It was clearly a thing that was built on top of openstack, to translate it into NFV-compatible bits09:43
ttxThat was a close vote to accept them09:43
ttxcmurphy: I like to think that the map helps (https://www.openstack.org/openstack-map)09:46
ttxSome people deploy "openstack the product" and are all-in. Some others just reuse openstack components in a larger stack. We need to enable both09:46
ttxThe part in the map that does not follow this product approach much is the "OPENSTACK-ADJACENTENABLERS" bucket09:47
ttxThey are part of the picture because they don't have a better place to go09:48
ttxBut I think everything else "fits"09:48
ttxWe might want to be more picky as we move up and sideways, things really have to provide extra value to be included in the "product"09:49
ttxsince they extend it a bit09:50
ttxTo answer cdent's original question, yes the addition of new strategic focus areas give us the opportunity to have a bit more of a product approach in our definition of what falls in the openstack bucket.09:51
ttxRather than our traditional "whatever we produce as a community" big-tent response09:52
cmurphywe sort of need a new resolution then, don't we?09:52
ttxIt's a bit early in the process to have a definitive answer, but that's definitely something for us to work on in 201809:53
ttxSeparating the infra into its own "product of our community" will also clarify what "openstack" is09:53
ttxbecause you will notice that the map conveniently ignores it, but it's still currently a part of "openstack"09:54
ttxI like to think of openstack in terms of commonality between components too09:55
ttxbasically "an openstack service" (generally) means a number of libraries being used, API guidelines etc09:56
ttxInterestingly, it also still means Python09:58
ttx(at least in that central "openstack" bucket on the map09:59
cmurphyI would like to avoid some scenario where the deployment tools get kicked out :)09:59
ttxWith the reduction in resources we observed in 2017, sharing more practices between components sounds like a good idea10:00
ttxcmurphy: The only part of the map that feels "artificially in" to me is the adjacent enablers bucket10:01
persiaJust take care not to reduce the set of things so much that it drives additional resource constraints.10:01
ttxwe need client tools, we need operational addons, and we need deployment/lifecycle management tools.10:01
ttxThey are part of "the product" even if they are not technically user-facing cloud services10:02
ttxpersia: right10:02
ttxfocus is a double-edged sword10:03
cmurphywith Qinling that seems like it would fall into the workload provisioning bucket I think?10:05
ttxI have to do a deeper look, especially looking at dependencies. It could be seen as a form of compute too10:06
ttxThat subdivision inside the main bucket is really marketing10:06
ttxlike where Zun is placed, could have gone in worload provisioning too10:06
ttxas AWS and others promote containers and functions as primary compute resources, it /could/ go in the compute box10:07
ttxis it a raw resource, or is it a form of orchestration, or is it a specific workload ?10:08
ttxIf you look at how most public clouds market it, it's really a raw resource. "Serverless" !10:08
ttxBut I'm making things up, I really need to dive into it to see if it is what I think it is :)10:09
cdentat the level of technical development of openstack should we be letting marketing drive our grouping decisions, especially when the containing foundation has changed shape. This feels like it could be an opportunity to foist off the marketing decisions elsewhere and limit the numbrer of factors we need to concern ourselves with. (Not sure that would be a good idea, just riffing)10:12
persiaDespite my general preference for "serve the ones that come", allowing marketing to drive that seems sensible at this point.  There is a fairly active marketing mailing list, which could likely be convinced to take authoritative decisions on some matters.10:14
ttxwell, the "map" is an (opinionated) product of the Foundation at this point10:14
ttxso we as TC can definitely give input and complain about weird choices10:15
persiaBut whether a project is a good *technical* fit as "official openstack" is something for which they are unlikely to be able to render an opinion.10:15
ttxbut it's not a duty of ours to keep it up to date10:15
ttxit's just hard for everyone to agree on where things should go and how they shall be named. That's where the editorial choice comes in10:17
ttx(I personally hate the "Core functionality" bolding but it's not 100% my decision)10:17
openstackgerritThierry Carrez proposed openstack/governance master: Allow public polling to choose release names  https://review.openstack.org/53422610:24
*** kumarmn has joined #openstack-tc10:34
*** kumarmn has quit IRC10:38
*** gcb has joined #openstack-tc10:46
*** liujiong has quit IRC10:56
*** dtantsur|afk is now known as dtantsur11:00
*** kumarmn has joined #openstack-tc12:35
*** kumarmn has quit IRC12:40
*** kumarmn has joined #openstack-tc13:01
dhellmannttx, tc-members: regarding the goals discussion, I've heard from one or two projects that they'd like a little more space to work on their existing priorities this cycle. Maybe we only want to adopt one goal?13:05
*** kumarmn has quit IRC13:06
*** dtantsur is now known as dtantsur|brb13:17
*** rosmaita has joined #openstack-tc13:24
ttxdhellmann: I'd say that's the discussion we need to have on the ML. Maybe those one/two projects could end up being not impacted by one of the goal we select13:32
dhellmannthat sounds like a good approach13:34
rosmaitattx dhellmann sorry i missed tc office hours, will try to make tomorrow ... but this cycle included a hidden community goal, viz., zull3 migration that has eaten up a lot of my time trying to restore functional gates13:42
rosmaitaso i feel like we already had 3 this cycle13:42
rosmaitai woudl be in favor of at most 1 next cycle13:42
rosmaitaideally, zero13:43
rosmaitathough i understand that might send the wrong message13:43
ttxrosmaita: that's good input. we'll do a ML thread soon to discuss how many / which with the wider community, be sure to chime in13:46
rosmaitattx: will do, is it too late to propose a goal for R?13:50
dhellmannrosmaita : 3? I thought we only had 2? did glance need to address both of those?13:53
*** kumarmn has joined #openstack-tc13:56
cmurphyI think the third was the "hidden" zuul migration goal13:57
persiaMaybe it makes sense to ask the infra folk explicitly if there are any significant infra goals this cycle that might impact other projects.13:58
persiaProbably the same for interop, etc.  Essentially any group whose goals would inherently affect large proportions of the total set of project teams.13:59
dhellmanncmurphy : ah, yes, that one caught me by surprise14:03
dhellmannpersia : good idea14:03
rosmaitai should make it clear that the infra team has done a great job with the zuul3 migration and put in a lot of work to make it smooth, but this being glance, there have been some weird issues that came up and are taking up time to figure out & fix14:04
persiaOh, I've also been impressed with the infra (and specifically zuul) team's efforts to help: I just thought it would be nice to try to provide wider warning (perhaps through community goals) in the future.14:05
rosmaitapersia you are entirely correct, that wasn't a response to your comment14:06
dhellmannthat's a good point. the zuulv3 migration could have been orchestrated as a community goal.14:07
rosmaitamaybe we can make it a retroactive goal14:07
dhellmannI suspect if it had been proposed for this cycle I would have objected to it on the grounds that there was insufficient documentation for anyone not involved with writing zuul to help with the migration. Though that could have been fixed up front and we might still have done it.14:09
mordredthe zuul v3 rollout provided many lessons and I hope to never do anything like it ever again14:10
* dhellmann nods14:10
*** dtantsur|brb is now known as dtantsur14:18
*** david-lyle has quit IRC14:33
*** hongbin has joined #openstack-tc14:39
EmilienMdhellmann: it's good feedback but these projects should raise it on the ML (like ttx said)14:39
dhellmannwell, we need to take the feedback where we get it. Not everyone is comfortable "going against the grain" in a big public discussion.14:44
dhellmannespecially when the conclusion that there will be goals seems predetermined14:44
smcginnisReally good points about the zuul migration. I think that was a bigger effort than anyone realized going in to it, and it ended up consuming much more time from products than we would have thought.14:46
fungii think it was a really big effort, but i don't think any of us were deluding ourselves as to whether we could accurately guess the scope. we knew it was necessary and we knew there would be significant impact. we also knew that we wouldn't be able to quantify the impact but that hardly matters if it's something that has to get done regardless14:53
smcginnisI agree. To clarify somewhat - I don't think other projects understood the impact it was going to have. Each project had to get much more engaged and do much more work than what I think was expected.14:54
fungiwe also knew it put the infra team at considerable risk of being tarred and compressed^Wfeathered, but without a significant overhaul in our ci paradigm we wouldn't have been able to continue to scale to meet future demands of the community14:54
fungiand delaying the inevitable would only have worsened the impact14:55
fungii also think it ended up being a good choice to roll up a bunch of significant breaking changes together rather than trickle them into the community in dribs and drabs over the course of the next several years14:56
fungibut yes, i agree it ended up being similar in nature to a community-wide goal with notable impact to pretty much every team/deliverable14:57
fungithough i don't know if we could have sufficiently scoped it as a community-wide goal under the present governance framework14:58
cdentI think it went remarkably well, all things considered, and there would have been no way to predict "the right way"14:58
dhellmannfungi : sure. all of those are good points. I think the thing that was missing was really clearly communicating some of that uncertainty. Following the goal structure may have helped, if only because of the structure itself.14:58
cdentany way would have been painful14:58
ttxEmilienM: ICYMI in the backlog, in the morning we discussed goals and think we have enough goals proposed at this point. We should start the public ML discussion on which / how many. I assume you will start it (if you can't let me know and I'll pick up the task)14:58
EmilienMttx: i'll do it today14:59
ttxEmilienM: thanks!14:59
fungidhellmann: it may have, yes, though really with as many unknowns as there were (and even still are this far into it) it's hard to know when a particular deliverable has reached full parity with the jobs it had before we started15:04
fungithere's a long tail on it which may never reach 100% completion everywhere as old approaches get abandoned in parallel with jobs being fixed and/or rewritten15:05
fungiwhereas we can say that we're "mostly there" with the community as a whole being close to business as usual again15:06
dhellmannfungi: sure. as I said, I probably would have pushed to have more documentation written up front to help with the job ports to remove some of the uncertainty. and we probably would have wanted to phase it in (move projects from v2 to v3 running in parallel) though I'm sure that would have taken more effort.15:07
pabelangerI also sure it is the first time people are getting exposure to ansible too, which might not have helped keep things smooth15:22
fungithe documentation ended up needing to be retrospective in many ways anyway, since there were still a lot of unknowns going into it. if we'd pre-written much of that we would probably have ended up needing to rewrite almost all of it anyway based on things we learned during actual implementation which we never would have predicted15:24
fungithe biggest challenge is that we had provided a turing-complete framework for projects to use to define their jobs, and needed to move them all to a different turing-complete framework. a bunch of that was automatable but the body of configuration (some 20k jobs) so vast that we couldn't hope to even classify most of the corner cases15:25
fungiwe're still finding new ones in infrequently-run jobs, even months later15:26
dhellmannfungi : well, I'm still not finding helpful docs on what variables zuul defines so I know what I can use in job definitions and it's hard to find even what jobs exist already to use as bases because they're spread across several repos. That's the sort of thing I mean it would have been useful to have.15:31
dhellmannI don't discount the complexity of the change at all. It was difficult to help, though, because I didn't have enough detailed info. I'm still struggling with that (see the ongoing discussion in -infra)15:32
dhellmannpabelanger : also a good point.15:32
fungiyup, i agree it's something i struggle with too (knowing what variables zuul provides via ansible is only half the problem, knowing what variables ansible itself provides is at times a challenge to figure out as well since we didn't write it)15:34
persiaAnsible is sufficiently complex that determining variable settings is difficult even for folk that did write it.  This isn't a critique of ansible, but just the nature of very complex systems.15:35
EmilienMttx, cmurphy, cdent: while mox+pagination are good goals, they don't directly help operator's life, while upgrade goal would do.15:46
ttxEmilienM: right. pagination is more end-user-facing15:47
ttxand mox is more tech debt reduction15:47
ttxwhich is why I like all 315:48
EmilienMttx: i'm still reading backlog :)15:48
ttxon the plus side, the upgrade goal would not affect glance :)15:48
*** david-lyle has joined #openstack-tc15:49
dhellmannwould the pagination goal affect glance?16:08
dhellmannor mox?16:08
dhellmannthe mox one doesn't seem to (I don't see mox in the glance dependencies)16:08
persiarosmaita ?16:08
dhellmannalthough having 3 goals seems like a stretch16:09
rosmaitapersia: reading scrollback16:09
persiarosmaita: Mostly about dhellmann's immediate questions.16:10
dhellmannrosmaita : I was trying to get a sense of which of the goals affect you16:10
dhellmann*proposed goals16:10
rosmaitadhellmann i think we are ok on pagination, someone did a project a while back to get rid of mox, but we still have some usage, so i think only the hardest ones are left, which is good or bad depending on how you look at it16:20
rosmaitadhellmann it's probably used in glanceclient or glance_store16:20
dhellmannI would have worried if we had 3 things we wanted you to do16:20
dhellmann1 seems ok16:20
rosmaitawell, except we still haven't completed py35 and policies is looking iffy16:21
rosmaitaso i am worried about backlog16:21
dhellmannit would be good to raise those concerns on the ML so we can try to find you some help16:22
rosmaitathat is a good point16:22
EmilienMttx: update sent.16:29
*** kumarmn has quit IRC17:09
*** kumarmn has joined #openstack-tc17:21
*** kumarmn_ has joined #openstack-tc17:22
*** kumarmn has quit IRC17:26
*** jpich has quit IRC17:30
*** openstackgerrit has quit IRC17:33
*** dtantsur is now known as dtantsur|afk18:05
*** david-lyle has quit IRC18:08
*** david-lyle has joined #openstack-tc18:59
*** diablo_rojo has quit IRC19:05
*** diablo_rojo has joined #openstack-tc19:21
*** cdent has quit IRC19:24
*** harlowja has joined #openstack-tc19:44
*** david-lyle has quit IRC19:57
*** david-lyle has joined #openstack-tc19:57
*** david-lyle has quit IRC21:12
*** david-lyle has joined #openstack-tc21:23
*** diablo_rojo has quit IRC21:27
*** diablo_rojo has joined #openstack-tc21:27
*** openstackgerrit has joined #openstack-tc21:31
openstackgerritDoug Hellmann proposed openstack/governance master: update the goal process to use storyboard for tracking  https://review.openstack.org/53444321:31
*** jroll has quit IRC22:53
*** jroll has joined #openstack-tc22:58

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!