Tuesday, 2017-08-29

*** gcb has joined #openstack-tc02:50
openstackgerritFlavio Percoco proposed openstack/governance master: Drop Technical Committee meetings  https://review.openstack.org/45984804:55
*** jpich has joined #openstack-tc07:32
*** alex_xu has quit IRC08:06
*** alex_xu has joined #openstack-tc08:12
*** cdent has joined #openstack-tc08:50
openstackgerritMerged openstack/governance master: Amend leaderless program resolution timeframe  https://review.openstack.org/49257808:56
* cdent opens for business09:00
cdenttc office hours is now in session09:00
openstackgerritMerged openstack/governance master: Allow teams to host meetings in their channels  https://review.openstack.org/48511709:02
openstackgerritMerged openstack/governance master: verb-subject agreement in meeting scheduling resolution  https://review.openstack.org/49588609:02
* johnthetubaguy lurks09:06
ttxSorry was busy replying to the code complexity review09:11
ttx(best excuse ever)09:11
ttxTL;DR: being good thing to raise, but top-5 probably not the way to box it09:11
ttxWould be great to get https://review.openstack.org/#/c/498363/ merged so that we have the right PTLs listed, so please pile up +1s09:12
cdentttx yeah, I figured top 5 was simply a way to get it into a box, and then once contained, we could put it in the right place09:13
ttxcdent: anything I missed in the channel chatter by skipping next week entirely ?09:13
ttxcdent: I like the idea of having a group of people focused in making our community more accessible in general. Could be wrapped as a SIG since it's not really upstream-specific imho09:14
ttxHandling code complexity being just one aspect to it.09:14
cdentttx no, not much happened, in irc, as I recall09:14
openstackgerritJohn Garbutt proposed openstack/governance master: Top 5 idea: service layering  https://review.openstack.org/49871909:14
ttxWe could definitely produce more code walk-in blogposts/videos09:14
ttxLike an intro of the ins and outs of a cookiecutter openstack service09:15
ttxWould speed up initial dive in code09:16
johnthetubaguywould putting it in the top5 things help that all happen more quickly?09:16
ttxjohnthetubaguy: I think it's too vague to be actionable09:16
ttxmaybe once the group is set up and it's mostly struggling with manpower, it could help to be top-509:17
ttxbut without some structure, you are asking for someone to build a thing, rather than to help with a thing09:17
cdentwe did come up with some ways to make it (if we’re still talking about complexity) actionable in discussion late last week: there’s a flake8 plugin that might be useful to turn on in various places09:17
cdentif we make it adivisory, the thing we are asking for help with is lessen the output of that plugin09:18
johnthetubaguyfeels like the first action is making it more actionable? Its meta, but it raises the priority09:18
ttxcdent: feels more of a goal-thing once we can get a quantified objective09:18
johnthetubaguyso I added a similar kind of thing here: https://review.openstack.org/49871909:19
ttxlike "reduce code complexity by 20%"09:19
johnthetubaguyI would be very suspicious of anything like that myself, its more a people issue, did we make it simple enough we have the time to describe things to new comes09:20
ttxjohnthetubaguy: yeah, that also feels like a design priority / strategic goal rather than a "we are struggling in this department, please help!"09:20
cdentwell the thing that made me write something up is because I’m concerned that the current state of things is turning people away09:21
ttxMy view of top-5 things is that we should keep them for distress calls, not strategic orientations09:21
ttxalthough some things can be both09:21
cdentthat’s probably true, but I think perhaps we have an opportunity here to be far more verbose about strategic directions09:22
cdent(and I think complexity reduction should be considered tactical)09:22
cdentthe strategy is to get people to think _far_ more about maintainability09:22
ttxFor example, we have that list of 5 strategic goals from the board/tc/uc workshop09:22
cdentand “developer happiness” (whatever that is)09:22
ttxThose are communicated separately from the top-509:22
ttxSimplification, ensuring that components can be reused in other stacks...09:23
ttxThose are strategic goals09:23
ttxThe other 3 being: better communicate what is openstack, raising the next generation of leaders and closing the ops-dev feedback loop09:24
ttxSome strategic goals might be missing from that list, but I'd rather add them to that list, rather than overload our private "help needed here now!" list09:25
ttxIf only because getting board/UC input on what strategic goals are is a good idea09:26
ttxI'd like to keep the top-5 list at TC level09:26
ttxIt's for things where the TC perceives an area will die/starve if nobody helps with it09:27
ttxNot really for things the Board/TC/UC thinks OpenStack will die long-term if we don't address it09:27
cdentmy eyes are going to fall out if we don’t work more on code readability :)09:27
ttx(I don't know if I make sense)09:27
cdentyou do09:27
ttxcdent: so on code readability it's certainly on the fence, since it's so updatream-focused09:28
ttxBut John's "Improved layering" definitely sounds strategic to me09:28
ttxOne way to phrase it is that the top-5 list is hightly tactical09:29
ttxIt's really a boots-on-the-ground thing09:29
ttxMore of a "we should really turn left if we want to avoid that iceberg there" than "we should really turn left if we want to ever reach New York" type of thing09:30
cdentI think that these two things have come up, have chosen the top-5 list as a target, but missed somewnat, suggests that we need a more concrete and visible form of “stuff that matters”09:32
cdent(“but is not icebergs")09:33
cdentor more accurately: a more concrete and visible path. As we probably the things but not the shared understanding of how it all fits together09:33
ttxI think that the best forum for non-iceberg things is the strategy workshop (Board+TC+UC thing)09:35
ttxThat list of 5 things got even more widely communicated than the top-5 list09:35
cdentto whom?09:36
ttxCommunity in a large sense. Like it appeared in Summit keynotes, in openstack Days keynotes09:36
ttxin blogposts etc09:37
ttxWe also have people assigned to work on each09:37
ttxSo they are actually staffed with Board/TC/UC members at creation time09:38
ttxSo the question becomes more "what should we really do to address that strategic issue" rather than "we need help to work on this"09:38
ttxThe code complexity issue could be seen as strategic, but as part of a larger "we need to keep openstack attractive to devs" bucket09:39
* johnthetubaguy re-reads scrollback10:01
johnthetubaguycdent: I think I am wanting a way to wave the "this is important" flag, and I saw top 5 list as a way to do that, more lists of things feels bad somehow10:03
johnthetubaguycdent: that sounds a bit like what you are saying above?10:03
cdentyeah, that’s how it feels to me too10:03
cdentit doesn’t feel like we currently have a way of saying “this is important” or “this feels bad” that is … successful?10:04
johnthetubaguythat mysql debate, and the wider tested versions of dependencies, it feels like that would live on a similar list10:05
johnthetubaguythe conversation I really want, I think is, no those 5 things are pointless what we really need is these other 2 things first10:07
cdentI tend to think that part of the job of the TC should be both discovering and representing those issues because we’re suppose to be able to have that wider view and the experience to know when something is important/feels bad and is also real10:07
cdentbut at the moment I don’t feel … traction?10:08
johnthetubaguycdent: I am feeling the same thing10:08
johnthetubaguyI don't really care how we have the conversation about these things, or how we communicate them, as long as its a thing that happens10:08
* cdent gives johnthetubaguy a nice cup of tea and a biscuit10:08
* johnthetubaguy makes happy noises as he eats the biscuit10:09
johnthetubaguyI feel like we need to trigger the debate that leads to a nice list of top problems, that makes it easy for folks to tell us we are wrong10:10
johnthetubaguyits more how do we fuel that community wide discussion10:11
johnthetubaguyI find putting a best guess list down is a good starting place to kick off such discussions10:11
* cdent nods10:13
cdentthere’s a lot of fear about having “useless” or “repeated” conversations, which is a shame10:14
cdentit’s a trap!10:14
johnthetubaguyI think writing it down someone where centrally helps some10:22
johnthetubaguysometimes including someone new feels like a "useless" conversation...10:23
johnthetubaguyI duno, feel there is something missing we should try, even if its just a wiki page10:23
johnthetubaguycdent: you fancy trying to make a list of lists, with some things that need to go on a list, in a wiki page?10:23
*** dtantsur|afk is now known as dtantsur10:23
cdentonly if we can list that wiki page in some list somewhere10:24
cdent(but yes, definitely, sure)10:24
cdentI’m travelling, starting today through to the ptg, but should have some time in the gaps10:27
johnthetubaguycdent: cool, thanks10:36
johnthetubaguycdent: once we have a wiki, we can always move it to governance, or link to it from the top 5 as an overflow, etc10:36
cdentIt seems like the sort of thing (listing these kinds of things) that we should be doing as a sort of ritual10:37
johnthetubaguycdent: +110:37
johnthetubaguycdent: would be good thing to do in the PTG room10:37
cdentI am, as usual, completely overbooked on monday and tuesday10:38
cdentwant to be in several places at once10:38
johnthetubaguysame here10:39
*** dtantsur is now known as dtantsur|busy12:23
*** gcb has quit IRC12:29
*** gcb has joined #openstack-tc12:30
fungii've discovered it's possible to be in all places at once, until you're observed directly and your wave function collapses12:34
* fungi is more effective as a wave than a particle12:34
cdentI tend to become decoherent if I sustain that too long12:35
fungiprobably not enough gluons12:47
openstackgerritChandan Kumar proposed openstack/governance master: Add aodh-tempest-plugins to aodh project  https://review.openstack.org/49879812:48
* cdent give fungi a cookie12:50
smcginnisCookie time?12:54
smcginniscdent: To make things more concrete, I wonder if we try to have a release cycle goal of "All projects should have an average cyclomatic complexity of <= 700" or something. It would be a start at least.13:08
* smcginnis is just brainstorming13:08
cdentsmcginnis: you’ve got to make a good pun to get a cookie13:08
smcginnisShoot, I only make puns by accident. :)13:09
cdentA release goal could work, I suppose, but I would hope that release goals have fairly universal acceptance and it’s unclear if something like “reduce cyclomatic complexity” would not meet with resistance13:10
smcginnisYeah, chances are probably high it would.13:10
cdentI think, in the back of my mind, that I went the top 5 list path to try to do an end run around the resistors: find other people ...13:12
openstackgerritMerged openstack/project-team-guide master: Revise the format  https://review.openstack.org/48726713:32
openstackgerritMerged openstack/project-team-guide master: Document process for lib release during freeze  https://review.openstack.org/48972313:33
openstackgerritMerged openstack/project-team-guide master: Add reno usage for editing stable branch notes  https://review.openstack.org/49631813:33
fungicyclomatic complexity is also an idea many teams may meet with skepticism. i'm concerned that if we hit them with too many required goals they have a hard time seeing the value in, they'll be less inclined to work with us overall13:34
fungiso... we'd need it to be pretty convincing, and probably set the bar low in terms of amount of work involved13:34
openstackgerritMerged openstack/project-team-guide master: Move 'big tent' to history  https://review.openstack.org/48051313:34
fungilikely need to start with a complexity analysis across the entire corpus of official deliverables?13:35
fungiso that we know what a good target is without being excessively burdensome13:35
fungithough if it's something we can get buy-in for, we can consider progressively ratcheting down the target each cycle13:36
fungiso starting with a relatively high complexity limit could be a way to get teams used to continually measuring it13:37
dhellmannhttps://medium.com/@copyconstruct/small-functions-considered-harmful-91035d316c29 has an interesting take on the function complexity/length discussion13:38
fungithe other challenge i see is that we need domain-specific tools to measure it... remember that not all code in official deliverables is written in python13:38
smcginnisGood points.13:39
fungidhellmann: excellent counterarguments in that article13:39
openstackgerritDoug Hellmann proposed openstack/project-team-guide master: Add "How to Preview Release Notes at RC-time"  https://review.openstack.org/49758913:39
cdentdhellmann: that makes a good point about DRY and complexity minimization _not_ being the same thing13:40
cdentI tend to be anti-dry but pro-small13:41
fungianother way to tackle the code complexity issue is to try solutions in a limited number of deliverables for a cycle or two, where the teams doing it are convinced of the benefit, and then if it seems to be working out make a goal13:42
cdentIn typical fashion I think we’re getting overly focused on the detail of a proposed implementation (tell people to lower cyclomatic complexity) rather than the real goals, which are: make code easier to read, more maintainable, and more “accessible” to new congtributors13:42
dhellmannso how do we do that in an objective way without encouraging unnecessary code churn?13:42
cdentthis is likely because the latter is very very hard to talk about while the former is relatively easy to dismiss (if you’re a mind to)13:43
fungiso far cross-project patterns we've seen emerge successfully are ones where a few projects try something out and then others see that working out for them and want the benefits so join in. jumping straight to a cross-project goal without some indication that it's measurable, achievable and beneficial is perhaps premature13:43
dhellmannthat's very true, and that's part of why the current goals process leans so heavily on community consensus to identify goals to "finish"13:44
smcginnisI was just thinking setting a bar for a complexity measurement would be a specific thing to target to move in the right direction to the overall, non-specific, goal.13:46
smcginnisStill pondering a good way to approach this.13:46
fungiso, like, if measuring and reducing cyclomatic complexity is being seen as a potential solution to the stated concerns, try to interest some guinea pig projects in it or find ones who are already doing this and see how it's going, then do some analysis across all potentially effected projects to see what a reasonable target value might be before starting the larger discussion of making it a community13:46
smcginnisI agree it's an issue that we should address. I just don't know how.13:47
smcginnisfungi: That could be a good start.13:47
fungii don't mind discussing these problems in the abstract, but we need concrete recommendations which can be objectively evaluated across participating deliverables/teams before it's a suitable "goal" in the sense of the framework we've defined13:48
fungiso i agree with cdent that we shouldn't jump to solutions too quickly until we've got a good consensus on the problems we want to address, but once we do that we also shouldn't jump to a community goal too quickly once we think we might have some solutions13:50
fungiand definitely can't go from problems to some vague goal which nobody knows whether they're meeting or not13:52
cdentSetting some concrete measurable goals is a good thing, but what’s really (really!) needed here is cultural change, and that’s difficult to measure or delineate. It’s really more about inspriration.13:53
openstackgerritMerged openstack/project-team-guide master: Add "How to Preview Release Notes at RC-time"  https://review.openstack.org/49758913:53
fungicultural change probably needs to focus more on message and marketing, yeah13:54
fungirhetoric even13:55
ttxIn other news, I'd like to find an effective way to promote public cloud needs. the Public Cloud WG (soon to become a SIG) has a number of suggestions that I think should have more visibility @ https://docs.google.com/spreadsheets/d/1Mf8OAyTzZxCKzYHMgBl-QK_2-XSycSkOjqCyMTIedkA/edit#gid=013:55
fungigoals (in the tc cross-project goals sense) may reinforce cultural change, but they won't create it13:55
ttxThe issue being, public cloud is at the far end of the usage spectrum, not so many users, but everyone in the ecosystem needs them13:56
ttxso it's hard to expect them to "show up and do the work" as much as it is from private cloud users wanting a feature13:56
fungiseems like public cloud would have _more_ users (consumers of the end product), just fewer operators/deployers13:57
ttxsure, different def of user13:57
ttxI mean, not so many different organizations13:57
fungialso public clouds tend to have more in-house development resources, and are more likely to want to extend/fork the software13:57
fungiand do home-grown deployments13:58
ttxwe have tens of public cloud deployments and hundreds/thousands of private cloud deployments13:58
fungirather than relying on distribution vendors and support organizations13:58
ttxfungi: I think that used to be true, but most of the current public clouds have less dev resource and deploy more vanilla openstack13:59
ttxagree on not relying on distro vendors as much13:59
ttxif only because the support contract cost math just doesn't work well13:59
fungioh, fair point the ones who ran massive forks do tend to be atrophying and going extinct13:59
fungiseems like there's more of a competitive pressure on public clouds to "differentiate" themselves in what they see as a limited market14:00
ttxI think their differentiation is no longer against other openstack clouds though14:01
ttxThey present interoperability between themselves as a differentiator against AWS/Google/Azure14:01
fungithat message we tried to push years ago about banding together to take on the major proprietary players is finally catching on?14:01
ttxi.e. "no lock in"14:01
ttxLike CityCloud said they were very happy to see more European OpenStack clouds14:02
ttxsame for OVH14:02
ttxdefinitely not a zero-sum game14:02
ttxyes, the message is definitely catching on from what I hear14:03
*** marst has joined #openstack-tc14:03
ttxat least in Europe14:03
fungior if it is zero-sum, the amount of market they have the potential to draw from outside is still a significantly more than what they already have14:03
fungiso might approach zero-sum across the spectrum of openstack/aws/gce/azure/misc14:04
fungimight make sense to carve up that public cloud wishlist a bit. some entries there definitely look like "if you run a public cloud this is something missing to help you do that" while others are more along the lines of "we've had a few customers request the ability to do this"14:08
fungiself-service sign-up for example, obvious benefit to public cloud use cases14:09
fungivolume multi-attach and multiple ceph? those are more general use case support features i could see all sorts of environments wanting, nothing public-cloud-specific14:10
cdentmulti-attach, the feature that refuses to land14:12
*** marst has quit IRC14:16
fungimight make sense to qualify the list based on features most public cloud providers have cobbled together themselves but would rather not have to maintain (i.e. required for the general public cloud use case), features which reinforce interoperability/portability of workloads to help them band together against the proprietary services, and things customers have requested which would make their service14:18
fungioffering more competitive in the market14:18
*** hongbin has joined #openstack-tc14:19
ttxack, a more categorized laundry list would not hurt14:20
*** marst has joined #openstack-tc14:23
*** marst_ has joined #openstack-tc14:23
*** marst has quit IRC14:27
fungiprioritizing the laundry list is a lot harder than prioritizing specific benefits14:30
fungido we want to help public clouds gain market share from proprietary services? okay here's the list of features they'd need to make that task easier... (something about federation, vouchers, interoperability standards, stuff leveraged directly by cloud-bursting solutions...)14:31
EmilienMttx: really nice reading https://ttx.re/queens-ptg.html14:33
EmilienMttx: thanks!14:33
cdentttx (or anyone else): Are openstack-specs (and its repo) dead, paused, on hiatus, or just slow?14:46
fungigood question... seems like cross-project specs process took a back seat when the goals work started up14:47
mtreinishcdent: heh, it's probably all of those14:47
mtreinishcdent: although it never really was active14:47
cdentWe should consider killing it if it is in fact dead, otherwise it is effectively noise14:50
ttxcdent: it was one more attempt at describing cross-project work, I'd say it's mostly dead at this point. thingee is the reference there, but he is burning the man this week14:54
cdentas ya do14:54
ttxI feel like all those attempts fail because nobody really project-manage them to completion, as sdague once said14:55
ttxwhich is why we introduced goal champions this cycle14:55
ttxbasically, having a cross-project spec or goal blessed by the TC is not enough to make it happen14:56
ttxyou need at least one person taking significant time to make it happen14:56
ttxas proved by dhellmann and sdague and others on various topics14:57
cdentI think there’s some truth to that, but it also results in some of the changes sometimes feeling like they are just happening because the project managing person wants them to (which could be a good thing, not sure)15:07
cdentwhich can result in a bit of detachment or lack of awareness where things change out from under people15:08
dhellmannthe problem is that we haven't really established a history of successfully motivating the community to act without a leader to keep applying pressure and reminding and tracking. To some extent that's natural, since we all come with our priorities, but it makes these sorts of initiatives harder because it's not like we have a large number of people willing and able to drive such large projects all the time.15:15
dhellmannthe idea behind the goals process was originally that we'd use it as the motivational lever, but that hasn't proven to be an effective approach15:16
cdentwell before we head back down the road of “how do we manage traction” should we consider destroying the openstack-specs repo? Or is that something we need thingee around to be able to decide?15:19
* smcginnis lights a match15:19
dhellmannthe history in that repo is still useful, so I don't think we want to "destroy" it. We're already not using it. We could mark it as deprecated somehow.15:42
smcginnisProbably should update the README in there to state it is for historical reference, and update the docs index page with something similar.15:51
cdentdhellmann, smcginnis: if you guys thinks that’s a good way to proceed I’ll go ahead and propose something15:52
smcginniscdent: Works for me.15:53
*** dtantsur|busy is now known as dtantsur|afk15:53
smcginnisYou and your fancy UTF-8.15:58
cdentit’s pretty much the only one I can remember16:01
*** jpich has quit IRC16:38
* fungi can make √ with compose+v+/ but not sure whether there's a good compose sequence for ✔17:49
smcginnisI just resort to here: •17:54
* dhellmann wonders if a bunch of emoji-slinging teens have taken over the irc accounts of the tc17:57
cdentomg ndb pos17:57
* cdent hides17:58
smcginnisIt's not even a Friday. Must be the end of release.17:58
* dhellmann still spells his emoticons out in longhand17:59
cdenti’ve got this (terrible) new macbook with the touchbar, it make emoji available by sliding around on the touchbar18:00
cdentdo not recommend18:00
smcginnisNo, not happy with it?18:00
cdentinternally it’s great: fast cpu and disk. the screen is really nice. but for my typing style the keyboard has _way_ too little movement and the trackpad is too big. the touchbar is a neat trick but it means most of the things you would have done with the keys that used to be there now involve more cognitive steps18:01
mtreinishcdent: heh, having the touch bar for a function row was bad on the 2nd gen x1 carbon I used to have too18:02
smcginnisThat trackpad is ridiculously large.18:02
smcginnisNot a mac person, but I've considered one just because my current work VPN options are either Mac or Windows. Lesser of two weevils.18:02
cdentthat’s an unfortunate set of choices18:03
mtreinishsmcginnis: route the traffic through a windows vm? Assuming you can do that in windows18:03
cdenti have read of some people doing that kind of thing18:03
cdenthaving to run a whole windows vm for that is icky though18:04
smcginnismtreinish: I could look into that. Just annoying travelling to have to do that.18:04
fungias someone who builds portable computers with _no_ pointer device at all, having a touchpad take up so much real estate would drive me bonkers18:07
smcginnisfungi: Hah, I think the touchpad is larger than your entire setup.18:07
cdentit’s pretty good at dealing with accidental taps from things like the base of the palm, but if you slide, it can get confused. I sadly had to turn on click to click (I usually prefer tap to click)18:11
*** cdent has quit IRC19:13
*** gcb has quit IRC19:33
*** marst has joined #openstack-tc21:58
*** marst_ has quit IRC22:01
*** dtroyer has quit IRC22:14
*** lbragstad has quit IRC22:20
*** dtroyer has joined #openstack-tc22:40
*** marst has quit IRC23:24

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