Wednesday, 2018-05-16

*** dklyle has quit IRC00:24
*** dklyle has joined #openstack-tc00:32
*** dklyle has quit IRC00:53
fungitc-members: wednesday muster drill! er, office hour!01:01
fungior keep plugging away at your forum prep01:01
* mnaser is in an out01:01
mnaserBut I think for the most part things are quiet because of prep.01:02
fungifor prep definitions of quiet at least01:02
*** edmondsw has joined #openstack-tc01:18
*** dklyle has joined #openstack-tc01:20
*** annabelleB has joined #openstack-tc01:22
*** edmondsw has quit IRC01:22
*** mriedem_afk has quit IRC01:27
*** dklyle has quit IRC01:29
*** rosmaita has quit IRC02:09
*** annabelleB has quit IRC02:17
*** annabelleB has joined #openstack-tc02:41
openstackgerritSteve Baker proposed openstack/governance master: Import ansible-role-tripleo-modify-image
*** ricolin has joined #openstack-tc03:15
*** edmondsw has joined #openstack-tc04:32
*** dtantsur|afk has quit IRC04:38
*** jaosorior has quit IRC04:40
*** annabelleB has quit IRC04:44
*** jaosorior has joined #openstack-tc04:47
*** kumarmn has joined #openstack-tc04:52
*** jaosorior has quit IRC04:54
*** jaosorior has joined #openstack-tc05:02
*** kumarmn has quit IRC05:17
*** kumarmn has joined #openstack-tc05:18
*** kumarmn has quit IRC05:23
*** edmondsw has quit IRC06:49
*** dims has quit IRC07:59
*** dims has joined #openstack-tc08:02
*** dims has quit IRC08:07
*** dims has joined #openstack-tc08:07
*** edmondsw has joined #openstack-tc08:20
*** edmondsw has quit IRC08:25
*** cdent has joined #openstack-tc08:57
*** dtantsur has joined #openstack-tc09:43
*** edmondsw has joined #openstack-tc10:08
*** edmondsw has quit IRC10:13
*** corvus has quit IRC10:29
*** corvus has joined #openstack-tc10:30
*** notmyname has quit IRC10:33
*** notmyname has joined #openstack-tc10:34
*** cdent has quit IRC10:51
*** kumarmn has joined #openstack-tc10:54
*** kumarmn has quit IRC11:06
*** jaosorior has quit IRC11:23
*** kumarmn has joined #openstack-tc11:27
*** kumarmn has quit IRC11:32
*** cdent has joined #openstack-tc11:33
*** jaosorior has joined #openstack-tc11:42
*** edmondsw has joined #openstack-tc11:57
*** edmondsw has quit IRC12:01
*** mriedem has joined #openstack-tc12:05
*** edmondsw has joined #openstack-tc12:07
*** edmondsw has quit IRC12:07
*** kumarmn has joined #openstack-tc12:19
fungiwhatever became of the discussion about adding barbican to the base services list? or was the decision that castellan could eventually be added instead?12:20
*** kumarmn has quit IRC12:24
*** dklyle has joined #openstack-tc12:30
*** edmondsw has joined #openstack-tc12:36
*** dklyle has quit IRC12:39
*** rosmaita has joined #openstack-tc12:41
*** annabelleB has joined #openstack-tc13:02
dhellmanntc-members: in case you didn't notice the wiki page edit, here's the slide deck I've prepared for the leadership meeting this weekend:
dhellmannI've tried to put some of what I intend to say in the speaker notes, but please let me know if you have any questions13:04
dhellmannfungi : good question; I'm not sure castellan is a replacement for barbican per se13:04
*** kumarmn has joined #openstack-tc13:08
*** annabelleB has quit IRC13:08
*** kumarmn has quit IRC13:13
fungimain reason i ask is once again raises the specter of "well, yes, that feature would be nice, but it means we'd have to also run barbican"13:15
mnaserfungi, dhellmann: i'm pretty sure castellan is a library which has 'drivers' that include barbican.  looking at the code, it seems to have a 'vault' driver too13:15
mnaserby vault:
fungiso "all openstack services should be able to expect the availability of a key management service" would be nice13:16
mnaserthe idea is that projects that use python-barbicanclient directly forces the use of barbican, but using castellan allows the project to have different secret storage mechanisms (not necessarily barbican)13:16
mnaserbarbican is super lightweight imho.13:17
fungimnaser: yeah, i'm aware of the differences between barbican and castellan, i just couldn't remember which we ultimately said should be a candidate for
mnasermore and more projects are depending on key management13:18
dhellmannfungi : yeah, there may be special limitations on the footprint size for a tripleo undercloud, I'm not sure.13:18
mnaseroctavia and magnum both use it13:19
mnaserand i assume cinder as well for encrypted volumes too13:19
dhellmannI feel like we want to encourage projects to use castellan to give deployers flexibility, especially in light of the existing variety of key managers out there13:19
dhellmannthat's certainly the direction we're taking with adding support for secret storage to oslo.config13:19
mnaserdhellmann: i agree13:19
fungihowever, if we're going down the road of openstack services generally expecting to be able to have key management available, then it actually encourages security even in places like the tripleo undercloud13:19
dhellmannyes, I also think it's wise to say we expect *a* key manager to be present13:20
mnaserthat would mean that projects have to adopt castellan, i'm not sure who has and hasn't yet13:20
mnaserlooks like octavia already has it13:21
mnaserlooks like magnum is lacking it13:21
fungiso back to my original question... i remember it got discussed a couple of forums back and unfortunately i was in another session at the time, so was trying to remember if castellan was the upshot of the original pushback to including barbican in the lase layer13:21
dhellmannI don't remember that specifically (I may not have been in that session either) but I would support that position today13:21
fungiif nobody recalls off the top of their heads, i'll go hunt down an etherpad13:22
mnaserlikewise (re: castellan adoption)13:22
*** frickler has joined #openstack-tc13:43
*** zhipeng has joined #openstack-tc13:57
*** kumarmn has joined #openstack-tc14:02
*** annabelleB has joined #openstack-tc14:07
*** kumarmn has quit IRC14:07
*** annabelleB has quit IRC14:17
ttxyeah, so castellan is an interface that lets you consume multiple secrets stores. The issue last time we discussed it was that some projects were directly consuming Barbican rather than the more narrow set of features Castellan exposes14:20
ttxcastellan would otherwise be a good pick ("A Castellan-supported secret store" being added to base services)14:21
fungiafter some hunting, i've found a breadcrumb...
fungiat least now i know what timeframe to check the ml for14:21
cdentSo is my understanding correct here that the new way to be an openstack project, without having to worry about dealing with all the exisiting weight of OpenStack (capitals intentional) is to just talk to the foundation and make a new neighbor project?14:24
ttxdhellmann: slide 8 features the OpenStack proposal bot as a contributor, is that intentional ?14:24
ttxcdent: well it depends on what you mean by "openstack project"14:25
ttxIt's clearly not a great product fit for "OpenStack"14:25
ttxIt's a deployment system for OpenStack, Kubernetes and other things14:25
mugsieYeah - that is why I am confused why it is under openstack/*14:25
ttxWell everything is under openstack in our infrastructure, that's another problem14:26
ttxWhich is why I wanted to flatten the git space14:26
mugsieI thought that was being dealt with as part of these new groups?14:26
ttxwell zuul is still openstack-infra/zuul afaict14:26
ttxAlso at this point it's more a stackforge-like thing14:27
ttx(which still leaves unde openstack/)14:27
mugsieyeah, seen as zuul-ci is not announced yet, i figured that might change post summit14:27
ttxbut yes, I agree that openstack/airship sounds weird14:27
ttxand we'll need to fix that once we have a proper solution for our git properties14:28
mugsieI am also confused why it needs to be in the OSF but, I haven't heard anything about it until I spotted that infra change go by14:29
mugsiettx: when was this kicked off? I have been to all public board meetings since SYD, and heard nothing about this14:30
ttxWe host a lot of projects in "unofficial" space aka stackforge14:31
ttxi don't know much about any one of them ?14:31
mugsiesure, but none of them are becoming a member of the foundation14:32
fungiproject managed by the foundation14:32
fungi"member" has much different connotations14:32
mugsie s/member/sub project of/14:32
mugsiefungi: yes, I worded that badly14:33
fungii get the impression they're trying to decide whether it goes in the edge or containers strategic focus area14:33
fungiif containers, it would be a sibling of kata14:33
fungiif edge, it would be the first project there14:33
mugsie sets up a new ML domain, so ity looks like a new area entirely14:33
ttxthe board gave the OSF staff the ability to incubate focus areas and pilot projects last board meeting -- this one is very much work in progress, hosting it under stackforge is step -114:34
*** kumarmn has joined #openstack-tc14:34
fungiand yes, next real step in genericizing our infrastructure hosting and no longer having openstack plastered over everything is for the infra team to bikeshed on a name for that hosting environment so that we can move things like to a less-openstacky domain14:34
fungimugsie: not a new strategic focus area, just a new project14:35
ttxPersonally I'm excited to see them willing to use our project infrastructure rather than just go to GitHub to collect stars14:35
fungiin the same way that openstack is a project or zuul is a project or kata is a project14:35
mugsiefungi: I thought that is what we were labeling things like kata / edge / zuul14:36
fungizuul is in the ci/cd strategic focus area, kata is in the containerization strategic focus area, openstack is in the open infrastructure strategic focus area14:36
ttxmugsie: you should come to my talk on Monday !14:36
fungimugsie: one positive side effect is that when openstack has no siblings it looks to the rest of the world like a collection of random parts, but once it has a sibling it can be "not that other thing" and so looks like a thing unto itself? ;)14:38
jbrycethe focus areas (datacenter, edge, containers, ci/cd) are basically buckets of related efforts around a specific kind of use case (could be a project with code like kata, could be a working group like edge, could be an opendev event like for ci/cd)14:38
fungiahh, yes, i said open infrastructure when i meant datacenter14:38
ttxfungi: you should come to my talk too !14:39
* fungi is still trying to get used to the new terminology14:39
*** kumarmn has quit IRC14:39
jbrycethere's also overlap between the focus areas (openstack services are used in edge deployments and container deployments, zuul is run in enterprise clouds)14:40
mugsieOK. I am assuming airship will come up on Sunday anyway?14:41
jbryceairship is very new and at this point, the devs are focused on getting their repos set up and starting to build a community14:41
jbryceit's not at a big announcement stage, so this isn't like kata launch in december14:42
jbryceit's more like any of the other unofficial projects that start out using community infra to try to start developing in the open and building a community14:43
fungii also see it as the emergent state of the discussions we've been having recently about what to do with projects who apply to be part of openstack even when they're not a great fit and would stretch the already strained scope we're struggling to define14:44
fungiairship didn't apply to be a component of openstack, but if they did i expect we'd raise similar concerns14:45
ttxsame concerns we had with StackKube14:47
ttxwhich was also a bad product fit14:47
fungiso, yeah, just another "unofficial" project from the openstack tc's perspective, but one which wants to seek guidance and perhaps assistance from the openstack foundation on building their community14:49
ttxthat is how I see it yes14:50
fungithough as we go down the road of genericizing the community infrastructure, the term "unofficial" will get a bit muddy (it may not be officially openstack, but could be officially something else)14:50
ttxI would be concerned if the project had overlap with openstack (in which case it could be seen as a run-around) but that's not the case here14:51
fungithough i'll warrant the brief project description used in the new project creation change didn't make that entirely clear (deploying openstack on bare metal...)14:51
ttxI don't know that much about it but it looks separate and complementary14:52
ttxI will look at it once the repos are moved :)14:52
*** dklyle has joined #openstack-tc14:53
fungifrom the repo description for divingbell is "a lightweight solution for configuration of baremetal nodes" and the commit message states "interface for deploying a bare metal Kubernetes cluster at scale to facilitate integrated deployment of OpenStack on Kubernetes using the existing OpenStack-Helm project"14:54
*** annabelleB has joined #openstack-tc14:55
fungiso those didn't make it super clear that it's not primarily openstack-focused, nor that it doesn't at least partly compete with things like ironic/bifrost14:55
fungihence, why i can understand that people might have been a little confused14:56
ttxindeed, we need to learn more14:56
mugsieor why it is not part of the helm projecty14:57
jbrycemugsie: helm in kubernetes or openstack-helm?14:57
jbryceit uses openstack-helm but it's kind of downstream from that14:58
mugsieis it? I just runs daemonsets on each node that does config-management14:59
mugsie(from what I can tell anyway)14:59
mugsieI could see that as a sidecar to os-helm, like os-security-hardening started as a sidecar to OSA15:00
jbryceit does things that are not in scope for openstack-helm and that are not related to openstack services15:00
jbrycelike bootstrapping a kubernetes environment that may or may not run openstack services at all15:00
jbryceplus a bunch of declarative config management stuff that may or may not relate to openstack-helm and openstack services15:01
jbryceif you are wanting to use openstack-helm you can do that without other airship components15:01
jbryceand you can use other airship components without openstack-helm15:01
mugsieah, right now, it doesn't bootstrap, and does basic cfgmgmt, so it looked more like an add-on than a thing of its own15:02
*** hongbin has joined #openstack-tc15:04
jbrycelike i said, it's still early on in the project and i've encouraged them to open it up earlier than waiting until it's "done"15:09
fungiin the spirit of
jbryceand the existing devs i think see the benefit to starting that earlier than later15:10
fungihard to believe that article is 12 years old now15:10
fungii was looking back at some forum discussion for one of netflix's open source projects recently, at the discussion around how they would "open source the 2.0 version any day now" and how much i sometimes take our default in-the-open processes for granted15:12
*** dklyle has quit IRC15:12
fungier, thought about how much i take it for granted15:13
dhellmannttx: yeah, I left the bot in because I figured we could talk about how even with automation we need help15:15
*** zhipeng has quit IRC15:17
*** dklyle has joined #openstack-tc15:18
*** kumarmn has joined #openstack-tc15:24
*** dklyle has quit IRC15:24
*** dklyle has joined #openstack-tc15:26
*** dklyle has quit IRC15:31
ttxmakes sense15:31
openstackgerritMatt Riedemann proposed openstack/project-team-guide master: Update dependency-management doc
*** kumarmn has quit IRC15:40
*** kumarmn has joined #openstack-tc15:40
*** kumarmn has quit IRC15:45
*** kumarmn has joined #openstack-tc16:02
*** kumarmn has quit IRC16:02
*** kumarmn has joined #openstack-tc16:03
*** kumarmn has quit IRC16:03
*** kumarmn has joined #openstack-tc16:03
*** kumarmn has quit IRC16:04
*** kumarmn has joined #openstack-tc16:04
*** kumarmn has quit IRC16:05
*** kumarmn has joined #openstack-tc16:05
*** kumarmn has quit IRC16:07
*** kumarmn has joined #openstack-tc16:08
*** edmondsw has quit IRC16:15
fungieventually found the forum etherpad i was looking for...
cdentthe fatal flaw of etherpads16:16
fungiunfortunately i can't quite make out if the consensus was that we should work toward adding castellan or barbican to base services16:17
cdentsecondary flaw of etherpads :)16:17
fungisecond of many, i'll warrant16:18
fungiat least i can skim the dev ml from may to see if there was a followup summary posted16:18
smcginnisFrom my very poor memory, I thought things leaned towards Castellan.16:18
*** edmondsw_ has joined #openstack-tc16:18
smcginnisKind of like tooz, I think we want a pluggable shim in there rather than directly relying on a specific service.16:20
*** edmondsw_ has quit IRC16:23
ttxsmcginnis: yes same here16:25
*** annabelleB has quit IRC16:41
mriedemas of barbican adoption in production is 7%, why would we say it's a base service?16:42
mriedemgranted barbican is a castellan api implementation but are there a large number of deployments using castellan with something that's not barbican?16:42
smcginnisI think it's a more general need for encryption key provider services.16:42
mriedemit's still not run in base devstack / integrated gate16:43
mriedemi guess that would be part of the on-ramp toward making it a base service?16:43
mriedemi'm semi interested because of the trusted_certs blueprint in nova16:46
*** annabelleB has joined #openstack-tc16:49
*** kumarmn has quit IRC16:51
*** kumarmn has joined #openstack-tc16:52
*** dtantsur is now known as dtantsur|afk16:58
*** kumarmn has quit IRC17:00
*** kumarmn has joined #openstack-tc17:03
fungimriedem: it was more the chicken-and-egg problem. nobody deploys barbican because no projects require it, and no projects are willing to require it because nobody deploys it17:19
fungiand the risk then is that they all reimplement key management solutions of their own in subtly different ways because what they really need is a consistent solution provided to them which none of them are willing to rely on17:20
*** diablo_rojo has quit IRC17:21
fungiand yeah, as i feared, i'm turning up no summary writeup to the ml for the forum session associated with that etherpad, but it seems like we're basically still in the same place we were a year ago17:22
dhellmanntc-members: items 1 and 3 from this list resonated with me:
smcginnisI think you're right. I don't recall seeing any follow on activity from that session.17:27
smcginnisdhellmann: Looks like a good and relevant article for many right now.17:28
dhellmannmriedem , fungi : right, the idea of declaring base services is not to say they are required, but that if another project wants to use those features that's OK *even if adoption is currently low* because we think that's the right direction to be taking17:28
dhellmannso it's "allowed" rather than "required"17:30
dhellmannI think the more generic "key store" is better, although barbican seems like it could be a reasonable default for that17:31
zanebdhellmann: it's effectively required for distros/installers17:36
*** kumarmn has quit IRC17:39
*** kumarmn has joined #openstack-tc17:39
fungii took it to the ml. let's see if we can get renewed traction17:42
fungii now realize i probably should have tagged it for [oslo] too17:43
dhellmannzaneb : that depends on the configurations those things support, though, right?17:44
*** kumarmn has quit IRC17:44
mriedemdhellmann: huh, ok, i didn't know there was an allowed barrier even, nova/cinder require barbican already if you're doing encrypted volumes attached to servers17:45
fungii'm more concerned with projects choosing to leave out useful security features because they're worried it would mean deployments would need barbican or something like it17:45
mriedemi mean, you can do that w/o a real key manager, but you'll have a lot of fun warnings in the logs17:45
mriedembut encrypted volumes aren't required17:46
mriedemwe gate on an essentially noop key manager though17:46
fungithis is sort of a meta-argument in the tripleo case, because it's tripleo choosing not to make use of a security feature in swift because it would mean using barbican17:46
fungiand while i understand the potential (space, performance, complexity) concerns with the undercloud layer service choices, i want to make sure that the choice isn't being imbalanced by not considering a key store to be a standard feature of openstack17:48
*** ricolin has quit IRC17:50
fungior to put it another way, how many potential security features do you have to decide not to enable by default because they would need a key store, before you decide that expecting the key store to be there is warranted?17:51
jrollthis has some words about key management at the BOS PTG, though don't think it's the same session as that etherpad
fungiyeah, i found that thread earlier (which is what led me to find the right forum), but it predates the forum by months17:52
dhellmannmriedem : for a specific feature, that's OK. I think the idea here is we might say service X doesn't work at all if there is no key store, and to say *that* we would want to put it in the base services list17:52
dhellmannfungi : that point about leaving out features is also a good point. we need projects to be willing to say "yes, this only works if you have the required thing installed"17:53
fungidhellmann: that wasn't the criteria we used to put etcd in the base services list, was it?17:53
notmynameFWIW, at-rest encryption in swift doesn't *require* barbican. you can set a master key in a config and it will work with no other project dependencies. of course, if you want the KMIPS or other KMS integration, you'll need barbican17:53
dhellmannfungi : we said there that projects are allowed to consider it a requirement, right?17:53
dhellmannhow else would that be interpreted?17:53
fungidhellmann: we did, but projects wanting to rely on it wasn't the trigger? i thought it was more that we wanted projects to stop rolling their own solutions because they couldn't count on a standard one17:54
dhellmannoh, sure, yeah17:54
fungimaybe two sides of the same coin17:54
dhellmannso I guess that's another path to entry to that list17:54
fungibut my (admittedly spotty) recollection is that projects were already doing dlm type things just all differently17:55
dhellmannI guess the list is a message to deployers that we think it's OK to use these things, and that we're not going to ask teams to go out of their way to avoid using them17:55
dhellmannyeah, that sounds about right17:55
dhellmannmaybe we should write some of this up and clarify it on the base services list17:55
dhellmanndoes anyone want to take a stab at that?17:55
fungii'll give it a shot17:56
dhellmanncool, thanks17:56
fungiwhat do you think... like maybe a rationale section with a paragraph or two covering our reasoning beyond the definition and process specifics?17:57
dhellmannlet me look at what's there now...17:57
fungithe definition is succinct, and i wouldn't want to risk muddying it with additional prose17:58
dhellmannyeah, I think adding a rationale section makes sense17:58
fungiso keeping the rationale separate from the definition hopefully avoids that17:58
*** kumarmn has joined #openstack-tc18:08
*** kumarmn has quit IRC18:13
*** diablo_rojo has joined #openstack-tc18:14
*** edmondsw has joined #openstack-tc18:57
*** mriedem1 has joined #openstack-tc19:09
*** mriedem has quit IRC19:11
*** mriedem1 is now known as mriedem19:15
*** dklyle has joined #openstack-tc19:18
*** dtroyer has quit IRC19:28
*** dtroyer has joined #openstack-tc19:28
openstackgerritJeremy Stanley proposed openstack/governance master: Include a rationale for tracking base services
*** david-lyle has joined #openstack-tc19:49
*** dklyle has quit IRC19:51
openstackgerritDoug Hellmann proposed openstack/governance master: fix stein goals build
*** annabelleB has quit IRC20:05
*** diablo_rojo has quit IRC20:09
*** annabelleB has joined #openstack-tc20:28
*** annabelleB has quit IRC20:36
openstackgerritJeremy Stanley proposed openstack/governance master: Include a rationale for tracking base services
*** cdent has quit IRC20:56
*** mriedem is now known as mriedem_afk21:41
*** pabelanger has quit IRC22:15
*** hongbin has quit IRC22:25
*** andreaf has quit IRC22:29
*** andreaf has joined #openstack-tc22:29
*** pabelanger has joined #openstack-tc22:34
*** edmondsw has quit IRC22:50
*** edmondsw has joined #openstack-tc23:11
*** pabelanger has quit IRC23:17
*** pabelanger has joined #openstack-tc23:20
*** annabelleB has joined #openstack-tc23:44
*** annabelleB_ has joined #openstack-tc23:47
*** annabelleB has quit IRC23:48
*** annabelleB_ is now known as annabelleB23:48
*** annabelleB has quit IRC23:56

Generated by 2.15.3 by Marius Gedminas - find it at!