| *** thingee_ has quit IRC | 00:00 | |
| dims | nice fungi | 01:28 |
|---|---|---|
| fungi | dims: the real exciting infra news of the night is that zuul v3 has moved past self-testing and is self-gating (we've shifted several infra repos over to having zuulv3.openstack.org gate them instead of zuul.openstack.org) | 02:22 |
| smcginnis | Good progress. | 02:43 |
| dims | will ship cinder and get to bed :) | 02:44 |
| smcginnis | ;) | 02:47 |
| *** dtantsur|afk is now known as dtantsur | 08:54 | |
| *** cdent has joined #openstack-tc | 09:05 | |
| *** openstackgerrit has joined #openstack-tc | 09:10 | |
| openstackgerrit | Flavio Percoco proposed openstack/governance master: Allow teams to host meetings in their channels https://review.openstack.org/485117 | 09:10 |
| openstackgerrit | Merged openstack/governance master: Add Barbican wsgi goal completion artifacts https://review.openstack.org/480818 | 09:28 |
| openstackgerrit | Merged openstack/governance master: Removal of installguide-cookiecutter https://review.openstack.org/489907 | 09:35 |
| openstackgerrit | Merged openstack/governance master: charms: Add Gnocchi charm and supporting interfaces https://review.openstack.org/489947 | 09:35 |
| *** sdague has joined #openstack-tc | 10:00 | |
| *** cdent has quit IRC | 11:24 | |
| openstackgerrit | Flavio Percoco proposed openstack/governance master: Drop Technical Committee meetings https://review.openstack.org/459848 | 11:33 |
| *** cdent has joined #openstack-tc | 11:36 | |
| *** mwhahaha has quit IRC | 12:19 | |
| *** mwhahaha has joined #openstack-tc | 12:20 | |
| *** cdent has quit IRC | 12:44 | |
| *** cdent has joined #openstack-tc | 13:18 | |
| *** hongbin has joined #openstack-tc | 13:44 | |
| *** thingee_ has joined #openstack-tc | 14:58 | |
| fungi | on the simplification front, i think the pike cycle is actually a big leap forward: we dissolved three teams (community app catalog, fuel, openstack ux) and added only one (shade which was actually just split off of the existing infra team) | 14:59 |
| thingee_ | fungi: +1 | 14:59 |
| thingee_ | fungi: that’s what I plan to highlight at ptg board | 14:59 |
| fungi | i was putting together the new and removed teams list for the pike press release stuff the foundation marketing team was working on, and only then did i realize we didn't really add new teams (shade only half counts) and got rid of three! | 15:00 |
| cdent | there’s another dimenions of complexity that is equally (maybe more?) important:P | 15:09 |
| cdent | within the services | 15:09 |
| *** dklyle has joined #openstack-tc | 15:15 | |
| *** david-lyle has quit IRC | 15:15 | |
| fungi | yup, parallel efforts are underway to whittle those down too | 15:25 |
| fungi | for example, i talked to sdague about the (still incomplete years later) trusted compute filter in nova being a good candidate to drop as it's more of an attractive nuisance than a feature | 15:26 |
| fungi | stuff like that is ripe for the chopping block | 15:26 |
| cdent | excellent | 15:34 |
| fungi | i think one of the challenges there is that those sorts of bits are hard for people outside the responsible teams to identify, and certainly harder to quantify and track | 15:55 |
| fungi | like, the only reason trusted compute filter came to my attention was that the vmt had gotten questions about it a couple years ago at which point it was in a partially-implemented state and posed a bit of a security risk at the time, then more recently it cropped up in a thread on a (non-openstack) crypto mailing list to which i subscribe and when i looked into the state there, it still hadn't ever | 15:57 |
| fungi | been fixed | 15:57 |
| cdent | I’m sure there’s plenty more of that sort of thing | 15:58 |
| cdent | but the time/energy to audit dead code paths is hard to find | 15:58 |
| cdent | especially since there are plenty of invisible users | 15:58 |
| fungi | so i asked sdague about it, and he confirmed some devs at intel had pushed the partial implementation because it turned out they wanted to be able to say this piece of server hardware they'd started shipping was supported by at least some virtualization platform, and getting "support" (however incomplete) for it into nova was a much lower bar than, say, vsphere | 15:59 |
| cdent | wow | 16:00 |
| fungi | but once they'd given their conference talks and put together glossies to hand out to potential customers, they walked away from actually completing the implementation | 16:00 |
| * cdent sighs | 16:00 | |
| EmilienM | cdent: hi | 16:01 |
| fungi | what's fun is that their pamphlets and whitepapers are still available for download from intel, in case you're interested in using their tpm | 16:02 |
| cdent | EmilienM: hello sir | 16:02 |
| EmilienM | cdent: I'm back from a meetings week, mostly afk. I saw your ping "EmilienM said he’s be willing to structure something like that, if people felt it was appropriate" | 16:02 |
| fungi | (pamphlets and whitepapers talking about how nova supports it, i mean) | 16:02 |
| EmilienM | was it about the retro? | 16:02 |
| cdent | yes | 16:04 |
| cdent | but if you read the rest of the log near there, not everyone was keen on the idea, so it is still a bit up in the air for now | 16:04 |
| cdent | not sure what the next step is | 16:04 |
| *** dtantsur is now known as dtantsur|afk | 16:20 | |
| dtroyer | fungi, cdent: I think that example of half-baked TPM support is one that might be useful as an example of why we should push back harder on checklist features, especially in areas like that where a certain amount of expertise is required just to be able to be credible to talk about it. It wouldn't hurt my feelings if the board were to see that on a list… | 16:23 |
| fungi | dtroyer: agreed, i brought that one up because it serves as a pretty clear-cut example of the sorts of tactical contributions we should be trying to avoid | 16:25 |
| fungi | problem is it was a bit of a trojan horse | 16:25 |
| fungi | having a general framework for attesting to verified boot for virtual machines that booted from verified hypervisors all the way down to the bios is a laudable goal | 16:26 |
| fungi | and sometimes it's hard to tell when a vendor might just be using the project to be able to demo some poc for prospective clients with no intent to follow through on completing the implementation | 16:27 |
| dtroyer | there may have been some of that, and it may have also been due to shifting priorities. This is to me anecdata about trusting proposals from some of our larger sponsor companies that they will actually follow through on these things, especially where someone else is not able to pick it up | 16:29 |
| dtroyer | it isn't the only time we've been burned | 16:29 |
| * cdent looks at all of the numa and pci code | 16:30 | |
| cdent | not that we aren’t still working on that | 16:30 |
| cdent | but duh amn | 16:30 |
| fungi | just stuck in my craw a bit to find publications like https://www.intel.com/content/www/us/en/architecture-and-technology/trusted-execution-technology/trusted-execution-technology-trusted-compute-pools.html and https://www.intel.com/content/www/us/en/architecture-and-technology/trusted-execution-technology/config-trusted-compute-pools-red-hat-enterprise-linux-guide.html | 16:31 |
| fungi | especially given that the filter has been marked "experimental" ever since its introduction some 4 years ago, and has fairly crippling design flaws like bug 1456228 | 16:36 |
| openstack | bug 1456228 in OpenStack Security Notes "Trusted vm can be powered on untrusted host" [Medium,Fix released] https://launchpad.net/bugs/1456228 - Assigned to Michael Xin (michael-xin) | 16:36 |
| dtroyer | totally… makes me want to find a way to bury a hook into an organization that isn't an individual contributor (who gets moved to a new project in two months) for accountability on things like that. In this case I can try to play that role, but we don't have folks like me in every organization that does this | 16:37 |
| fungi | (note that the fix-released there is for the ossn about how nova isn't going to fix it) | 16:37 |
| fungi | https://wiki.openstack.org/wiki/OSSN/OSSN-0059 | 16:37 |
| fungi | dtroyer: agreed, this example happens to have a significant member company embroiled in the situation but there are likely plenty of examples we can find which are for very small/startup vendors as well | 16:39 |
| fungi | and those are likely harder to get similar sorts of traction for a responsible party (or may even go out of business partway through some implementation) | 16:40 |
| dtroyer | true, but with small companies, you half expect there to be a certain volitility in their long-term presence | 16:40 |
| fungi | fair enough | 16:40 |
| dtroyer | now we see we have to expect that from everyone | 16:42 |
| cdent | shoudl done openstack gpl ;)/2 | 16:43 |
| * dtroyer refrains from commenting, except to say that would have limited contributions enough that we may not have had that particular problem to begin with | 16:44 | |
| *** dklyle has quit IRC | 16:44 | |
| *** dklyle has joined #openstack-tc | 16:45 | |
| cdent | it’s probably best to refrain from commenting pretty much any time I throw a ;)/2 | 16:49 |
| *** cdent has quit IRC | 17:08 | |
| *** persia has quit IRC | 17:18 | |
| sdague | fungi: hmmm... I think that's an overstatement of what I said | 17:37 |
| fungi | sdague: sorry, didn't mean to imply you said all of that | 17:38 |
| sdague | but, yeh, they definitely disappeared after it had landed in one release never to be seen again | 17:38 |
| fungi | you confirmed that they never returned to complete the implementation after hyping it | 17:38 |
| sdague | fungi: yes | 17:38 |
| fungi | the reasons for the initial (partial) implementation become clear on reviewing their conference talk and whitepapers/marketing brochures | 17:39 |
| sdague | ah, ok | 17:39 |
| fungi | the fact that they jumped to start using it to sell their product without actually finishing it | 17:39 |
| sdague | yeh, I didn't know that piece of the story | 17:39 |
| fungi | it's tempting to follow hanlon's razor and guess that perhaps they didn't _realize_ they were marketing their product by referring to an incomplete solution which doesn't actually do what unwitting consumers would expect | 17:42 |
| fungi | but occam's razor in this case implies they simply did it because they could | 17:43 |
| fungi | and because there was no real accountability | 17:44 |
| sdague | yeh, that's all fair | 17:45 |
| fungi | i'd be willing to just cite incompetence on their part if other organizations had worked in the community to start implementing that, never finished it, and intel's marketing arm ran with it not realizing it wasn't actually usable | 17:48 |
| fungi | but since it was intel doing the implementation, the evidence is a bit more damning | 17:48 |
| fungi | not trying to pick on intel in particular on this, i expect we can find plenty more examples of other member companies engaged in similar scenarios | 17:49 |
| fungi | and to bring it back around to my original point, these are places we can probably shed some complexity with no real collateral damage | 17:50 |
| fungi | except maybe to companies who were trying to use the cut features to market their products | 17:51 |
| *** thingee_ has quit IRC | 18:07 | |
| *** sdague has quit IRC | 18:17 | |
| dtroyer | I'll stick my neck out a bit and say that in an organization this large, the marketing hypes and the guys pushing code rarely talk directly. And constantly shifting management-level priorities don't help. And this isn't to make excuses, but to complete the 'how we got to this point' picture, and maybe to even help decide if that particular thing can/should just be removed. | 18:28 |
| dtroyer | It would be helpful to me (in chasing this down internally) to have a sense of Nova team's preferences here, fix it or cut it? | 18:28 |
| fungi | dtroyer: by way of history, https://wiki.openstack.org/wiki/OSSN/OSSN-0059 references a discussion from 2 years ago where deprecation was suggested: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067766.html | 19:25 |
| fungi | shane wang pushed back at the time, saying that intel's tcp/oat 3rd-party ci would be online "soon" to address the concerns raised | 19:26 |
| fungi | malinik also raised concerns with removing it | 19:27 |
| fungi | and a third intel contributor who i haven't had any interactions with that i can remember | 19:28 |
| fungi | oh, dulko too | 19:29 |
| fungi | so the only non-intel contributor to that thread who came anywhere close to suggesting it be kept was jogo, whose argument at the time was "people are using this, it is a negligible maintenance burden" | 19:32 |
| fungi | sbauza, johnthetubaguy and mikal seemed good with getting rid of it | 19:34 |
| fungi | fast forward 2+ years, and it's still marked experimental and there's been no further development on it | 19:34 |
| fungi | what i find most interesting is that red hat is the only distro/vendor who published documentation about setting up a deployment using trusted compute pools as far as i can find, and yet rh core reviewers in that thread seemed in favor of dropping it | 19:55 |
| dtroyer | fungi: thanks for the additional background. I want to sort this one it, it is not the kind of thing we can leave hanging like this and expect to be taken seriously. | 20:53 |
| *** lbragstad has quit IRC | 22:17 | |
| *** hongbin has quit IRC | 23:12 | |
| openstackgerrit | Billy Olsen proposed openstack/governance master: Add charm-interface-gluster-peer https://review.openstack.org/484333 | 23:47 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!