| *** dklyle has quit IRC | 00:24 | |
| *** dklyle has joined #openstack-tc | 00:32 | |
| *** dklyle has quit IRC | 00:53 | |
| fungi | tc-members: wednesday muster drill! er, office hour! | 01:01 |
|---|---|---|
| fungi | or keep plugging away at your forum prep | 01:01 |
| * mnaser is in an out | 01:01 | |
| mnaser | But I think for the most part things are quiet because of prep. | 01:02 |
| fungi | for prep definitions of quiet at least | 01:02 |
| *** edmondsw has joined #openstack-tc | 01:18 | |
| *** dklyle has joined #openstack-tc | 01:20 | |
| *** annabelleB has joined #openstack-tc | 01:22 | |
| *** edmondsw has quit IRC | 01:22 | |
| *** mriedem_afk has quit IRC | 01:27 | |
| *** dklyle has quit IRC | 01:29 | |
| *** rosmaita has quit IRC | 02:09 | |
| *** annabelleB has quit IRC | 02:17 | |
| *** annabelleB has joined #openstack-tc | 02:41 | |
| openstackgerrit | Steve Baker proposed openstack/governance master: Import ansible-role-tripleo-modify-image https://review.openstack.org/568727 | 02:49 |
| *** ricolin has joined #openstack-tc | 03:15 | |
| *** edmondsw has joined #openstack-tc | 04:32 | |
| *** dtantsur|afk has quit IRC | 04:38 | |
| *** jaosorior has quit IRC | 04:40 | |
| *** annabelleB has quit IRC | 04:44 | |
| *** jaosorior has joined #openstack-tc | 04:47 | |
| *** kumarmn has joined #openstack-tc | 04:52 | |
| *** jaosorior has quit IRC | 04:54 | |
| *** jaosorior has joined #openstack-tc | 05:02 | |
| *** kumarmn has quit IRC | 05:17 | |
| *** kumarmn has joined #openstack-tc | 05:18 | |
| *** kumarmn has quit IRC | 05:23 | |
| *** edmondsw has quit IRC | 06:49 | |
| *** dims has quit IRC | 07:59 | |
| *** dims has joined #openstack-tc | 08:02 | |
| *** dims has quit IRC | 08:07 | |
| *** dims has joined #openstack-tc | 08:07 | |
| *** edmondsw has joined #openstack-tc | 08:20 | |
| *** edmondsw has quit IRC | 08:25 | |
| *** cdent has joined #openstack-tc | 08:57 | |
| *** dtantsur has joined #openstack-tc | 09:43 | |
| *** edmondsw has joined #openstack-tc | 10:08 | |
| *** edmondsw has quit IRC | 10:13 | |
| *** corvus has quit IRC | 10:29 | |
| *** corvus has joined #openstack-tc | 10:30 | |
| *** notmyname has quit IRC | 10:33 | |
| *** notmyname has joined #openstack-tc | 10:34 | |
| *** cdent has quit IRC | 10:51 | |
| *** kumarmn has joined #openstack-tc | 10:54 | |
| *** kumarmn has quit IRC | 11:06 | |
| *** jaosorior has quit IRC | 11:23 | |
| *** kumarmn has joined #openstack-tc | 11:27 | |
| *** kumarmn has quit IRC | 11:32 | |
| *** cdent has joined #openstack-tc | 11:33 | |
| *** jaosorior has joined #openstack-tc | 11:42 | |
| *** edmondsw has joined #openstack-tc | 11:57 | |
| *** edmondsw has quit IRC | 12:01 | |
| *** mriedem has joined #openstack-tc | 12:05 | |
| *** edmondsw has joined #openstack-tc | 12:07 | |
| *** edmondsw has quit IRC | 12:07 | |
| *** kumarmn has joined #openstack-tc | 12:19 | |
| fungi | whatever 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 IRC | 12:24 | |
| *** dklyle has joined #openstack-tc | 12:30 | |
| *** edmondsw has joined #openstack-tc | 12:36 | |
| *** dklyle has quit IRC | 12:39 | |
| *** rosmaita has joined #openstack-tc | 12:41 | |
| *** annabelleB has joined #openstack-tc | 13:02 | |
| dhellmann | tc-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: https://docs.google.com/presentation/d/1wsPfeGC83I5C8s6-9tlsxz49bBRY5PHdIdXGxutVqgA/edit#slide=id.p | 13:03 |
| dhellmann | I've tried to put some of what I intend to say in the speaker notes, but please let me know if you have any questions | 13:04 |
| dhellmann | fungi : good question; I'm not sure castellan is a replacement for barbican per se | 13:04 |
| *** kumarmn has joined #openstack-tc | 13:08 | |
| *** annabelleB has quit IRC | 13:08 | |
| *** kumarmn has quit IRC | 13:13 | |
| fungi | main reason i ask is http://lists.openstack.org/pipermail/openstack-dev/2018-May/130546.html 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 |
| mnaser | fungi, 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 too | 13:15 |
| mnaser | by vault: https://www.vaultproject.io/ | 13:16 |
| fungi | so "all openstack services should be able to expect the availability of a key management service" would be nice | 13:16 |
| mnaser | the 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 |
| mnaser | barbican is super lightweight imho. | 13:17 |
| fungi | mnaser: 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 https://governance.openstack.org/tc/reference/base-services.html | 13:17 |
| mnaser | more and more projects are depending on key management | 13:18 |
| dhellmann | fungi : yeah, there may be special limitations on the footprint size for a tripleo undercloud, I'm not sure. | 13:18 |
| mnaser | octavia and magnum both use it | 13:19 |
| mnaser | and i assume cinder as well for encrypted volumes too | 13:19 |
| dhellmann | I 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 there | 13:19 |
| dhellmann | that's certainly the direction we're taking with adding support for secret storage to oslo.config | 13:19 |
| mnaser | dhellmann: i agree | 13:19 |
| fungi | however, 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 undercloud | 13:19 |
| dhellmann | yes, I also think it's wise to say we expect *a* key manager to be present | 13:20 |
| mnaser | that would mean that projects have to adopt castellan, i'm not sure who has and hasn't yet | 13:20 |
| mnaser | looks like octavia already has it | 13:21 |
| mnaser | looks like magnum is lacking it | 13:21 |
| fungi | so 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 layer | 13:21 |
| dhellmann | I don't remember that specifically (I may not have been in that session either) but I would support that position today | 13:21 |
| fungi | if nobody recalls off the top of their heads, i'll go hunt down an etherpad | 13:22 |
| mnaser | likewise (re: castellan adoption) | 13:22 |
| *** frickler has joined #openstack-tc | 13:43 | |
| *** zhipeng has joined #openstack-tc | 13:57 | |
| *** kumarmn has joined #openstack-tc | 14:02 | |
| *** annabelleB has joined #openstack-tc | 14:07 | |
| *** kumarmn has quit IRC | 14:07 | |
| *** annabelleB has quit IRC | 14:17 | |
| ttx | yeah, 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 exposes | 14:20 |
| ttx | castellan would otherwise be a good pick ("A Castellan-supported secret store" being added to base services) | 14:21 |
| cdent | airship | 14:21 |
| cdent | huh | 14:21 |
| fungi | after some hunting, i've found a breadcrumb... https://review.openstack.org/419397 | 14:21 |
| fungi | at least now i know what timeframe to check the ml for | 14:21 |
| mugsie | cdent: https://github.com/att-comdev/divingbell | 14:22 |
| cdent | So 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 |
| ttx | dhellmann: slide 8 features the OpenStack proposal bot as a contributor, is that intentional ? | 14:24 |
| ttx | cdent: well it depends on what you mean by "openstack project" | 14:25 |
| ttx | It's clearly not a great product fit for "OpenStack" | 14:25 |
| ttx | It's a deployment system for OpenStack, Kubernetes and other things | 14:25 |
| mugsie | Yeah - that is why I am confused why it is under openstack/* | 14:25 |
| ttx | Well everything is under openstack in our infrastructure, that's another problem | 14:26 |
| ttx | Which is why I wanted to flatten the git space | 14:26 |
| mugsie | I thought that was being dealt with as part of these new groups? | 14:26 |
| ttx | well zuul is still openstack-infra/zuul afaict | 14:26 |
| ttx | Also at this point it's more a stackforge-like thing | 14:27 |
| ttx | (which still leaves unde openstack/) | 14:27 |
| ttx | lives* | 14:27 |
| mugsie | yeah, seen as zuul-ci is not announced yet, i figured that might change post summit | 14:27 |
| ttx | but yes, I agree that openstack/airship sounds weird | 14:27 |
| ttx | and we'll need to fix that once we have a proper solution for our git properties | 14:28 |
| mugsie | I 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 by | 14:29 |
| mugsie | ttx: when was this kicked off? I have been to all public board meetings since SYD, and heard nothing about this | 14:30 |
| ttx | We host a lot of projects in "unofficial" space aka stackforge | 14:31 |
| ttx | i don't know much about any one of them ? | 14:31 |
| mugsie | sure, but none of them are becoming a member of the foundation | 14:32 |
| fungi | project managed by the foundation | 14:32 |
| fungi | "member" has much different connotations | 14:32 |
| mugsie | s/member/sub project of/ | 14:32 |
| mugsie | fungi: yes, I worded that badly | 14:33 |
| fungi | i get the impression they're trying to decide whether it goes in the edge or containers strategic focus area | 14:33 |
| fungi | if containers, it would be a sibling of kata | 14:33 |
| fungi | if edge, it would be the first project there | 14:33 |
| mugsie | https://review.openstack.org/568857 sets up a new ML domain, so ity looks like a new area entirely | 14:33 |
| ttx | the 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 -1 | 14:34 |
| *** kumarmn has joined #openstack-tc | 14:34 | |
| fungi | and 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 review.openstack.org to a less-openstacky domain | 14:34 |
| fungi | mugsie: not a new strategic focus area, just a new project | 14:35 |
| ttx | Personally I'm excited to see them willing to use our project infrastructure rather than just go to GitHub to collect stars | 14:35 |
| fungi | in the same way that openstack is a project or zuul is a project or kata is a project | 14:35 |
| mugsie | fungi: I thought that is what we were labeling things like kata / edge / zuul | 14:36 |
| fungi | zuul is in the ci/cd strategic focus area, kata is in the containerization strategic focus area, openstack is in the open infrastructure strategic focus area | 14:36 |
| ttx | mugsie: you should come to my talk on Monday ! | 14:36 |
| fungi | mugsie: 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 |
| jbryce | the 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 |
| fungi | ahh, yes, i said open infrastructure when i meant datacenter | 14:38 |
| ttx | fungi: you should come to my talk too ! | 14:39 |
| * fungi is still trying to get used to the new terminology | 14:39 | |
| *** kumarmn has quit IRC | 14:39 | |
| jbryce | there'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 |
| mugsie | OK. I am assuming airship will come up on Sunday anyway? | 14:41 |
| jbryce | airship is very new and at this point, the devs are focused on getting their repos set up and starting to build a community | 14:41 |
| jbryce | it's not at a big announcement stage, so this isn't like kata launch in december | 14:42 |
| jbryce | it'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 community | 14:43 |
| fungi | i 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 define | 14:44 |
| fungi | airship didn't apply to be a component of openstack, but if they did i expect we'd raise similar concerns | 14:45 |
| ttx | same concerns we had with StackKube | 14:47 |
| ttx | which was also a bad product fit | 14:47 |
| fungi | so, 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 community | 14:49 |
| ttx | that is how I see it yes | 14:50 |
| fungi | though 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 |
| ttx | I 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 here | 14:51 |
| fungi | though 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 |
| ttx | I don't know that much about it but it looks separate and complementary | 14:52 |
| ttx | I will look at it once the repos are moved :) | 14:52 |
| *** dklyle has joined #openstack-tc | 14:53 | |
| fungi | from https://review.openstack.org/568659 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-tc | 14:55 | |
| fungi | so 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/bifrost | 14:55 |
| fungi | hence, why i can understand that people might have been a little confused | 14:56 |
| ttx | indeed, we need to learn more | 14:56 |
| mugsie | or why it is not part of the helm projecty | 14:57 |
| jbryce | mugsie: helm in kubernetes or openstack-helm? | 14:57 |
| mugsie | openstack-helm | 14:58 |
| jbryce | it uses openstack-helm but it's kind of downstream from that | 14:58 |
| mugsie | is it? I just runs daemonsets on each node that does config-management | 14:59 |
| mugsie | (from what I can tell anyway) | 14:59 |
| mugsie | I could see that as a sidecar to os-helm, like os-security-hardening started as a sidecar to OSA | 15:00 |
| jbryce | it does things that are not in scope for openstack-helm and that are not related to openstack services | 15:00 |
| jbryce | like bootstrapping a kubernetes environment that may or may not run openstack services at all | 15:00 |
| jbryce | plus a bunch of declarative config management stuff that may or may not relate to openstack-helm and openstack services | 15:01 |
| jbryce | if you are wanting to use openstack-helm you can do that without other airship components | 15:01 |
| jbryce | and you can use other airship components without openstack-helm | 15:01 |
| mugsie | ah, right now, it doesn't bootstrap, and does basic cfgmgmt, so it looked more like an add-on than a thing of its own | 15:02 |
| *** hongbin has joined #openstack-tc | 15:04 | |
| jbryce | like 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 |
| fungi | in the spirit of https://www.linux.com/news/commentary-open-source-not-verb | 15:10 |
| jbryce | and the existing devs i think see the benefit to starting that earlier than later | 15:10 |
| fungi | hard to believe that article is 12 years old now | 15:10 |
| fungi | i 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 granted | 15:12 |
| *** dklyle has quit IRC | 15:12 | |
| fungi | er, thought about how much i take it for granted | 15:13 |
| dhellmann | ttx: yeah, I left the bot in because I figured we could talk about how even with automation we need help | 15:15 |
| *** zhipeng has quit IRC | 15:17 | |
| *** dklyle has joined #openstack-tc | 15:18 | |
| *** kumarmn has joined #openstack-tc | 15:24 | |
| *** dklyle has quit IRC | 15:24 | |
| *** dklyle has joined #openstack-tc | 15:26 | |
| *** dklyle has quit IRC | 15:31 | |
| ttx | makes sense | 15:31 |
| openstackgerrit | Matt Riedemann proposed openstack/project-team-guide master: Update dependency-management doc https://review.openstack.org/568883 | 15:35 |
| *** kumarmn has quit IRC | 15:40 | |
| *** kumarmn has joined #openstack-tc | 15:40 | |
| *** kumarmn has quit IRC | 15:45 | |
| *** kumarmn has joined #openstack-tc | 16:02 | |
| *** kumarmn has quit IRC | 16:02 | |
| *** kumarmn has joined #openstack-tc | 16:03 | |
| *** kumarmn has quit IRC | 16:03 | |
| *** kumarmn has joined #openstack-tc | 16:03 | |
| *** kumarmn has quit IRC | 16:04 | |
| *** kumarmn has joined #openstack-tc | 16:04 | |
| *** kumarmn has quit IRC | 16:05 | |
| *** kumarmn has joined #openstack-tc | 16:05 | |
| *** kumarmn has quit IRC | 16:07 | |
| *** kumarmn has joined #openstack-tc | 16:08 | |
| *** edmondsw has quit IRC | 16:15 | |
| fungi | eventually found the forum etherpad i was looking for... https://etherpad.openstack.org/p/BOS-forum-key-management | 16:16 |
| cdent | the fatal flaw of etherpads | 16:16 |
| fungi | unfortunately i can't quite make out if the consensus was that we should work toward adding castellan or barbican to base services | 16:17 |
| cdent | secondary flaw of etherpads :) | 16:17 |
| fungi | heh | 16:17 |
| fungi | second of many, i'll warrant | 16:18 |
| fungi | at least i can skim the dev ml from may to see if there was a followup summary posted | 16:18 |
| smcginnis | From my very poor memory, I thought things leaned towards Castellan. | 16:18 |
| *** edmondsw_ has joined #openstack-tc | 16:18 | |
| smcginnis | Kind 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 IRC | 16:23 | |
| ttx | smcginnis: yes same here | 16:25 |
| *** annabelleB has quit IRC | 16:41 | |
| mriedem | as of https://www.openstack.org/analytics barbican adoption in production is 7%, why would we say it's a base service? | 16:42 |
| mriedem | granted barbican is a castellan api implementation but are there a large number of deployments using castellan with something that's not barbican? | 16:42 |
| smcginnis | I think it's a more general need for encryption key provider services. | 16:42 |
| mriedem | it's still not run in base devstack / integrated gate | 16:43 |
| mriedem | i guess that would be part of the on-ramp toward making it a base service? | 16:43 |
| mriedem | i'm semi interested because of the trusted_certs blueprint in nova | 16:46 |
| *** annabelleB has joined #openstack-tc | 16:49 | |
| *** kumarmn has quit IRC | 16:51 | |
| *** kumarmn has joined #openstack-tc | 16:52 | |
| *** dtantsur is now known as dtantsur|afk | 16:58 | |
| *** kumarmn has quit IRC | 17:00 | |
| *** kumarmn has joined #openstack-tc | 17:03 | |
| fungi | mriedem: 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 it | 17:19 |
| fungi | and 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 on | 17:20 |
| *** diablo_rojo has quit IRC | 17:21 | |
| fungi | and 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 ago | 17:22 |
| dhellmann | tc-members: items 1 and 3 from this list resonated with me: https://www.fastcompany.com/40569522/these-are-the-reasons-why-your-whole-team-is-burning-out | 17:27 |
| smcginnis | I think you're right. I don't recall seeing any follow on activity from that session. | 17:27 |
| smcginnis | dhellmann: Looks like a good and relevant article for many right now. | 17:28 |
| cdent | aye | 17:28 |
| dhellmann | mriedem , 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 taking | 17:28 |
| dhellmann | so it's "allowed" rather than "required" | 17:30 |
| dhellmann | I think the more generic "key store" is better, although barbican seems like it could be a reasonable default for that | 17:31 |
| zaneb | dhellmann: it's effectively required for distros/installers | 17:36 |
| *** kumarmn has quit IRC | 17:39 | |
| *** kumarmn has joined #openstack-tc | 17:39 | |
| fungi | i took it to the ml. let's see if we can get renewed traction | 17:42 |
| fungi | i now realize i probably should have tagged it for [oslo] too | 17:43 |
| dhellmann | zaneb : that depends on the configurations those things support, though, right? | 17:44 |
| *** kumarmn has quit IRC | 17:44 | |
| mriedem | dhellmann: 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 servers | 17:45 |
| fungi | i'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 it | 17:45 |
| mriedem | i mean, you can do that w/o a real key manager, but you'll have a lot of fun warnings in the logs | 17:45 |
| mriedem | but encrypted volumes aren't required | 17:46 |
| mriedem | we gate on an essentially noop key manager though | 17:46 |
| fungi | this 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 barbican | 17:46 |
| fungi | and 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 openstack | 17:48 |
| *** ricolin has quit IRC | 17:50 | |
| fungi | or 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 |
| jroll | this has some words about key management at the BOS PTG, though don't think it's the same session as that etherpad http://lists.openstack.org/pipermail/openstack-dev/2017-February/113016.html | 17:51 |
| fungi | yeah, i found that thread earlier (which is what led me to find the right forum), but it predates the forum by months | 17:52 |
| dhellmann | mriedem : 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 list | 17:52 |
| dhellmann | fungi : 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 |
| fungi | dhellmann: that wasn't the criteria we used to put etcd in the base services list, was it? | 17:53 |
| notmyname | FWIW, 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 barbican | 17:53 |
| dhellmann | fungi : we said there that projects are allowed to consider it a requirement, right? | 17:53 |
| dhellmann | how else would that be interpreted? | 17:53 |
| fungi | dhellmann: 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 one | 17:54 |
| dhellmann | oh, sure, yeah | 17:54 |
| fungi | maybe two sides of the same coin | 17:54 |
| dhellmann | so I guess that's another path to entry to that list | 17:54 |
| fungi | but my (admittedly spotty) recollection is that projects were already doing dlm type things just all differently | 17:55 |
| dhellmann | I 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 them | 17:55 |
| dhellmann | yeah, that sounds about right | 17:55 |
| dhellmann | maybe we should write some of this up and clarify it on the base services list | 17:55 |
| dhellmann | does anyone want to take a stab at that? | 17:55 |
| fungi | i'll give it a shot | 17:56 |
| dhellmann | cool, thanks | 17:56 |
| fungi | what do you think... like maybe a rationale section with a paragraph or two covering our reasoning beyond the definition and process specifics? | 17:57 |
| dhellmann | let me look at what's there now... | 17:57 |
| fungi | the definition is succinct, and i wouldn't want to risk muddying it with additional prose | 17:58 |
| dhellmann | yeah, I think adding a rationale section makes sense | 17:58 |
| fungi | so keeping the rationale separate from the definition hopefully avoids that | 17:58 |
| dhellmann | ++ | 17:59 |
| *** kumarmn has joined #openstack-tc | 18:08 | |
| *** kumarmn has quit IRC | 18:13 | |
| *** diablo_rojo has joined #openstack-tc | 18:14 | |
| *** edmondsw has joined #openstack-tc | 18:57 | |
| *** mriedem1 has joined #openstack-tc | 19:09 | |
| *** mriedem has quit IRC | 19:11 | |
| *** mriedem1 is now known as mriedem | 19:15 | |
| *** dklyle has joined #openstack-tc | 19:18 | |
| *** dtroyer has quit IRC | 19:28 | |
| *** dtroyer has joined #openstack-tc | 19:28 | |
| openstackgerrit | Jeremy Stanley proposed openstack/governance master: Include a rationale for tracking base services https://review.openstack.org/568941 | 19:30 |
| *** david-lyle has joined #openstack-tc | 19:49 | |
| *** dklyle has quit IRC | 19:51 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: fix stein goals build https://review.openstack.org/568947 | 19:54 |
| *** annabelleB has quit IRC | 20:05 | |
| *** diablo_rojo has quit IRC | 20:09 | |
| *** annabelleB has joined #openstack-tc | 20:28 | |
| *** annabelleB has quit IRC | 20:36 | |
| openstackgerrit | Jeremy Stanley proposed openstack/governance master: Include a rationale for tracking base services https://review.openstack.org/568941 | 20:43 |
| *** cdent has quit IRC | 20:56 | |
| *** mriedem is now known as mriedem_afk | 21:41 | |
| *** pabelanger has quit IRC | 22:15 | |
| *** hongbin has quit IRC | 22:25 | |
| *** andreaf has quit IRC | 22:29 | |
| *** andreaf has joined #openstack-tc | 22:29 | |
| *** pabelanger has joined #openstack-tc | 22:34 | |
| *** edmondsw has quit IRC | 22:50 | |
| *** edmondsw has joined #openstack-tc | 23:11 | |
| *** pabelanger has quit IRC | 23:17 | |
| *** pabelanger has joined #openstack-tc | 23:20 | |
| *** annabelleB has joined #openstack-tc | 23:44 | |
| *** annabelleB_ has joined #openstack-tc | 23:47 | |
| *** annabelleB has quit IRC | 23:48 | |
| *** annabelleB_ is now known as annabelleB | 23:48 | |
| *** annabelleB has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!