Monday, 2018-02-05

*** mtreinish has quit IRC01:58
*** mtreinish has joined #openstack-tc01:59
*** liujiong has joined #openstack-tc02:45
*** kumarmn_ has joined #openstack-tc02:49
*** kumarmn has quit IRC02:52
*** ykarel has joined #openstack-tc03:14
*** gcb has joined #openstack-tc03:37
*** ykarel has quit IRC04:06
*** ykarel has joined #openstack-tc04:07
*** ykarel_ has joined #openstack-tc04:42
*** ykarel has quit IRC04:45
*** coolsvap has joined #openstack-tc05:16
*** ykarel__ has joined #openstack-tc05:40
*** ykarel_ has quit IRC05:43
*** ykarel__ is now known as ykarel06:52
ttxfungi: \o/08:50
*** liujiong has quit IRC09:11
*** liujiong has joined #openstack-tc09:12
*** jpich has joined #openstack-tc09:22
*** ykarel has quit IRC09:29
*** ykarel has joined #openstack-tc09:30
ttxOn the topic of release frequency and LTS, I just read
ttxA few interesting bits if you can read past the OpenStack snark and the self-congratulation tone09:40
ttxK8s supports last 3 releases, so roughly 10 months back09:40
ttxbeen discussing faster/slower release frequency, as well as skipping-upgrades, but so far decided no change09:41
ttxIt seems like they are struggling a bit to have those discussions -- the threads raising them die before they can find a body to make a call09:44
ttxMaybe dims has fresher news09:44
ttx(the article linked above is slanted toward delegating the LTS work to distributions, since it's written by a distributor)09:46
ttxI wonder if our own LTS discussion is not distorted by over-representation of DIY ops in our engaged user community. That would explain why we are struggling to find resources to do it, as a lot of our resources come from distributions, not DIY users.09:49
*** dtantsur|afk is now known as dtantsur10:05
*** liujiong has quit IRC10:22
*** ykarel is now known as ykarel|away10:40
persiaInteresting article.  Despite my typical economic argument that if ops want LTS, they should either donate FTEs or pay vendors sufficiently for the vendors to donate the FTEs, I suspect there are useful discussions to have to ensure there is effective alignment between those producing requirements for OpenStack and those providing resources.10:44
*** ykarel|away has quit IRC10:44
*** cdent has joined #openstack-tc10:45
*** dtantsur is now known as dtantsur|brb12:17
*** gcb has quit IRC12:30
* dims reading13:04
dims" the threads raising them die before they can find a body to make a call" ... yes!13:05
dimssig-architecture is making some progress in their backlog, but progress is slow. pm-sig is like ours, can't direct resources and hard for them to set direction. for example the roll out of KEP processs is taking too much time -
dimsi am kinda heads down on the openstack<->kubernetes stuff. will be proposing a new repo in our infra in a week or two13:11
* cdent wishes he had more spare time to help dims13:15
dimsthanks cdent ! :)13:16
cdentI even have corporate permission to do so, but can't find the time...13:16
cdentthere's a huge list of such things13:16
dimspersia : ttx : fungi : you may have seen this, if not, backlog/minutes from their steering committee -
smcginnisI have been pushing in ops meetup and other discussions that LTS should really be a distro thing.13:26
smcginnisThere's certainly things we could do in the community to make it easier (like skip level upgrade support) but the distros are the ones that are actually providing "support".13:26
smcginnisAnd the DIY folks have made the decision to - do it themselves - so if they want something long term, that's just an implication of choosing to go that route.13:27
*** coolsvap has quit IRC13:34
ttxI've been thinking of ways to get indirect ops (those who consume openstack through some distro) to be more vocal13:49
ttxcurrently they are underrepresented which leads to some perspective distortion when we poll the -ops list to make technical decisions13:50
ttx(they are also underrepresented in the user survey)13:50
cdentYeah, I think that's a pretty big gap.13:50
cdentWhich leads us if not astray, then at least diverts energy13:51
ttxbasically we established a good feedback loop, but it's partial13:51
ttxI'll likely engage with the new UC once the elections are over. Don't want to derail that process13:51
*** kumarmn_ has quit IRC13:56
ttxdims: looks like this Google doc is not public13:57
*** kumarmn has joined #openstack-tc13:57
dimsah you need to join the kubernetes-dev google group @ttx13:57
* ttx sighs13:58
* ttx wonders how one does that13:59
ttxah, that blue button probably13:59
dimsy, and you can set it to not send you any emails too13:59
ttxhm , still not accessing, probably takes some time14:00
dimsack. "Meeting notes are available to members of the kubernetes-dev mailing list" from here -
*** kumarmn has quit IRC14:01
ttxok, accessing now14:02
*** dtantsur|brb is now known as dtantsur14:07
dhellmannttx: if we need to get more user feedback from customers of distributors, maybe we should be asking the distributors more directly?14:14
ttxdhellmann: that's what we are doing for the user survey... we should probably be doing the same for tech feedback14:16
ttxnot sure how to do it in practice14:16
dhellmannalthough presumably all of the contributors who work for distributors are channelling that feedback already14:16
ttxopenstack-distros ML ? Ask distros to join openstack-ops ?14:16
dhellmannif only we had a product management working group to talk to14:17
*** kumarmn has joined #openstack-tc14:18
*** kumarmn has quit IRC14:18
cdentI suspect there are plenty of people who don't even think of the opensource community when they use (or buy) openstack, and as such the surveys are very biased14:19
*** kumarmn has joined #openstack-tc14:19
cmurphyI try to channel feedback from customers into bug reports and blueprints14:19
cmurphysome customers aren't willing or able to engage directly14:20
dhellmannI think we all do, for the things we know about already. The issue is for topics that come up in one corner of the community. It takes a while for the conversation to spread. Is there a way to make that happen more quickly?14:20
*** coolsvap has joined #openstack-tc14:21
dhellmannNot that everyone needs to be involved in everything, but if we want user input to make a technical choice (like "which distribute lock manager should we start with?") it would be nice to have a way to collect that feedback14:21
dhellmannOTOH, maybe we worry about this stuff too much. If people aren't engaged, is that our fault? I feel like we beg for input a lot of the time.14:22
TheJuliadhellmann: That is a good point14:23
cdentMaybe we should try a different strategy: ask for forgiveness14:23
dhellmannor just expect it14:23
* dhellmann may be a little grumpy this morning14:23
* cdent squints at dhellmann 14:23
dhellmannor a big grumpy. it's early.14:24
TheJuliadhellmann: It would be awesome of packagers/distributions were sharing the feedback they are getting from customers, not just what goes into bugs/blueprints, but allow their vendor to come to the community and say "I have a customer with x nodes, y needs, z is a friction point"14:24
TheJuliaTime for fresh coffee?14:24
dhellmannTheJulia : what form do you see that sort of feedback taking?14:24
dhellmannyes, need more tea14:24
cmurphyI think it's to the vendor's advantage to be that representation and to bring that feedback, if they're not doing that it's their loss because it's their customers' loss14:25
TheJuliadhellmann: dialog with the teams going into the ptg would be the most impactful. Operators who have some connections/contacts with team provide a great deal of context that helps in discussions and properly framing problems.14:26
TheJuliadhellmann: If we had teleporters, I would hapilly beam you excess hot water from the kettle this morning14:26
dhellmanncmurphy : right14:26
TheJuliacmurphy: I would worry the vendor has their own vision and plan, and customer feedback might take a backseat to own plans and vision14:27
dhellmannTheJulia : I guess I'm saying, if we have customer A of vendor X and A doesn't *want* to worry about upstream, then how do we know what they want and how much should we care? Isn't that X's responsibility, as cmurphy points out?14:27
cmurphyTheJulia: you don't think the vendor generally has its customers' interests at heart?14:28
cmurphyif customer feedback is taking a backseat that's not a vendor i would choose for anything14:29
dhellmannI don't think it's reasonable for us to assume that the vendor is ignoring their customers. At some point we have to assume that problem would work itself out.14:29
TheJuliaOne point, it is often not a want, but a complete lack of knowledge/understanding or time... or even worse, forbidden by policy. cmurphy is right, it is not X's responsibility, but it is good to steward information they obtain back to the underlying communities.14:29
*** david-lyle has quit IRC14:30
TheJuliacmurphy: more so the thought that all customer feedback is framed in the plans and vision of a vendor, those may not be the plans and visions of a customer. The customer may not share that data, and that intermediate step may warp the feedback as a result. The age old problem of wispering in person's ear next to you and watching the statement change as it crosses the room.14:31
dhellmannhow far do we, as non-vendors to those customers, need to go to solicit their feedback?14:32
*** dklyle has quit IRC14:32
TheJuliaI think, at least ideally, that if we could reduce the steps in any feedback loop, or more directly engage from a community standpoint, that might net us a better understanding of the customer context.14:32
dhellmannare you thinking of any specific steps that could be eliminated?14:33
TheJuliadhellmann: I think it would be in vendors best interests to help facilitate, to say "Hey, if you want to be involved in the long term direction or provide raw feedback/use cases, go to the main community"14:33
dhellmannok, sure. but what could/should we do from the community side?14:34
dhellmannif we want to make it easy to engage with us and obvious that we want that, is there something we need to change?14:35
cmurphyat least one of my customers needed me to proxy for them on a launchpad bug, for some legal reason they didn't go into they wouldn't file it or comment on it themselves14:35
dhellmannhaving a legal reason is interesting. but it seems like the system worked there: they talked to their vendor14:36
cmurphyright - the people who choose to use vendors do so because they want their vendor to represent them in these things14:36
dhellmannttx's original point was that sometimes we want input from those users more directly. maybe there are reasons we *can't* have that sometimes. I'm looking for things we could change that are hindering our ability to get it that we could fix.14:37
dhellmannI try to proxy the other way, fwiw. I don't know the number of threads I've started on our internal list to raise questions from the community with folks at RH who are less focused upstream than I am.14:38
cdentdhellmann: I wonder if we shouldn't be a bit more brazenly open "if you don't tell us, we can't do, so we're going to do this stuff we do know"14:38
TheJuliadhellmann: perhaps all we need is an anonymous tip box....14:38
dhellmannTheJulia : that's an interesting thought experiment. it can be hard to have a conversation with an anonymous party, though.14:39
*** mriedem has joined #openstack-tc14:39
TheJuliaTrue, but their statements, (if of course, well stated) have good context, it is something to help us frame our thoughts and try and start a discussion since it is ultimately, new information14:40
TheJuliaof course, it may also be old, and then there is the issue of spambots14:40
TheJuliacdent: That makes a lot of sense to me14:41
cdentA related thing is for us to have some damn self respect: we do what we think is right until feedback says otherwise. Stop guessing.14:41
dhellmannso if we say we're less concerned with users who are not actively collaborating with us, and we expect customers of vendors to (at least optionally) be represented by those vendors, is everything we're doing now enough? can we do more to get that vendor feedback in different forms? earlier in the process?14:42
TheJuliacdent: ++14:42
cdentdhellmann: I've got to step out, but will think on that while out.14:42
fungian example of missed opportunities to forward feedback: recently in working to bring an arm64-based cloud into our nodepool we discovered we needed gpt/efi support added to dib...14:44
fungithere were no open feature requests for this so the dib team hadn't prioritized it previously14:44
dhellmannfungi : does that mean no one wanted it? or people worked around it?14:45
fungion searching around, i found a bugzilla report against rdo asking for dib to get gpt/efi support14:45
fungiit had never been forwarded upstream14:45
*** rosmaita has joined #openstack-tc14:45
*** gcb has joined #openstack-tc14:46
fungisomething as simple as copy-pasting from bz into a new lp bug would have made a noticeable difference14:47
TheJuliawhen I was at HPE, one of our engineering teams was pushing hard for it. They would collaborate on existing patches, offer up solutions. It was also a time when DIB reviews were not that active and dib was really not tracking work... nor was anyone there to say "Hey, go do x"... eventually they gave up due to resistance14:47
fungiwell, at least the good news is you can now boot uefi-based systems with dib images, it's just unfortunate a major vendor in our ecosystem knew they had customers wanting it already and hadn't told us14:48
TheJuliaso this kind of takes us to the discussion of a single point of truth, or in this case need14:49
dhellmannfungi : does not forwarding it upstream mean the vendor didn't prioritize it?14:49
TheJuliathere are presently WAY too many places for this sort of information to get filed with some of the project overlaps14:49
dhellmannIt doesn't seem likely that we'll get vendors to drop their own issue trackers.14:57
smcginnisAs far as getting more indirect feedback - I wonder if we should put some effort towards having birds of a feather or other types of sessions at things like Red Hat Summit, etc.14:57
dhellmannI'm not sure we want to encourage them to file *everything* upstream either, even if they would.14:57
dhellmannsmcginnis : that's an interesting idea14:57
dhellmannI haven't been to a RHS so I'm not sure how they're organized.14:58
smcginnisStill maybe limited, but it would be one path to try to get more directly to the consumers of those distro releases.14:58
fungidhellmann: i suppose. i mean, in this case it was only a matter of rotting there for a few months, but the sad part is that the comment on the bug indicating dib is where support would need to be implemented was a regular openstack contributor and didn't pass that request along to the project15:01
dhellmannyeah, that sounds like a failure of our internal processes15:01
fungiso even within our established base of contributors we may be able to do a better job of raising awareness15:01
dhellmannso maybe that's -- exactly -- an area we can work on15:02
*** hongbin has joined #openstack-tc15:02
persiaOn leaving LTS to distros: when I was a distro dev, I always preferred when upstream gave us a place to collaborate with other distros: sometimes we created midstream repos when they did not.  From this, I suggest we (openstack) would do well to make distro devs feel part of us when working on LTS branches, and let them use our infra to do it.15:05
smcginnispersia: That sounds reasonable. We tried to actually do that with the stable/* branches though. If we can at least get a couple vendors asking for something like an lts/* to collaborate, I would be all for it.15:09
persiaVendors+DIY ops+cv polishers is likely a better audience.15:11
*** david-lyle has joined #openstack-tc15:42
*** gcb has quit IRC15:47
dhellmannsmcginnis : rather than renaming the branches I like the idea of just not closing them15:54
dhellmannbesides making thing simpler for consumers, it's less work upstream15:54
smcginnisdhellmann: Yes, that would be simpler.15:54
smcginnisI just wonder if we need an explicit name change.15:55
smcginnisWith stable we had some committment from a few vendors that they would support stable longer than our current policy.15:55
dhellmannperhaps we don't want to call the branches "stable" at all any more15:55
dhellmannsince they change "modes" periodically15:55
dhellmannmaybe just series/15:55
smcginnisIt was agreed to since there were multiple that were going to be ther efor it.15:55
smcginnisThen it broke within a couple months and no one ever did anything about it.15:56
smcginnisdhellmann: Oh, I like that. series/ocata would be better. Or at least better than the implied state that stable/ gives.15:56
dhellmannand if we want to "close" a branch we could do that with a job that just always votes -1 with an appropriate message15:57
dhellmanninstead of deleting it15:57
dhellmannhaving to work around a bunch of our processes in reno has made me look for ways to simplify15:57
dhellmannthat and realizing just how much of them are based on the idea of a large pool of 100% time contributors15:58
smcginnisWe definitely need to do more simplification.15:58
smcginnisCode and process wise.15:58
dhellmannyes to both15:58
cdentI like the "series" idea16:00
cdentbut either renaming branches, or using new names in the future, is a lot of changes to thinks like grenade :(16:00
dhellmannis there any reason we couldn't go through all of the projects with open stable branches and create series branches for them?16:01
dhellmannI mean, that's all automated now, so...16:01
dhellmannmaybe renaming is more trouble than it's worth -- that's what we decided when we changed the release processes16:02
openstackgerritHongbin Lu proposed openstack/governance master: Add devstack-plugin-container to QA team
ttxyes, we considered renaming them to series/ in the past (when we dropped release/) but decided too much stuff assumes stable/17:22
TheJuliawhy was release/ dropped? it seems kind of logical to me.. it was a release branch, it still is, it might just not be released from again17:27
dhellmannTheJulia : it was only called that during the period where the release was being finalized, and then immediately renamed to stable17:32
dhellmannthe renaming took a  lot of coordination, so we decided to just go right to stable and adjust acls on the branch instead17:32
TheJuliaso it doesn't seem like there would be an issue going back to release/ if we wanted17:33
*** jpich has quit IRC17:35
dhellmannexcept the increasing amount of tooling built around the literal string "stable/"17:35
*** dtantsur is now known as dtantsur|afk17:53
*** david-lyle has quit IRC18:01
fungialso renaming long-lived existing branches would generate much downstream disruption for people tracking those branches18:17
fungithere is no such thing as a redirect in git reference names. closest may be a lightweight tag at the old branch name pointing to the new branch name, but i expect that would still not do much other than make `git checkout <oldname>` work, i doubt it would solve `git pull` in tracking branches with the old name18:19
fungiif we wanted to do it, nicest would be to update all our toolig to treat "stable/" and "series/" identically, and then transition to the new naming pattern only with newer releases while the stable/.* branches for older releases age out and get eol'd18:26
fungithough if we're dropping the idea of deleting branches at eol, then we effectively can't ever remove the handling for the old pattern18:26
dhellmannfungi : right, and if we can't drop it, let's not complicate matters further by adding another name18:39
dhellmannas nice as it is to have "correct" names, sometimes practicality beats purity18:40
*** david-lyle has joined #openstack-tc18:57
*** harlowja has joined #openstack-tc19:03
*** coolsvap has quit IRC19:04
cdentTheJulia: woot on ironic ptl self-nomination. Can you describe what "My vision is for ironic to be utilized in more use cases outside of what we have typically seen as our primary user." means? Who is the primary user and who are the other ones you'd like to make happen?19:09
TheJuliacdent: Primary user being nova, so I think it would be good to encourage the ecosystem of those who don't interact with ironic through nova.19:10
cdentah, excellent. yes please.19:10
TheJuliaLargely, that seems to be large operators who are more focused on managing baremetal as they see fit. It is not as cloudy, but we know people are doing it today19:11
TheJuliaso it behooves us to support their efforts and try to better bring those users into the fold19:11
fungiinfra-cloud used ironic via bifrost to manage the systems on which we puppeted our openstack deployment19:12
fungiit was quite a nice setup (while it lasted)19:12
fungi[r.i.p. infra-cloud]19:12
cdentfungi: I don't know anyone who wants to do this, so this is entirely theoretical: But supposing some organization wanted to donate money for infra to buy AWS capacity for including in the CI pool. Would that be workable?19:18
fungicdent: eventually probably (or more likely donate access to their account), but not until nodepool grows aws support19:19
fungii don't think we'd want the foundation stuck acting as a go-between on funds for that19:19
fungidonating access to something someone else pays for directly tends to work out better for us19:20
cdentI was thinking about in more in terms of whether it would be philosophical ikcy19:21
cdenttotally unrelated, I've managed to capture one of my biggest concerns about openstack collaboration in a tweet:
fungiit's likely nodepool will grow support for non-openstack cloud platforms anyway, since we're seeing an increasing number of non-openstack downstream users (right now their only option is to define static job nodes)19:21
fungii wouldn't be surprised if in another year or two nodepool had support for azure, aws, gce...19:22
cdentseems sane19:24
dims++ fungi19:25
fungii still expect openstack to be our primary backend19:26
fungialso one of the bits we're missing today is the ability to segment nodepool for better multi-tenancy so that different projects can get their own resource assignments (for example, someone wants to donate an aws account to augment testing for kata containers but doesn't want it used for other purposes)19:28
fungiwell, s/projects/communities/ probably19:28
fungior what the foundation is calling "strategic focus areas"19:29
fungiall stuff i expect to come up at the ptg for people bored^H^H^H^H^Hinterested enough to hang out in the infra room19:30
TheJuliafungi: perhaps obtain a hypnotoad?19:30
fungiall glory to the hypnotoad19:32
cdentI need to warm up the clone machine for the PTG. I need to start soon as each clone takes a few days to be ready and I've only got the one machine.19:38
TheJuliaI guess clones make more sense than teleportation....19:39
* dhellmann dusts off his time-turner19:49
*** diablo_rojo_ has quit IRC20:13
*** rockyg has joined #openstack-tc20:13
*** diablo_rojo_ has joined #openstack-tc20:15
*** cdent has quit IRC20:32
fungii just project a holographic presence into all the rooms20:34
fungi[please state the nature of the medical emergency]20:34
openstackgerritManoj Kumar proposed openstack/governance master: Fourth phase of the deprecation of trove-integration
dmsimardfungi: +1 for bifrost but I still haven't found something that was simpler than a PXE server :)21:37
*** rockyg has quit IRC21:39
fungidec mop21:43
fungiat least if all you needed to boot were lat terminal servers21:45
dmsimardfungi: decnet seems to predate my career (or even my birth) :/21:46
fungiyou're making me feel old21:46
dmsimardsorry :(21:47
funginot your fault, i have plenty of other reasons to feel old too21:49
dmsimardah, actually I recently learned that saying "sorry" can be interpreted very differently outside Canada.. I'm going to need to really think twice about how I use it moving forward21:50
fungiit's quite the staple of canadian english vernacular, so i've come to interpret it based on where i think someone originates21:51
*** kumarmn has quit IRC23:45
*** kumarmn has joined #openstack-tc23:45
*** kumarmn has quit IRC23:50
*** hongbin has quit IRC23:53

Generated by 2.15.3 by Marius Gedminas - find it at!