Thursday, 2018-08-09

*** zaneb has quit IRC00:08
*** lbragstad has joined #openstack-tc00:53
openstackgerritgengchc2 proposed openstack/governance master: Adding Dariusz Krol candidacy for Trove PTL  https://review.openstack.org/58851000:57
*** annabelleB has joined #openstack-tc01:01
*** annabelleB has quit IRC01:02
*** annabelleB has joined #openstack-tc01:02
*** annabelleB has quit IRC01:03
*** lbragstad has quit IRC01:05
*** annabelleB has joined #openstack-tc01:07
*** gagehugo_ has quit IRC01:07
*** gagehugo has joined #openstack-tc01:22
*** eumel8 has quit IRC01:24
*** mriedem has quit IRC02:08
openstackgerritgengchc2 proposed openstack/governance master: Adding Changcai Geng candidacy for Freezer PTL  https://review.openstack.org/59007102:15
*** dklyle has joined #openstack-tc02:46
*** annabelleB has quit IRC03:03
*** rosmaita has quit IRC03:04
openstackgerritbaisen proposed openstack/governance master: add personal info to tricircle  https://review.openstack.org/59008203:13
*** dklyle has quit IRC03:42
*** e0ne has joined #openstack-tc04:11
*** e0ne has quit IRC04:24
*** ricolin has joined #openstack-tc04:28
*** eumel8 has joined #openstack-tc05:36
*** evrardjp has joined #openstack-tc06:55
*** tosky has joined #openstack-tc07:52
openstackgerritChandan Kumar proposed openstack/governance master: Move refstack-client, refstack and python-tempestconf to interop WG  https://review.openstack.org/59017908:00
openstackgerritLuka Peschke proposed openstack/governance master: Updating CloudKitty PTL information  https://review.openstack.org/59018008:00
ttxyes, it might be the shock it needed to be revived. I wish the previous PTL would have sounded the alarm publicly rather than progressively go dark, but it's hard to blame him as that was volunteered time08:03
ttxIt feels like we could have handled a Trove-like transition there without skipping a release08:04
*** jpich has joined #openstack-tc08:19
*** dtantsur|afk is now known as dtantsur08:33
*** cdent has joined #openstack-tc09:08
*** ricolin has quit IRC09:26
*** dpl has joined #openstack-tc11:58
*** rosmaita has joined #openstack-tc12:32
TheJuliaI think perceptions change and around the election does really cause people to step back and ponder... ponder if they've served that project and group of people well.12:36
TheJuliait is easy for people to withdraw at that point, which is the exact opposite of what projects need, but we are all human12:36
smcginnisHopefully this is something that our health checks will help avoid in the future.12:39
smcginnisOr at least, allow us to react a little sooner.12:39
*** edmondsw has joined #openstack-tc12:45
*** lbragstad has joined #openstack-tc12:46
*** ianychoi has quit IRC12:49
mugsieI think there is also the worry that if you raise the flag, no one will answer, and the project will end sooner than if you try and run a project in evenings and weekends12:49
mugsiethe lure of "I can definitely deal with this stuff this weekend" is hard to break12:49
smcginnisThat is true.12:50
cdentI have very mixed feelings about loyalty to corporate open source12:58
persiaI have very mixed feelings about categorising projects as "corporate" and "non-corporate".12:59
mugsieWell, it is usually loyalty (or just pride / a sense of ownership) for something you built12:59
cdentpersia: it's like I'm laying out bait for you ;)13:00
cdentpersia: but yes, my mixed feelings are to do with the categorising13:00
TheJuliasmcginnis: I doubt it, because we can only look at trends and take the PTL's perspective, and things can change massively in a very short time.13:01
cdent(in part)13:01
TheJuliasmcginnis: well, react sooner, I agree it should help13:01
mugsiee.g. Designate was started in a company I help found, by one of my co-founders. We then went to work for $PublicCloud to bring it forward, and then brought it into the private cloud version. We all kept working on it long after it was our dayjob13:01
cdentmugsie: yes, I agree with all that. I've stuck with placement through two employers now, and gabbi through three. But I think it is also fair to be angry with corporations that say they are supporting this stuff, but aren't, not really.13:03
mugsiecdent: definitely13:03
cdentThey make _billions_ of dollars off this stuff.13:04
TheJuliais the problem a value perception issue?13:04
persiaWhen folk's roles/funding sources change, the model I've seen work best is transparency.  Someone saying "I no longer feel I have as much time for foo as I used to have: is anyone else willng to help?".13:04
persiaNo reason to stop work just because it isn't 100% of one's dayjob, but that should be a personal interest / future career / etc. decision, not just blind expectation.13:05
persia(same applies for folks who encounter personal issues that block time, even with the same funding situation)13:05
TheJuliapersia: I concur, we just need to remember that is the context of those people and that we can't expect the same level of interaction or commitment.13:06
mugsiepersia: There is a talk from boston where me and the PTL at the time both stood on stage and said that, and got nothing from anyone. There was even distros in the room, who started asking for features, and who pinged me for help with their internal deploy tooling that to this day have not contributed to us13:07
persiaYes, and to make clear to people that if their available time changes (for any reason), they are encouraged to report this to the wider project and ask for help (rather than waiting for the cycle to end, etc.).13:07
persiamugsie: Yep.  That happens.  Especially on stage: it is rare that the people who are capable of making commitments are in those rooms (they have meetings in private rooms at the same time).13:08
mugsieall that did was kick off a rumour mill that designate was dead, and there was no point in doing anything with it13:08
persiamugsie: Would a framework to report it that was explicitly constructed to indicate that the project isn't dead have helped avoid starting that rumour?13:08
cdentmugsie: yes, simply asking hasn't proven effective (whether in front rooms or back rooms). I think not doing things we don't have time for is one of the remaining strategies13:08
mugsieOh, I am aware - but the raising of the issue nearly killed the project13:09
cdentwhen someone asks for A, ask them which B they don't want.13:09
persiaI've seen asking work in back rooms.  Key is who is asking and for what.  Asking generically for "help with foo" doesn't tend to be interesting.13:09
cdentand if no one asks for A, don't do. Do what's needed instead.13:09
mugsieyeah, we had a whole cycle where our major feature was "we fixed the gates"13:10
evrardjpI think that's a reasonable goal to keep the lights on13:13
mugsieevrardjp: yeah, I thought so :)13:14
evrardjpAlso I have a fatalistic view of software: if there is no-one willing to step in to work on it, maybe it doesn't fill enough interest/use cases and must die? (Not talking about a project particularily here, just saying sometimes it's not worth the effort)13:15
evrardjpin other words: times change13:15
persiaevrardjp: I've seen that work *very* well in other contexts.  The usual results are a) a fork on different infra (sometimes for trust reasons) and b) someone stepping up and taking over if they have a need for it to be maintained.13:16
mugsieevrardjp: yeap, that is usually true.13:16
persiaThere are lots of companies in the business of selling warrants for open source software.  If they have warranted a feature, there are almost no limits to their need to be able to effect change for the term of the warrant.13:17
evrardjpI don't disagree : )13:18
mugsieIt is just annoying to hear a vendors PS team did a few one off bespoke installs of your software for their customers, but they haven't done anything for the project or integrated it into the installer, or have integrated it into the installer, and don't contribute back at all13:18
mordred++13:19
mugsieto be fair, one of the vendors have made an effort to put people on the project recently and add it to the installer13:20
evrardjpmugsie: that's sad indeed. But I consider if they install it and report bugs, even if they don't fix it, they are still positive in the balance. But I guess you're talking about an experience that's not so positive.13:20
persiamugsie: One of the big challenges for communities ike ours is defining the edges.  If we make it trivial enough to join that those PS people find it easier to work upstream than to carry local patches/fixes, then we lose the ability to have an "us" that is doing it "right".  If we have any barrier that lets those PS folk be defined as "them", then they have no incentive to put in the time to be part of "us".13:20
persiaOne project in which I was involved in the past took an interesting view towards this: they blindly applied every patch from anyone who would provide one, and volunteers focused on making (even terrible) patches for every bug, all based off someone else's work.13:21
persiaThis became immensely popular, even though it was demonstrably worse than the source from which it forked.13:22
persiaMaking it good ended up killing a lot of the popularity.13:22
persiaSo this story doesn't really have a moral, or provide an answer.13:22
mugsiepersia: the PS people have been great, and pushed back docs and info. the vendor product team didn't do any of that until recently, dispite quite a few of their large customers asking for it13:22
mordredeven if we made is simple for people to join, I think an issue we've seen in many contexts is that people might have time to report the bug or even submit a patch the first time, but they don't have time to follow through on review comments and whatnot13:22
evrardjppersia: interesting13:22
mordredwhich is the flip-side of persia's story ... we ignore patches from people who don't follow up on them, even if the patches are good13:23
persiamordred: Yep.  We define an "us" based on a level of interaction.  We're happy to provide training for folk that demonstrate a willingness to interact that much.  We exclude the rest.13:23
mordredyup13:23
*** mriedem has joined #openstack-tc13:24
scasi've started engaging, for better or worse, because the rumor mill started about chef openstack being dead. it was a bit disheartening to read on the ml that, but it also showed me i was too heads-down for the project's well-being. continuity has been on my mind for more than a cycle or two13:24
mugsiea vendor made the mistake of telling a customer the project was dead, when the customer had been talking to the upstream team for a while13:24
mordredI think in the early hype days there were reasons in which that was acutally a useful stance - but today we're in a position where we haven't developed "janitors" who will grab those sorts of things and follow through on them13:24
evrardjpmordred: that sounds time expensive13:25
evrardjpI'd rather distribute so that everyone becomes a "janitor"13:25
mordredyah. that too13:25
evrardjpor that there is none needed13:25
persiaI think distribution should be based on incentives, rather than one size fits all.13:25
evrardjp(but that's dreaming)13:25
mugsiemordred: yeah, that may be a good way forward, and something I know we have talked about in the past - talking over patches, or merging with followups13:26
evrardjppersia: in case of non merged code that was proposed, the incentive should be clear: "you don't have to carry that patch downstream if we merge it". With the policy on reviews in (anti nitpicking), I don't see any barrier anymore13:27
persiaFor example, if some org wants feature foo, it makes sense to fund someone to do a feature, and that person has little incentive to be a janitor.  Conversely, if some org has sold a support contract, warrant, or similar, it makes sense for that org to fund a janitor (or face potentially uncontrolled liability, which is usually inrteresting to the risk management department).13:27
evrardjpif there ever was a barrier13:27
mordredpersia: yes13:27
persiaevrardjp: So if I randomly add a patch to a bug and then go do something else for six months, the patch will be applied?13:27
mordredpersia: one of our problems thus far, I believe, is that we've not done a great job in communicating to people about funding janitors13:27
mordredpeople get that they need to fund people to work on features13:27
persiaRemember, I don't care about the customer situation again until the next release, and even then, I probably don't have forward confirmation as to whether or not I'll need to port the patches.13:28
evrardjppersia: that's not what I meant -- the incentive in the effort of merging in the first place is the reduced cost on the long run of carrying a fork13:28
mugsiepersia: the problem is that the janitor role is carried by a few people, and orgs are happy to have a janitor assigned for 6 months, which is actually more work for the project than they get back13:28
scasi sometimes wonder what would have happened if peak openstack had taken chef down with it, had i not been stubborn enough to scratch my own itches13:28
*** zaneb has joined #openstack-tc13:28
scasdeployment efforts are usually multi-year affairs, so long as they don't cause too much pain13:28
persiamordred: Understood.  I'm happy to sit with folk who sell the products that need that support, if you have candidate orgs.  I can also refer some peers.  I don't know of much open content that really pushes the point in strict economic terms.13:28
cdentmordred: funding janitors is definitely a needed thing. It was kind of what rocky was going for in one of her sessions in vancouver but it got sidetracked. As our local token board member, is that a thing you can push harder?13:29
*** edmondsw has quit IRC13:29
persiascas: Yes, but those might not be upgraded over that term, which is the only time the PS folk are incented to care about what upstream does.13:29
mugsiecdent: mordred it also came up in the BoD session in Vancouver13:29
mordredcdent: I can certainly try - I've raised it in, I believe, every board meeting we've ever had13:29
cdentmordred: you are a) a star, b) apparently need to go nova13:30
mordredthe issue is that nobody on the board are in the product-management chain at their companies that control employee allocation to tasks13:30
persiaDo we believe that a sufficient plurality of the board represents organisations that are liable if future releases of openstack fail to perform in the way that the current releases perform?  if not, that's not a useful body to approach for this sort of request.13:30
scaspersia: fair point. upgrading has been something that has been lightly approached due to time involved13:30
mordredso while everyone on the board seems to understand the issue and agree it should be made better, everyone seems equally as empowered as I am to effect that change in their host companies13:30
cdentmeh13:30
mugsieyeah - they are usually so far removed from the real work their company does, I wonder do they even know what level of upstream that they actually have, or just reading sumaries of management reports13:31
scasin chefland, once one is at a certain deployment level, upgrading is usually done out of band without involving the automation13:31
mordred(in case y'all don't know, I do not have any power to affect change in my host company)13:31
scas(not causing too much pain, there's that theme)13:31
cdentmordred: let's form a new company and hire each other13:32
mordredcdent: such a good idea13:32
* smcginnis laughs at "host company"13:32
mugsiepersia: well, our latest platnium member will still be printing money if openstack is a thing or not for example, same for quite a few member companies13:32
mordredcdent: do either of us know how to find money to pay each other?13:32
persiamugsie: That has nothing to do with whther the code is any good, unfortunately.13:33
cdentmordred: I was assuming I'd pay you with the money you pay me. That's how capitalism works, right?13:33
scasmordred: just use a blockchain!13:33
mordredcdent: oh, right13:33
mugsiemordred: there has to be a bank running a Havana cloud we can consult on right?13:33
mordredscas: yes! we just do an ICO right?13:33
persiaOr, for that matter, whether any particular project within the "openstack" umbrella exists or is maintained, as long as "openstack" is a thing.13:33
mordredmugsie: SO MANY BANKS13:33
scasmordred: yup. the white paper is literally writing itself13:33
mugsiein ten years someone who can debug a broken havana openstack install will be the new cobal developer13:33
scassomething something moon13:33
persiasmcginnis: Would you prefer "sponsoring fiscal entity" (being the formal term of art)?13:34
evrardjpmugsie: I laughed, but I don;t know if I should13:34
mugsieI am only 1/2 joking13:34
mordredpersia: inside of companies I've tried multiple times to communicate that it's cheaper to fund janitors upstream than to fund people to fix breaks after the fact downstream. unfortunately, it's a value prop that spans more than one fiscal quarter, so none of the managers involved are particularly motivated to invest in a reward outside of their bonus comp structure13:35
scasmugsie: i can see it being plausible. platform choices tend to be multi-year things. no reason why someone wouldn't be running havana in a decade, if they can keep their own personal pain levels tolerable13:36
*** edmondsw has joined #openstack-tc13:36
scasi used to support a websphere customer whose one and only request was 'reboot the machine'13:36
scasthat's what they paid for13:37
persiamordred: Certainty and profit also matter.  Organisations that charge for time are incented to do it wrong, if the customer pays.  Most PS orgs are like this.  Also, orders are fufilled, but it is unwise to undertake a staffing commitment until one has a forward contract to consume that.  So, until there is known funding to solve a problem, it doesn't make sense to staff someone to do the janitorial work.  By the time it does make sense, it's too13:37
persialate (plus, maybe charge the customer).13:37
mordredpersia: yah13:38
mordredscas: I used to get paid to 'support' an app that had no support needs - but nobody at the company understood the tech, so they put me on the payroll to hedge risk in case something did break13:39
persiaI believe there are only two common business models that fund janitors, being a) operators (as it's cheaper to hire a janitor than pay PS $$$$ every once in a while) and b) orgs with "fixed-price" commitments (which are anything but), that do not incur additional hourly rates for faiure, but rather either see no gain or see reduced income (common in soverign contracts).13:39
mordredin the time I worked there, it didn't break such that I needed to do anything one time :)13:39
persiaPS firms (which we often call "vendors") generally benefit significantly from the lack of janitors, from upstream code not working, from upstream documentation being low quality, and similar.13:39
*** edmondsw has quit IRC13:41
scasit has been said, in this channel, that such efforts as the one i currently consider a giant hobby are better suited as products13:41
scasonly once, but that one sticks with me13:41
scasbeing that so much capital flows through and around openstack, it shouldn't be that there are discussions about how to fund the development13:43
cdentone would think as much, but here we are13:44
scasindeed. that's the part i didn't follow up with13:45
scasi had some sidewalk discussions at the peak of the hype, when i learned what itch i was really scratching. the story was stark back then: "they don't see any money in it, so this is our last summit"13:46
mugsiethe problem is for a lot of private operators, the infra / cloud / platform team (which is where a janitor style role woudl come from) is considered a cost centre, so trying to justify the headcount can be difficult, the PS organisations want billible hours (see persia's description), and the traditional linux vendors who traditionally do the janitor work get the entire bucket, which means they need to prioritize  the areas they do janitorial13:48
mugsiework in13:48
scasfive cycles later, the self-reported survey shows that there's something. people use these things that "didn't see any money"13:48
*** edmondsw has joined #openstack-tc13:51
persiamugsie: I fail to see a distinction between "linux vendor" and "PS firm", although I admit that the folk who work on open source are often a cost centre not in the PS team.13:54
scasthe paths to openstack are as important as openstack itself. not every company is able to make the cosmic shift, be it due to whatever reason they have. ps orgs can only do so much13:54
persiaThe operators are definitely a cost centre.  See the Public Cloud WG for examples of operators that understand that landing things early can reduce the overhead of that cost centre.13:54
persiaThere are also perversities related to the cycle structure.  Professionally, I only care about Queens and Stein.  I'll start caring about Rocky only after it isn't a development target.  Personally, I understand that this is a broken model, but I've been around a whlie.  Folk used to less transparent development environments may not appreciate things in the same way.13:56
scasprofessionally, i care about three releases roughly tied to equivalent osp versions. for my other hat, i care mainly about whatever 'master' is at at the time13:59
*** amotoki_ is now known as amotoki14:01
scasi'll generally start focusing on rocky once packages have been made GA14:01
scasi've tried to keep closer to trunk, but it was not worth the additional burden of chasing a moving target14:02
persiaThat this is true *except* when one has outstanding patches is part of why there are so few janitors.14:04
*** jaypipes has quit IRC14:06
scasalas, this is the underpinning of the bazaar model14:08
scaswhen widely used open source efforts are maintained by people who show up 'for fun', it's not always sustainable14:09
*** jaypipes has joined #openstack-tc14:10
scasi speak not only of openstack, but others. i'm all too reminded of freebsd of yesterdecade14:10
mugsiepersia: the difference for me is one is a product team, with PS, who does product dev in a "upstream kind of first" model, the other is a "we will fork openstack where is it now, and maintain it for you for the life of your contract"14:10
scasthe mentality of not upstreaming first, or at all, is part of the problem for maintaining things. i can point to metrics, but i can also infer that most of them carry local patches14:11
persiamugsie: In march, I spent three days staffing a booth wherein I was discussing how to deal with the latter with "life of the contract" being measured in decades.  It turns out that it looks a lot like the former, except with more complicated testing infrastructure.14:12
mugsiethe reality is for a "boxed product" style on premises product, you will always have patches you are carrying - it is the nature of the beast. the key metric is how soon you converge with the upstream solution to the bug after upstreaming it14:13
mugsiepersia: yeah, but a lot of these PS orgs have been doing this style of product for decades, and have the infra / people / process to pull it off (most of the time)14:14
persiaNot necessarily.  I spent some time working with a "boxed product" vendor that shipped unmodified public code.  The value add was entirely about the box.  There are lots of models, and many are in use by different parties at any given time.14:14
persiamugsie: Yep, but key is that if some constituency wants folk to perform janitorial duties, the organisations you describe are entirely the wrong audience for the request.14:15
scasps orgs won't necessarily do the work. you can't bill for open sourcing14:17
persiaOh, yes you can :)14:18
scasif there's a perceived need. many enterprises like to consider their local patches akin to the crown jewels themselves14:20
ttxIt's a general trend as open source gets more and more adopted / the default, the imbalance between users and contributors is only getting worse14:23
ttxOpenStack is far from being the only open source project suffering14:23
scas^14:24
mugsiettx: very true14:24
ttxhype keeps you afloat artificially14:24
persiaThis is contrary to my experience.  30 years ago, "contributors" were magic folk, and learning to be a contributor was hard, but *everyone* used the code.  Not doing so left you with the vendor tools, which were only as good as the unix wars permitted.14:24
persiaTransparency has increased, but I think the ratio of users to contributors is actually smaller.14:25
ttxOne mistake we made is to build to much processes (in the Zingerman sense) around that period of abundance14:25
persiaThat is something with which I agree14:25
ttxIt's easy to believe it will never stop. We made taht mistake, and K8s is doing the same right now14:25
scasindeed14:25
ttxThere must be a syndrome with someone's name to describe that. The fallacy of nice things14:26
persiaBeing able to name the discoverer is one of the nice things that seems to have been lost along the way.14:26
mugsiettx: yeah, I saw it when I was working on k8s - all our team did was pull the source, and package it in a box nicely - we didn't do any upstream at all (in k8s - we did in some of the container runtimes)14:29
scasthe unfortunate reality is that as open source becomes the default choice, all too often, many people are happy this simple fact: so long as it Just Works, it can be one person or 10014:29
scasto a great extent, many can be unaware as to how things are behind the curtain14:30
fungicf, openssl14:30
openstackgerritThierry Carrez proposed openstack/governance master: Adding Dariusz Krol candidacy for Trove PTL  https://review.openstack.org/58851014:30
ttxI fixed the review, you can revote on it ^14:31
ttxwow. hmm14:31
ttxSomehow gerrit is smart enough to see that that patchset was the same as the previous one we voted on14:32
ttxThat is kind of cool14:32
scascoming from freebsd, i was accustomed to the notion of a single person being responsible for a large swathe of a codebase14:32
smcginnisttx: I've noticed that behavior since the last gerrit upgrade. Kind of nice.14:33
scasto that degree, it's not often that i've asked of others14:34
cdentttx gerrit looks at the commit hash et voila14:38
cdentit's not super new, but happens rarely enough that when it does it's all "zomg, gerrit is so my friend"14:38
*** hongbin has joined #openstack-tc14:41
*** dtantsur is now known as dtantsur|brb14:43
scasfostering continuity to spread beyond a small focused group, or an individual in some cases, suggests to be predicated on the ability for someone new to grok things to be able to propose and land patches14:44
scasit's easy for someone accustomed to not see the sharp edges14:45
scasthis is especially true in the more complex of efforts14:45
evrardjpcdent: yeah on the "it's not so new", and definitely on the "so my friend" ;)14:48
ttxupdating status on https://etherpad.openstack.org/p/stein-leaderless14:50
openstackgerritChandan Kumar proposed openstack/governance master: Move refstack-client, refstack and python-tempestconf to interop WG  https://review.openstack.org/59017914:50
scasduring the time i had freebsd as a focus, going back some two decades at this point, the more cantankerous of efforts usually had one person. contributing patches was notoriously difficult due to numerous reasons14:50
chandankumarttx: Hello14:51
ttxchandankumar: o/14:51
chandankumarttx: https://review.openstack.org/#/c/590179/ regarding this review do i need to update project-config also?14:51
*** dpl has quit IRC14:51
ttxno.. from an infra perspective the repos do not change14:52
chandankumarttx: i donot know how working group handles release deliverables?14:52
chandankumarttx: ok14:52
ttxit's just a governance question... what entity owns them14:52
ttxif you add them on one side you need to remove them from the other side14:52
chandankumarttx: got it thanks :-)14:54
*** annabelleB has joined #openstack-tc14:55
ttxtc-members: you should vote on that change (confirming Claudiu as PTL for another cycle at Winstackers) https://review.openstack.org/#/c/589553/14:55
ttxerr14:56
ttxthat is not the change I expected14:56
ttxlet's wait until it's fixed14:57
ttxSo regarding leaderless projects, it looks like we have a clear resolution path for all, except Freezer14:59
ttx(otherwise there seems to be lazy consensus in keeping Trove and removing Searchlight)15:00
cdentoh look tc-members it's office hours15:00
smcginniso/15:00
fungiohai15:00
* cmurphy has a conflicting meeting :'(15:00
EmilienMo/15:01
smcginnisDidn't we have a candidate for freezer?15:01
ttxWhat's your take on Freezer ? Approving Changcai or dropping it ?15:01
smcginnisAgree on the trove and searchlight ones.15:01
ttxsmcginnis: we do, does not mean we should save it... since it missed Rocky.15:01
pabelangerhello15:01
ttxI'm leaning weakly toward keeping them provisionally and revisit before Membershipfreeze15:01
zanebo/15:02
smcginnisThat works for me. Let's give them a little time to right the ship, then follow through with policy if we don't see that happening.15:02
ttxDropping it now would seriously impact that new leadership from stepping up15:02
fungicmurphy: yeah, i have another meeting at the exact same time as our thursday office hour too. makes it hard to split my attention successfully15:02
ttxbut I could go the other way, because the missed release looks so bad15:03
cdentIf we're going to give people extra time we _must_ be strong in our follow through15:03
smcginniscdent: ++15:03
TheJuliao/15:03
ttxcdent: I'd argue we need a pair signed up to follow15:03
* ttx looks who the lucky winners are15:03
ttxttx and mugsie15:04
smcginnisYou're a winner!15:04
ttxsuckers!15:04
ttxerr15:04
TheJulialol15:04
* TheJulia suddenly wants to watch the fifth element15:05
ttxWe *do* reshuffle those every cycle right15:05
ttxsmcginnis: if you feel this way, you should vote on https://review.openstack.org/#/c/590071/ and  https://review.openstack.org/58864515:06
smcginnisOh right.15:06
openstackgerritLuka Peschke proposed openstack/governance master: Updating CloudKitty PTL information  https://review.openstack.org/59018015:06
ttxsmcginnis: wants to give a quick report on how the release is going so far ?15:11
ttxwant*15:11
smcginnisThey're going.15:11
smcginnis:)15:11
smcginnisWe have a few projects yet to RC, but I'm not too concerned at this point. Yet.15:11
* smcginnis pokes mugsie 15:12
smcginnisI've at least seen some activity from most of the major ones.15:12
ttxit's your everlasting optimism15:12
fungioptimism is what keeps the homicidal rage at bay15:13
smcginnisYep15:14
* dhellmann finally makes it through atlanta traffic15:15
smcginnisSeems like we had most of the discussion today before the office hour.15:15
dhellmannttx: my plan was to change liaisons each tc term, since that's when the tc members might change over. after stein that will sync back up closer to the dev cycle so it amounts to the same thing15:17
cdentI had a small update on the paste situation, mentioned it before, but will restate: it looks like haypo may have the keys to the paste kingdom, but it is August and he's in France15:17
smcginnisSend ttx to track him down?15:18
dhellmanncdent : what's the plan then? get him to land the fix? or add some volunteers?15:18
* dhellmann volunteers to go to france to hunt for haypo15:18
dhellmannin spite of the heat15:18
* lbragstad is curious of other services have discussed other options to paste15:18
EmilienMI'm actually flying to France right now15:18
smcginnisI'll carry dhellmann's bags15:18
* EmilienM knows where he lives15:18
smcginnislbragstad: How is the flask work going?15:19
cdentdhellmann: based on what I was able to read, haypo is neither interested, nor has the expertise to "own", so I reckon if we want stability we will need to adopt, so my plan was to see what he thought of that idea15:19
ttxcdent: those French people don't work in August15:19
lbragstadpretty good so far15:19
dhellmanncdent : ok15:19
smcginniscdent: It would be good having some input from someone "official" on that project, even if he's not an expert.15:20
cdentlbragstad: I think lots of services would like to change but a) the usual resources problems (see earlier in today's logs), b) the extant paste.ini files that are out in the world and are customized15:20
lbragstadsmcginnis: we've had the plumbing merged for quite a while, so now we're at the point of converting parts of keystone's APIs to using actual flask15:20
smcginnislbragstad: cdent has a good point. Are you doing anything to handle the migration from paste.ini, or is it a clean cut over?15:20
cdentsmcginnis: I think calling him official is overstating things. It's merely that he was granted the power to <not quite sure> at some point in the past. There is no project. It is dead.15:20
dhellmannit sounds like maybe he's the person to give the keys to someone else who wants to take it over, though. if we have such a person.15:21
smcginnisWell, official in this case just being he has some power related to the project.15:21
smcginnisYeah, it's at least a possible pathway to some other activity.15:21
lbragstadsmcginnis: kmalloc was providing some ways to load middleware via configuration, but otherwise we're attempted to pull middleware into keystone proper15:21
lbragstadat least as a stop gap15:22
lbragstadbut ultimately it would be nice if those lines were cleaner (IMO)15:22
lbragstadand i think that's what we're striving towards15:22
smcginnisCurrent RC status in case anyone is interested: http://paste.openstack.org/show/727745/15:23
*** alex_xu has quit IRC15:24
* lbragstad sets https://review.openstack.org/#/c/590361/ next to smcginnis15:24
smcginnis:)15:24
dhellmanncdent , smcginnis : since you were both working on https://etherpad.openstack.org/p/tc-board-foundation I wanted to make sure that you saw that Alan will be there Sunday for the PTG and that I added an agenda item to talk about the joint leadership meeting for November. There could be some nice overlap with the topics you had in mind.15:25
smcginnisdhellmann: Thanks, that could be good.15:26
cdentindeed15:26
*** dtantsur|brb is now known as dtantsur15:29
dhellmanntc-members: I count about 25 teams that don't seem to have health tracker details on https://wiki.openstack.org/wiki/OpenStack_health_tracker15:29
cdentI had another thing I wanted to ask about, and it has completely slipped my mind. I think the earlier conversation about loyalty and resources (which was very interesting) used up my brain15:29
dhellmannsome have "reported issues" but nothing that looks like an update from a tc-member15:29
mnaseri think i never updated mine on the wiki so i'll get around it.15:29
EmilienMI still need to reach out some of them indeed15:30
TheJuliaI think I have one I still need to reach out to, and two I need to follow-up on. Hopefully in the next few days.15:30
pabelangerI'm still have 2 sigs to reach out too, been missing their meeting times sadly15:31
dhellmannthat would be great, thank you15:31
dhellmannpabelanger : I think we can emphasize the project teams for this round (and given the timing)15:31
dhellmannbut if you're done with those, by all means contact the sig leaders15:31
pabelangerdhellmann: ack15:31
cdentdo we have enough data to identify any trends or themes?15:32
dhellmanntc-members: if you have tried to contact the PTL of the team and had no response, just note that. that's an indicator on its own :-/15:32
dhellmanncdent : I haven't had time to review all of the reports yet, but I intend to do that before denver so we can discuss it there15:33
persiaMaybe also note how and when the contact was attempted.  Some people are oddly strict about hours.15:33
dhellmannpersia : ++15:33
TheJuliaAlso retry, I had one PTL that never recieved two emails and I finally got ahold of them on the third and via IRC.15:34
dhellmannemail knows no time15:34
dhellmannTheJulia : good point15:34
fungii've been doing my best to get up with them in scheduled meetings so far, but yes there are a few on my plate that are lacking updates in the wiki, or for which i haven't solicited details yet15:34
persiadhellmann: It so does.  There exist people who only read email during $hours, and if things are missed in a day, never get back to them.15:34
persiaAlso, email is inherently unreliable (by mechanisms inherent in the current protocols), so retries do matter (and hours of retries matter: some organisatons do filtering differently by time of day).15:35
*** ricolin has joined #openstack-tc15:36
mordredpersia: I frequently fall into that set of people15:38
mordredpersia: email is a terribly unreliable way to reach me - not because my email itself is bad (it's actually quite good) but because if I miss it it's typically gone for good :)15:39
*** dklyle has joined #openstack-tc15:39
persiamordred: Thank you for volunteering!  You are an excellent example case of folk who generally communicate well that suggest a single email at potential $bad_time_of_day isn't a reliable mechanism.15:39
fungiit's unfortunate that e-mail is so unreliable given smtp is extra reliable, people have built in all sorts of unreliability in the name of progress15:39
fungis/built in/bolted on/15:40
persiafungi: Sadly, even SMTP isn't reliable any more: recent protocol updates actively remove some of what was there (but I'm arguing *with* you here).15:40
fungisure15:40
pabelangerdhellmann: I've updated loci info on wiki, reply came in while on PTO15:40
mordredmy problem is that I very reliably get way too much email15:41
dhellmannpabelanger : thanks15:41
fungiroughly twice a year i get tasked with sending out code contributor discounts for summit registration. it's not until after i send e-mail to ~1500 people that i realize just how many of them decide to reply to me15:41
fungisome have questions, some just want to have friendly conversation15:42
mordredhow friendly15:42
fungiit's a great way to virtually meet lots of people from the contributor community, but also quite a time sink :/15:42
*** annabelleB has quit IRC15:43
*** annabelleB has joined #openstack-tc15:43
fungiand i feel compelled to reply to them all, because not to do so would be rude15:43
persiaYou are a fundamentally good person.15:43
TheJulia++15:44
TheJuliaI personally fall into the email is the worst way to contact me, since so many emails I get are just noise, and it makes it difficult to pick out the signal for me... especially when... *squerrel!*15:46
ttxsquerrels are the worst15:46
fungiunfortunately i've got really efficient server-side filtering set up on my mta15:48
fungiwhich makes it all too easy to separate signal from noise15:48
fungibut... so much signal15:48
ttxzeroth-world problems: My spam filter is too good15:49
persiaReceiving no spam != receiving zero noise.  Some folk's signal is other's noise, especially if there is limited time for email.15:50
TheJuliaI've had too much bad luck with spam filtering catching legitimate email and stuff getting caught into the wrong folder because of an out of band reply, that I just try and keep it all minimally messed with and scan when the braincells are powered.15:51
* kmalloc circles up15:52
TheJuliattx: my spam filtering was awesome when I ran a private TLS wrapped SMTP system for law firms that was all whitelist access only to reach each other... we had zero spam.15:52
kmallocfwiw, keystone (as of now) does not allow loading of non-standard middleware (one exception is the debug middleware) in the pipeline15:53
kmallocthis is for 2 reasons: 1) security, even if we re-enable it, non-blessed middleware cannot be added after we handle auth because it could muck with data in ways we can't control, breaking how keystone handles a request, and 2) because loading in middleware after auth is as easily handled above the wsgi layer in a proxy15:54
cdentkmalloc: yeah, that's how it should be, but unfortunately nova, at least, is not like that15:54
kmallocwe could add in a loader (trivially) at this point, but it would still adhere to the "before the keystone authentication handlers" because of the security concerns / possibility of breaking keystone in horrible ways.15:54
lbragstadand paste.deploy is !maintained :(15:54
kmallocwe do direct load of the middleware we care about and instantiate it, wrap the wsgi_app15:55
cdentyeah, same thing in placement. is nice separation of concerns with good control15:55
kmallocif you look here https://github.com/openstack/keystone/blob/master/keystone/server/flask/core.py#L89 we load in our middleware we care about here15:56
kmalloconce keystone is moved to pure flask, all the middleware supplied by keystone's python package (itself) will be moved to flask "before_request" methods15:56
kmallocso we will only have oslo/blessed 3rd party middlewares loaded in15:56
kmalloccdent: yeah, i looked at some of what placement was doing when making decisions on how keystone was going to handle that15:57
jrollironic does the same, we only load middleware we know about15:57
kmalloccdent: i much prefer telling folks "you may use a proxy in front of keystone, or you may use keystonemiddleware if you need to be behind "auth"15:58
kmallocjroll: ++ yeah it is silly to allow "any/all" middleware from anywhere15:58
jrollnot that people won't just patch it to add things in, but we tried :)15:58
lbragstadalso - this might be irrelevant to some15:58
kmallocjroll: i find people "patching" things in is much rarer and those folks are going to do silly thing anyway15:59
lbragstadbut using something like flask cleans up a lot of technical debt for us15:59
*** dklyle has quit IRC15:59
kmallocjroll: solution: re-write keystone in rust (s/keystone/ironic) and distribute binaries with obfuscation. no wait, that is the wrong answer ;) heheh15:59
lbragstads/irrelevant/an implementation detail/15:59
kmalloclbragstad: ++15:59
jrollheh16:00
kmallocwe could have done flask with paste, but i figured i could more easily drop paste with a move to flask than any other time16:00
kmallocsince there was massive re-working to be done.16:00
lbragstadfor example - the community goal we wanted to get done for Rocky becomes a lot simpler to implement16:00
kmalloclbragstad: especially since we don't use oslo.service16:00
jrolllbragstad: do you think that was because you used something like flask, or because you were re-writing a large chunk of code anyway, so it was easy to clean up while you were there?16:00
jroll(or both)16:00
kmallocjroll: both.16:00
lbragstadfor sure the later16:00
jrollnod16:01
kmallocjroll: flask makes it a lot easier to add in functionality where we need / change out how things work. but massive re-write makes it easier to make big changes / plan for the big changes16:01
lbragstadflask probably has something to do with it, but i'm sure $other_framework would work, too16:01
kmallocyeah16:01
*** dklyle has joined #openstack-tc16:01
kmallocany well built framework would have had the same benefit16:01
lbragstadadhering to a framework helps us isolate our business logic from the wsgi layer (if that makes sense?)16:03
jrollnod16:03
lbragstadwhich should, theoretically, help us improve self-service APIs in a "secure" way16:03
kmallocit also is forcing us [the way i wrote the conversion] to merge in all the separate api "extensions" so each path prefix (e.g. /users) is isolated into a single file "controller" wise.16:04
*** annabelleB has quit IRC16:04
kmallocwe used to have things spread all over and could hook into any url prefix from anywhere16:04
lbragstad^ should help with developer pain of understand routing in keystone16:04
lbragstadunderstanding*16:04
lbragstadwhich kinda gets to cdent's point of having less people around16:04
*** annabelleB has joined #openstack-tc16:05
kmallocwe're also not just using flask, we're using flask_restful (mostly)16:05
kmallocsince it adds some nice API-specific mechanisms.16:05
cdentunderstanding routing is _huge_ help16:05
kmalloci also very much like that flask has a global request context that can be accessed from anywhere as long as the request has started (in the flask app)16:06
lbragstadi hope it helps when people don't have to wrap their minds around a custom routing/dispatcher to understand how keystone's API is implemented (especially if they are already familiar with something like flask)16:06
*** annabelleB has quit IRC16:06
kmallocso no need to pass "request" or "context" around, just reference it. it makes our code a lot easier to work with.16:07
kmallocwe used to pass request objects all over the place16:07
kmallocnow we just do flask.request.<request_bit, usually environ>16:07
clarkbkmalloc: out of curiousity why have a debug middleware over say debug logging configuration? Does it let you do more than record requests in detail?16:07
kmallockmalloc: debug middleware is specific to whole-app-wsgi debug data, it is in addition to debug logging16:08
*** jpich has quit IRC16:08
kmallocmost folks have no use for the debug middleware data even when debug logging, but since we offered it by defualt before, i maintained it16:08
kmallocit is on the short list of "to be removed" if we don't have a concrete use for it16:09
kmalloceasier to keep out base set of middleware than drastically change it (for example, i'd love to make os-profiler not even loaded unless configured on as well)16:09
kmallocs/kmalloc/cdent16:10
kmalloc:P16:10
kmallocerm16:10
kmallocclarkb: dang it, you all have similar names pre-coffee16:10
kmalloc:P16:10
* cdent has been mistaken for clarkb before16:12
fungiunrelated, but in response to my comment last week about cyborg not having weekly meetings in irc even though they have subteams meeting on zoom, seems they _do_ have weekly irc meetings they just hadn't put them on the schedule. fixed with the merging of https://review.openstack.org/58997116:12
cdentlbragstad, kmalloc was there a particular thing that made doing the flask switchover "possible" for a priority/time/permission/whatever it takes sense?16:17
lbragstadum - well if i understand your question, we kinda had to do it to do fix some problems in keystone16:17
lbragstadfor example, incorporating the new default roles we provide into keystone APIs is a lot easier after converting to flask16:18
cdentokay, so would it be fair to say you were able to justify it by hanging it on a feature of some kind?16:19
lbragstads/converting to flask/separating keystone business logic from parts of the WSGI implementation/16:19
lbragstadi would say so, yes16:19
cdentif you just wanted to "clean up" would you still have been able to do it?16:19
cdentI know these are weird questions, because it's not like anyone is likely telling you exactly what to do, but... there are implicit drivers16:19
lbragstadwell - i guess i would still push to have done the conversion to flask even if we didn't hang a feature (security specific feature) on it for the sake of making keystone easier for newcomers to understand16:20
* lbragstad isn't sure if he's giving conflicting answers16:20
lbragstadwe've had a decline in contributors and maintainers, so making it easier for new people to join or pick things up is important IMO16:21
cmurphyi wish we had planned better at the beginning of the cycle to incorporate the flask stuff16:21
cdentI'm not sure there are any straight answers. I'm mostly fishing for your feelings16:21
cmurphywe had some other stuff drop off the table this cycle while we were spending bandwidth on flask16:22
lbragstadyeah16:22
cdentso we can steal the oomph16:22
lbragstadit wasn't until like halfway through we were looking at everything and seeing the impact it would have if we waited until after we cleaned up a ton of the technical debt fixed by flask16:23
lbragstador converting to an official framework that wasn't our handrolled-thing16:23
lbragstadbut i completely agree with cmurphy, i would have likely to foreseen that impact sooner =/16:25
lbragstads/likely/liked/16:32
*** hongbin has quit IRC16:37
*** tosky has quit IRC16:39
openstackgerritMerged openstack/governance master: Add Tripleo Ansible repo  https://review.openstack.org/58341617:09
openstackgerritMerged openstack/governance master: Add openstack-chef project  https://review.openstack.org/58547317:12
*** annabelleB has joined #openstack-tc17:22
*** cdent has quit IRC17:29
*** gouthamr is now known as gouthamr_away17:37
*** ricolin has quit IRC17:46
*** annabelleB has quit IRC18:03
kmalloclbragstad: unfortunately, it's hard to see the impact (mostly the cleanup benefits) sometimes18:09
kmalloclbragstad: early on18:09
kmalloclbragstad: also, flask work didn't start right at the beginning of the cycle. =/18:10
*** dtantsur is now known as dtantsur|afk18:24
*** annabelleB has joined #openstack-tc18:27
*** annabelleB has quit IRC18:45
*** annabelleB has joined #openstack-tc18:48
*** mriedem has quit IRC19:11
*** mriedem has joined #openstack-tc19:11
*** tellesnobrega has quit IRC19:31
*** tellesnobrega has joined #openstack-tc19:32
*** annabelleB has quit IRC20:06
*** annabelleB has joined #openstack-tc20:11
*** lbragstad has quit IRC20:51
*** gouthamr_away is now known as gouthamr20:53
*** gouthamr is now known as gouthamr|brb21:20
mnaserhttps://twitter.com/JohnONolan/status/98087250839518822421:20
mnaserinteresting thread to read21:20
*** gouthamr|brb is now known as gouthamr21:20
*** gouthamr is now known as gouthamr|brb21:21
*** diablo_rojo has joined #openstack-tc21:23
jrollneat, thanks for the link21:25
*** zaneb has quit IRC21:27
fungiyeah, that was going around back about the same time slack announced they were going to be getting rid of their irc gateway21:31
*** gouthamr|brb is now known as gouthamr21:40
fungiin discussing with tonyb, changes like https://review.openstack.org/590386 feel a little weird since it's altering the election record after conclusion of the election based on appointments which are the responsibility of the tc, but ni a repository with gerrit acls making it such that the election officials need to be the ones to approve those appointments22:11
fungii understand it's more a matter of picking somewhere official-seeming to have appointee volunteers declare their intent and that there's no good way to track whether someone was appointed vs elected in the current projects.yaml data, so as a compromise it doesn't seem terrible, but still a little weird22:13
*** annabelleB has quit IRC22:14
smcginnisI did think it seems like these TC appointments should be recorded somehow in a governance repo, but... meh.22:15
persiasmcginnis: They are, by means of the changes proposed (and approved) to projects.yaml22:18
persia`git blame` or similar will show which candidates were approved outside of the election process, letting one track down the relevant governance change (and TC discussion)22:19
jrollcould always do a quick TC vote on the ML or with meetbot, and link to that, with the chair's +122:19
smcginnispersia: Yes, just that instead of putting that info also in elections where they were not actually part of any election, it seemed like maybe something else we needed to official state. But it does say TC-APPOINTED, so I was glad to see we at least have that as a breadcrumb for our future selves.22:20
persiajroll: How is that better than something like https://review.openstack.org/#/c/590071/ ?22:20
jrollpersia: specifically I'm talking about changes like https://review.openstack.org/#/c/590386/ where the election results are being modified22:21
jroll(which is what seems weird to fungi)22:21
jrollif folks feel less weird after it's recorded in projects.yaml, then it's moot :)22:22
persiajroll: Yep.  Before posting the link I did, I was searching for the equivalent at https://review.openstack.org/#/q/project:openstack/governance22:22
persiaBut I didn't see one for WinStackers, so there appears not to be a precise equivalent.22:23
diablo_rojoI think if its updated in governance that should be fine- I don't think we really need to also make changes to the elections repo.22:23
fungiin the case of the prior ptl being appointed to continue the seat after missing the nomination window, there's no current precedent for indicating that in the governance data22:24
fungibecause the ptl info doesn't actually change22:24
persiaHrm.22:25
diablo_rojoThat is an interesting conundrum22:25
persiaToo late now, but in future, I suspect that the correct model is for the election update to clear the old data, to be updated after a vounteer volunteers.22:26
persiaIn the unusual situation where a volunteer appears during voting, I'm more comfortable approving it as a late nomination within the election.22:26
persiaBut post-election changes to election data feels wrong somehow.22:27
*** tosky has joined #openstack-tc22:30
*** diablo_rojo has quit IRC22:55
*** evrardjp has quit IRC22:55
tonybI suppose for the *next* PTL election we could produce 2 changes, meant to be merged in rapid succession, one that sets all PTL positions to some placeholder that equates to 'Open pending election results', and a second one that appoints PTLs based on said election.  In the event that a project remains leaderless in an election that will leave scope for a will candidate or the TC to appoint a PTL.23:15
funginote my use of "precedent" there to not preclude extending the data we maintain in the governance repo, should that be a preferable option23:15
tonybI *could* generate such chnages for this election if we think that's a good idea23:16
tonybfungi: I did think of adding simple 'appointed-by' and 'appinted-at' records as well.23:17
persiatonyb: I was thinking just one change, representing election results (including setting to "None" if that is the result of the election).23:19
persiaWith individual changes for the individual appointments, unless everyone believes it makes more sense to appoint everyone at once (but that leaves less for discussion).23:20
fungiyeah, that may make more sense as a future process. election results change to governance removes the ptls for teams which did not elect one, and then the nominees get (re)added in subsequent changes23:23
fungithe other thing which is still missing, which may have been an intended feature of the present solution, is that at least some of them provided campaign platforms in their post-election changes to the election repo23:24
fungii'm not sure ho important that is, as the volunteers could also just provide some similar verbiage in their commit message to governance23:25
*** annabelleB has joined #openstack-tc23:26
*** tosky has quit IRC23:48
tonybOkay do you think there is merit in doign that now?  Have we merged anything to the governance repo that would cause a problem?23:58

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