| fungi | dhellmann: dims: smcginnis: the two islands south of us are under a mandatory tourist evacuation, residents get to stay but have some rolling blackouts and are under a water conservation order for a couple weeks until their grid is reconnected to the mainland. up where we are is unaffected (other than a little additional overflow from tourists who weren't allowed to go to their planned destinations) | 00:01 |
|---|---|---|
| fungi | for some reason my irc client wasn't displaying my nick highlights for this channel suddenly, dunno why | 00:02 |
| dims | fungi : whew glad to hear | 00:11 |
| smcginnis | fungi: Yeah, glad to hear you aren't too negatively impacted. | 00:35 |
| *** emagana has quit IRC | 00:47 | |
| *** emagana has joined #openstack-tc | 00:53 | |
| *** emagana has quit IRC | 00:58 | |
| *** sdague has quit IRC | 01:08 | |
| *** emagana has joined #openstack-tc | 03:10 | |
| *** lbragstad_ has joined #openstack-tc | 03:14 | |
| *** lbragstad has quit IRC | 03:14 | |
| *** marst has joined #openstack-tc | 03:36 | |
| *** emagana has quit IRC | 05:15 | |
| *** dtantsur|afk is now known as dtantsur | 07:01 | |
| *** emagana has joined #openstack-tc | 07:27 | |
| *** emagana has quit IRC | 07:31 | |
| *** dtantsur is now known as dtantsur|bbl | 07:47 | |
| openstackgerrit | Merged openstack/governance master: Mark Cinder complete for Pike uWSGI goal https://review.openstack.org/486053 | 08:24 |
| openstackgerrit | Merged openstack/governance master: Adds oswin-tempest-plugin for Winstackers https://review.openstack.org/486107 | 08:25 |
| ttx | TC office hour ! | 09:00 |
| ttx | If anyone's around, wanted to discuss which item should be our next top-5-help-wanted thing | 09:01 |
| ttx | Singling out Glance seems to have helped | 09:01 |
| *** cdent has joined #openstack-tc | 09:02 | |
| ttx | I was wondering about pushing Designate/Barbican, as those both need a final push before they are part of base-compute/any deploys | 09:02 |
| cdent | I’m conflicted on that. | 09:03 |
| cdent | Part me says of “of course we should both of those as without them things are not great” | 09:03 |
| cdent | Another part of me says “there’s all these people getting along just fine without them, so maybe they aren’t really needed and that’s why they don’t get enough attention" | 09:04 |
| cdent | brb | 09:04 |
| johnthetubaguy | does everyone need encryption, I guess its a total deal breaker for some, crazy overhead for others | 09:04 |
| ttx | cdent: I think Barbican is more in the 1st category, Designate might be in the second | 09:05 |
| ttx | I think we need a good story for secrets storage, basically. Should be optional (behind Castellan) so that people who don't want the extra complexity can opt for insecure storage | 09:06 |
| ttx | but we need the "good secrets storage" story to void every project to badly reinvent it locally | 09:06 |
| ttx | It's more of a tech debt reduction thing than a feature imho | 09:07 |
| ttx | Designate, arguably, is a different story | 09:07 |
| cdent | I do think that what we choose to put on the list says a lot about what we think about that old canard: what is openstack? And I personally think that by boosting both barbican and designate we are helping public interoperable clouds and that’s the mission that moves me. | 09:07 |
| ttx | Basically I want Barbican to be in the "base services" list, and it needs a push to make it to mainstream | 09:08 |
| johnthetubaguy | cdent: I like interop being the lens here | 09:08 |
| ttx | I don't think we can push it to the base services list until we declare it as strategic | 09:08 |
| ttx | (and the top-5 list is a way to do that) | 09:09 |
| johnthetubaguy | so where are the critical places we need the secret storage? | 09:09 |
| ttx | Good question, having a definitive list would certainly help | 09:10 |
| johnthetubaguy | I know encryption (especially when shared between services) is important | 09:10 |
| johnthetubaguy | signing stuff (like images) is another that keeps coming up | 09:11 |
| ttx | offering it as a service for app developers to store secrets is also a good thing | 09:12 |
| ttx | but it's secondary | 09:12 |
| ttx | I'm more concerned with Nova or Cinder reinventing it locally | 09:12 |
| ttx | just so that they can encrypt properly | 09:13 |
| johnthetubaguy | so they all use barbican today, with the option of a crazy thing that distracts, AFAIK | 09:13 |
| johnthetubaguy | I know dims was looking at that | 09:13 |
| johnthetubaguy | all can use, I should probably say | 09:14 |
| johnthetubaguy | now those features are largely untested last time I checked, mostly as few seem to use them | 09:14 |
| johnthetubaguy | or at least, you couldn't reboot a server for many releases, and no one really complained | 09:14 |
| johnthetubaguy | that is probably not the same things, just a strange data point | 09:15 |
| johnthetubaguy | ... so I am tempted by more work on thinking about OpenStack as an application platform | 09:15 |
| johnthetubaguy | I mean we are making progress there now, but it feels crazy important to build a healthy ecosystem | 09:16 |
| johnthetubaguy | its mostly another way to think about interop I guess | 09:16 |
| johnthetubaguy | building an app that runs on all certified OpenStack clouds, etc | 09:16 |
| cdent | interop tends to be where most of these conversations end up, and rightly so | 09:17 |
| * johnthetubaguy nods | 09:17 | |
| johnthetubaguy | being talking to folks building Scientific Gateways, you really want that to run on any OpenStack | 09:18 |
| ttx | Friendly reminder if you haven't done so already -- please register to the PTG if you intend to come :) | 09:19 |
| johnthetubaguy | the *aaS moving up the stack | 09:19 |
| johnthetubaguy | ttx: yeah, I just got budget agreed for that, so I need to go do all that | 09:19 |
| * cdent arrives on the saturday before | 09:19 | |
| ttx | If I read the hotel room block data correctly we might already have filled it, so if you want to stay at the event hotel you should try to get one of the last things | 09:19 |
| ttx | (not so many alternate hotels nearby) | 09:20 |
| johnthetubaguy | yeah, seems like its all gone, I should have done that friday, damm it | 09:20 |
| *** sdague has joined #openstack-tc | 09:20 | |
| ttx | You can try to book directly at the hotel. I'll see if there is any way to extend the block | 09:21 |
| cdent | with regards to making barbican and or designate base services and on the top 5 list, is being base or on the list chicken or egg? | 09:21 |
| ttx | I think it's hard to make it a base service until it's more polished | 09:23 |
| ttx | so it needs that extra bump in attention to make it to the other side of the hill | 09:23 |
| cdent | that’s what I would think too | 09:23 |
| cdent | Do we have evidence that the top 5 list has “worked” or has the boost in help in those areas been from the usual suspects altering or adding to their responsibilities? | 09:25 |
| ttx | cdent: I read the recent Glance report as a sign that it "worked"... At least being able to point people to a list really helps | 09:25 |
| ttx | But the list needs to be filled before we advertise it even more | 09:26 |
| johnthetubaguy | getting permission to change what you do was probably easier with it being on the list, but we should check | 09:26 |
| ttx | a top-5 list of 2 looks a bit funny | 09:26 |
| johnthetubaguy | heh, true | 09:27 |
| johnthetubaguy | although I like how it invites others to make suggestions | 09:27 |
| cdent | If we’ve moved on from that topic, I have some comments about tags to point at. | 09:30 |
| ttx | cdent: please do | 09:31 |
| cdent | the discussion around ironic on https://review.openstack.org/#/c/482759/ | 09:31 |
| cdent | in the comments there are several issues (some raised by me, some by others) | 09:31 |
| * ttx reads latest situation | 09:32 | |
| cdent | questions about who the real audience of tags are, and whether they “matter” | 09:32 |
| cdent | if they apply differently to project, repo, deliverable, how do we know from just looking at the tag | 09:32 |
| ttx | In the YAML format they either apply to team or to deliverable | 09:33 |
| ttx | traditionally only the team diversity tags were "team tags" | 09:33 |
| ttx | everything else applied to deliverable level | 09:34 |
| cdent | except that some repos have more than one deliverable, is one of the questions brought up on that review | 09:34 |
| ttx | The recent status:maintenance-mode tag changed that | 09:34 |
| ttx | you mean some deliverables have more than one repo | 09:34 |
| cdent | and whoever is consuming the tags (still not clear on that one) do they know about those distinctions | 09:34 |
| ttx | Basically if a deliverable contains more than one repo it is a single thing spread across multiple git repos | 09:35 |
| cdent | no, I mean, some repos have more than one deliverable. for example, openstack/nova produces the nova api and the placement api | 09:35 |
| ttx | same versioing, same rules applied across | 09:35 |
| ttx | Oh, you mean some repositories produce multiple *services* | 09:35 |
| ttx | "deliverable" is a release term | 09:35 |
| ttx | means repositories released together | 09:36 |
| ttx | I see your point | 09:36 |
| cdent | Well this is exactly my point: whoever is consuming the tags doesn’t care about service, deliverble, release, team, project, repo | 09:36 |
| cdent | none of those thigns | 09:36 |
| cdent | They care about whether they can find good stuff | 09:36 |
| cdent | tags, in their effort to be an objective demarcation of “something”, have ended up reflecting the technical boundaries that are meaningful to _us_ but are probably not all that useful to consumers | 09:37 |
| ttx | cdent: at some point they need to line up "stuff" with one of those constructs though | 09:38 |
| cdent | why? | 09:38 |
| ttx | Well, let's take practical questions they may have | 09:38 |
| cdent | (not disagreeing, just trying to get to the real point of tags) | 09:38 |
| *** marst_ has joined #openstack-tc | 09:38 | |
| ttx | They want, for example, to know if the team behind a certain "stuff" has diverse affiliation and therefore is more solid | 09:38 |
| *** marst has quit IRC | 09:38 | |
| ttx | Or they want to know if a certain "stuff" follows a determined rule for deprecation, or stable maintenance | 09:39 |
| cdent | which they are you talking about at this stage? because I’d be surprised if someone evaluating openstack is thinking very much about whether the team is diverse. | 09:39 |
| cdent | they are thinking about whether the code exists and does what it says on the tin | 09:40 |
| ttx | cdent: as the tags are reproduced on the project-navigator and concur in producing a "maturity score", yes, they care | 09:40 |
| cdent | _we_ worry about things like diversity (because it is indeed a good sign of health) | 09:40 |
| ttx | cdent: users want to know if "stuff" is mature enough for them to consider. the problem being, they all have a different definition of what "mature" means | 09:41 |
| ttx | So we provide them a number of metrics that they can match to their definition of maturity | 09:41 |
| ttx | Those are exposed on the project navigator | 09:41 |
| ttx | Defining the tags is just a way to build that information | 09:42 |
| ttx | so that it can be exposed in a way that is consumable by users | 09:42 |
| ttx | To answer your question, users don't read the tags from projects.yaml | 09:42 |
| ttx | They do, however, read the project navigator | 09:42 |
| ttx | which conveniently blurs team/project/repo/deliverable/service into a "stuff" thing | 09:43 |
| ttx | cdent: if the diveristy was only useful to us, it has nothing to do as a tag | 09:43 |
| ttx | Tags need to provide a useful data point, that answers a question users may have | 09:44 |
| ttx | If some tags are so far off that they do not provide an interesting data point for users, they should be removed | 09:44 |
| ttx | Exception being the tc-approved-release which is a thing that the bylaws define | 09:44 |
| ttx | and that we need to define one way or another | 09:44 |
| ttx | (could be something different from a tag though) | 09:45 |
| cdent | so, then, the point of tags is a way to appear authoritative about “maturity” using a calculation that we create along several dimension identified by the tags (which is fine). We could just as easily (as we used to) use subjective judgement to group projects into “mature” and “not quite mature” groupings on the navigator page. | 09:45 |
| cdent | But by using tags we hope to allow people to use some of their own judgement by being aware of which dimensions are more important to them. | 09:45 |
| ttx | cdent: yes, that's the idea | 09:45 |
| ttx | cdent: now I wouldn't paint them as a total success :) | 09:46 |
| ttx | the "stuff" mapping done at the project-navigator level is kinda fuzzy | 09:46 |
| ttx | resulting in weird corner cases (like Telemetry) | 09:46 |
| cdent | Are our analytics on the navigator page sufficient to know that people explore and dig, or do they just look and see that nova is big, healthy and old and that’s that. | 09:46 |
| ttx | cdent: not sure | 09:47 |
| ttx | BUT we have been having that discussion lately: | 09:47 |
| cdent | because it _seems_ that the reason people choose certain project is because other people have alread chosen it | 09:47 |
| cdent | which is normal and fine, but suggests that tags are overhead | 09:48 |
| ttx | tags/project-navigator is a bit of a reactive thing. You describe things as they are, not as you want them to be | 09:48 |
| ttx | We might want to paint a more aggressive picture of how things should be, even if we are a bit off | 09:48 |
| cdent | I agree that we should be painting future pictures much more. | 09:49 |
| ttx | i.e. expose the set of projects that make up the core/interop/whatever, put things in a "next" bucket when they are not quite there yet | 09:49 |
| ttx | put things in a "ops-tools" bucket or a "deployment-tools" bucket | 09:49 |
| ttx | (that's the work being done/explored with mapping | 09:49 |
| ttx | Trying to segment things based on the role they have in the system | 09:50 |
| cdent | unconstrained growth is cancer? | 09:50 |
| ttx | But also potentially based on how mature they are | 09:50 |
| cdent | So, given everything we just said, it seems like we need to make sure that when evaluating applying tags to things we need to be more clear about what they are being applied to | 09:57 |
| ttx | I'll plead guilty that the tags system was an engineer solution to an essentially-marketing problem | 09:57 |
| cdent | and when evaluating the creation of tags we need to think primarily in terms of their usefulness on the navigator | 09:57 |
| ttx | That said, the marketing folks were asking us to produce data that they could remix, so that's what we gave them | 09:57 |
| cdent | I tend to think that when people are looking at the navigator they are looking at projects | 09:57 |
| cdent | so tags that apply to something other than projects may be moot | 09:58 |
| ttx | yes, that's a good point | 09:58 |
| ttx | ties back into the need to create buckets | 09:58 |
| ttx | python-novaclient has nothing in common with nova-the-service | 09:58 |
| ttx | except they are both produced by the same team | 09:58 |
| ttx | exposing them on the same level anywhere just adds confusion | 09:59 |
| * cdent nods | 09:59 | |
| ttx | If they were called services/nova and clients/nova that would be much clearer | 09:59 |
| ttx | or even core-iaas/nova and pythonclients/nova | 09:59 |
| ttx | anyway, hopefully we should have a plan to present by Denver | 10:00 |
| ttx | still very much in brainstorming phase | 10:00 |
| ttx | so thanks for sharing your concerns | 10:00 |
| cdent | I think they can be useful as long as we keep them relatively simple and easy to judge. | 10:01 |
| cdent | Once we start having to ask questions about what they mean, then boom | 10:01 |
| cdent | (I’m still confused about maintenance-mode, for example) | 10:01 |
| ttx | The whole diversity tagging could be replaced by a regular repoort | 10:01 |
| ttx | which would allow for much more detailed analysis and information | 10:02 |
| ttx | As engineers, we like the idea of a magic formula, but in reality we need to apply some analysis on top | 10:02 |
| * cdent is not an engineer | 10:03 | |
| cdent | I’ve always bristled at the concept of “software engineer” | 10:03 |
| ttx | like, diversity doesn't matter if your project just has a couple commits per cycle | 10:03 |
| * cdent nods | 10:03 | |
| ttx | People want to know health and resiliency of the contributor base, not exactly how manu organizations it takes to do 80% of core reviews | 10:04 |
| ttx | They want to know "can I bet the future of my organization on this project" | 10:05 |
| ttx | It feels like they might read a regularly-produced contribution report more than a set of tags | 10:05 |
| * cdent continues to wonder who “they” are | 10:11 | |
| *** dtantsur|bbl is now known as dtantsur | 10:11 | |
| *** mugsie has quit IRC | 10:22 | |
| *** mugsie has joined #openstack-tc | 10:25 | |
| *** mugsie has quit IRC | 10:25 | |
| *** mugsie has joined #openstack-tc | 10:25 | |
| *** mugsie has quit IRC | 10:31 | |
| *** mugsie has joined #openstack-tc | 10:33 | |
| *** mugsie has quit IRC | 10:33 | |
| *** mugsie has joined #openstack-tc | 10:33 | |
| openstackgerrit | Sean Handley proposed openstack/governance master: Add public cloud WG. https://review.openstack.org/489555 | 10:41 |
| openstackgerrit | Sean Handley proposed openstack/governance master: Add public cloud WG. https://review.openstack.org/489555 | 10:49 |
| openstackgerrit | Alexander Chadin proposed openstack/governance master: Add watcher-tempest-plugin to watcher project https://review.openstack.org/489557 | 10:52 |
| sdague | ttx: that's fine, the diversity tags are a short cut that can be computed, and not one where people (mostly) are going to fight over how their project is described in them | 11:22 |
| sdague | ttx: if you have a brave soul that's signed up to publish project health reports for 50 official projects every couple of months, and deal with the backlash, a different model is welcomed | 11:23 |
| ttx | rack | 11:30 |
| ttx | ack* | 11:30 |
| openstackgerrit | Sean Handley proposed openstack/governance master: Add public cloud WG. https://review.openstack.org/489555 | 11:37 |
| *** cdent has quit IRC | 12:32 | |
| dims | ttx : johnthetubaguy : about the barbican as base. i think we should say castellan should be used (not barbican directly) and we should have an alternative driver in castellan as an escape valve. | 13:23 |
| mugsie | should we not add easier to run production backends to barbican? | 13:24 |
| mugsie | barbican itself is not too bad from what I remember, the complexity was in the backends, especially the ones you should run in production | 13:26 |
| dims | mugsie : leaning towards, not running one more thing and a minimum api that can be better guaranteed to work | 13:26 |
| mugsie | I get that. barbican has features that castellan doesn't though, doesn't it? like SSL CA and ability to sign things without the key ever leaving barbican? | 13:29 |
| dims | mugsie : right, are those needed by majority of use cases is the question. | 13:31 |
| mugsie | I would be afraid of people trying to re-implement them if barbican is not there, or worse having an `if barbican .. else ` block | 13:32 |
| *** cdent has joined #openstack-tc | 13:32 | |
| mugsie | for example DNSSEC and designate will require barbican, as I do not want us to implment crypto signing code in designate. But, I can't think of many more use cases of the top of my head | 13:34 |
| dims | mugsie : then designate should do barbican directly, and evangelize to operators why that's the best choice. no? | 13:35 |
| mugsie | yeah - but if it is not a base service we can't rely on it | 13:35 |
| mugsie | it is the chicken and egg problem | 13:35 |
| cdent | rely on it and they will come? | 13:36 |
| mugsie | or people will just disable DNSSEC :) | 13:36 |
| dims | cdent : not sure if we should lean towards easier ops take by providing options (or) towards the dev concern mugsie pointed out | 13:37 |
| cdent | dims: I think the “omg too many services” concern is a red herring | 13:37 |
| *** hongbin has joined #openstack-tc | 13:38 | |
| cdent | once you automate 5 things, 10 things is not actually 5 more | 13:38 |
| mugsie | for me, that fact it is crypto, makes it different. We should really want a single, auditable, and securely designed place for our crypto and secret storage | 13:38 |
| dims | mugsie : yes, and most enterprise will have one or more already | 13:39 |
| mugsie | at which point, barbican can use the HSMs that are pre deployed | 13:40 |
| mugsie | having it inside a single service makes complicance, and segragation easier from an ops side | 13:40 |
| dims | mugsie : is there any other alternative to make everyone switch on barbican? | 13:42 |
| mugsie | dims: probably, but I would need to take a little time to look at the use cases, and what we have. Maybe expanding castellan? but that might cause castellan to become a rewrite of barbican, loaded into each project | 13:44 |
| dims | agree | 13:44 |
| cdent | we insist on keystone being a, uh, keystone, and require that people shim to their enterprise infrastructure | 13:45 |
| cdent | why can’t barbican be the same? | 13:45 |
| mugsie | for secret storage you will need to have a difference service anyway, won't you? I thought the non barbican driver was going to be vault? | 13:45 |
| cdent | and we require barbican | 13:45 |
| mugsie | cdent: yeah, thats true | 13:45 |
| dims | cdent : we are not in a position to twist arms anymore | 13:45 |
| cdent | I find it hard to believe that we _actually_ ever were. People just kind of went with it. | 13:47 |
| cdent | I think rather than trying to predict outcomes, we should create a solution and see if it works. | 13:48 |
| cdent | Respond to feedback rather than predicting feedback. | 13:48 |
| dims | cdent : i am proposing one... "projects should use castellan and be sure it works. projects that need more can use barbican directly" | 13:49 |
| * cdent is still not entirely clear where the castellan/barbican boundary is | 13:49 | |
| dims | castellan is a oslo-like library | 13:49 |
| *** emagana has joined #openstack-tc | 13:50 | |
| cdent | dims: which interfaces to a variety of keystores, including barbican? | 13:54 |
| dims | yes, barbican is done. kmip/vault in progress | 13:55 |
| cdent | dims: if that’s the case, what are the arguments in favor of requiring barbican (instead of using castellan)? | 13:58 |
| dims | "[09:33:48] <mugsie>I would be afraid of people trying to re-implement them if barbican is not there, or worse having an `if barbican .. else ` block" | 14:02 |
| cdent | but isn’t the point of castellan to mask that? | 14:03 |
| dims | cdent : castellan is a subset of the functionality | 14:04 |
| mugsie | Castellan only provides secret storage and retrival | 14:04 |
| *** lbragstad_ is now known as lbragstad | 14:04 | |
| dims | cdent : if someone needed full barbican functionality, they can use barbicanclient | 14:04 |
| cdent | Is secret storage and retrieval the key need? | 14:05 |
| dims | cdent : that was the belief for starting the castellan library | 14:05 |
| cdent | but now? | 14:06 |
| dims | cdent : see the nova+cinder encryption scenario | 14:06 |
| dims | castellan is enough. no need for full barbican functionality | 14:06 |
| cdent | and where is it not enough? | 14:07 |
| dims | cdent : mugsie's scenario with DNSSEC | 14:07 |
| cdent | I’m sorry if I sound like I’m being obtuse or obstreperous, just trying to get things clear so there aren’t some hidden assumptions | 14:08 |
| cdent | I’d like to figure out some way to move something forward | 14:08 |
| cdent | we often seem like we’re going in circles | 14:08 |
| dims | cdent : not at all. happy to share what i know | 14:09 |
| cdent | so next question: are there roadblocks in the way of using castellan for the cinder scenario? | 14:10 |
| smcginnis | Cinder switched to using Castellan in Ocata, though I'm actually not 100% on it's full use. | 14:11 |
| cdent | mugsie: what do you think would happen if you just declared: from pike on, designate requires barbican ? | 14:14 |
| * dtroyer catches up | 14:15 | |
| dtroyer | re: chicken-and-egg… it looks like we've already climbed the first two bits of that by Nova and Cinder using (some amount of) Castellan. Designate being the first one to require all of Barbican does not feel like a huge stretch to me when two of the other services likely present will also leverage Barbican when it is present. | 14:18 |
| dtroyer | Also, DNSSEC is opaque enough to many that another service to support a solid implementation should be a small price to pay | 14:19 |
| sdague | do we know what is required to make castellan enough | 14:19 |
| dtroyer | For DNSSEC? I think it would be for it to proxy all of Barbican | 14:20 |
| dtroyer | maybe not all, but the signing APIs | 14:20 |
| sdague | I was involved in some of this on the Nova side, and the pre castellan world was a big set of 4 way if conditions in Nova about secret backends | 14:20 |
| sdague | ok, so lets be specific, what set of APIs are needed to get added. | 14:21 |
| dtroyer | I saw mugsie mention signing above. I don't think DNSSEC uses the CA bits | 14:23 |
| *** marst_ has quit IRC | 14:28 | |
| mugsie | sorry, I went for a coffee, an missed all this :) | 14:34 |
| *** marst has joined #openstack-tc | 14:35 | |
| mugsie | so, for designate, we will use (as yet un written, but we have discussed it in principal with barbican) signing api | 14:35 |
| mugsie | which, we will use by hashing the info, then sending the hash to barbican, they take a private key in the store, sign the hash with the key, and send it back | 14:36 |
| mugsie | so, it will be a signing using a private key in barbican API | 14:36 |
| mugsie | and users will put a key in barbican, and gran us access, (i imagine much like they do in octavia right now) | 14:37 |
| dtroyer | I think sdague's question is whether the signing APIs should also be routed through Castellan like the secrets are now | 14:37 |
| mugsie | well, I am not sure that we would be able to find something else to back castellan that would support it, would we? | 14:39 |
| dtroyer | if I understand ttx's response to that earlier the answer is 'just use Barbican directly' in this case | 14:39 |
| mugsie | yes | 14:39 |
| dtroyer | will Barbican implement the signing directly or use a back-end for that part? | 14:39 |
| mugsie | cdent: I don't think we would require barbican for all uage of designate - just if you have DNSSEC turned on. | 14:39 |
| cdent | from a packagers standpoint that means designate requires barbican | 14:40 |
| cdent | ? | 14:40 |
| mugsie | I do think if it is not a base service, a different, also not base service that required it, would just not be installed | 14:40 |
| dims | dtroyer : that functionality is already in barbicanclient... why duplicate? | 14:40 |
| mugsie | cdent: it could be a recommends, instead of a requries for a packager | 14:40 |
| dtroyer | dims: in the client directly? so it isn't a REST API, but a python lib? | 14:40 |
| cdent | mugsie: what I mean is that the packager would have to package barbican if they package designate | 14:41 |
| mugsie | cdent: oh, humm. yes - probably | 14:41 |
| dims | dtroyer : i meant, there's no point making everything available through barbicanclient (making REST calls to barbican), from castellan | 14:41 |
| mugsie | dtroyer: from our discussions in the past, it looked like it was in barbican, but i can't speak for that team | 14:41 |
| sdague | dims: where I get concerned is that if we piecemealing together security features through multiple libs, things get wonky | 14:41 |
| dims | right sdague | 14:42 |
| sdague | so... you know what would be great. A summary of the current state of the world in a doc, and where all the gaps are. | 14:42 |
| openstackgerrit | Merged openstack/project-team-guide master: Update feature branch creation details https://review.openstack.org/489293 | 14:42 |
| sdague | because we're picking appart things based on really partial information | 14:43 |
| dtroyer | I may have misunderstood then, dims you are just talking about what the app calls (barbicanclient vs castellan) and not where the signing code lives. gotcha | 14:43 |
| dims | yep sdague | 14:43 |
| mugsie | sdague: yeap | 14:43 |
| sdague | this is actually why most projects have a specs process, is to force harder problems through that exercise of "this is the problem, these are the gaps, here are some solutions" | 14:43 |
| sdague | I don't care where the artifact is, but this problem going through that kind of process would be good | 14:44 |
| dhellmann | ++ | 14:44 |
| dims | sdague : i am barely/newly involved in this discussion, so no clue how robust barbican is in the field. so just trying to figure out that stuff | 14:45 |
| sdague | dims: sure, and the point is, we all have various fuzzy bits of information. Someone needs to dive through this and summarize, because I don't think enough info exists to make a good / right decision right now | 14:46 |
| dims | sdague : dtroyer : i have heard many folks have their own implementations (including huawei) | 14:46 |
| sdague | dims: that would be great to capture, and to capture why | 14:46 |
| dims | yep | 14:46 |
| dims | agree that we don't know enough to make a good decision sdague | 14:47 |
| *** cdent has quit IRC | 15:21 | |
| * ttx reads scrollback | 15:29 | |
| dims | smcginnis : w00t on the release ptl candidacy | 15:39 |
| smcginnis | dims: ;) | 15:39 |
| ttx | mugsie: haven't looked into it, but at first glance I feel like the signing API should be exposed in Castellan, and Designate's DNSSEC feature would depend on Castellan+a backend that implements the signing feature | 15:43 |
| dims | ttx : why overload castellan? why not let designate use barbican directly? | 15:44 |
| mugsie | ttx: exposing it in castellan means that the key has to be loaded in designate's memory, right? | 15:44 |
| mugsie | which is not some thing I am keen to introduce | 15:44 |
| ttx | mugsie: not necessarily, in case of Barbican that could be a pass-through to Barbican's signing | 15:45 |
| * dims still curious | 15:45 | |
| mugsie | unless we write a custom backend for castellan, at which point, we should just use barbican | 15:45 |
| dims | right mugsie | 15:45 |
| dims | just to understand what exists, i am writing a castellan driver for vault - https://review.openstack.org/#/c/483080/ | 15:46 |
| ttx | dims: I'm concerned about the added dependency hampering adoption of Designate | 15:46 |
| mugsie | but -keep in mind, this for an optional feature, and we would not need it unless you wanted DNSSEC | 15:46 |
| mugsie | which 99% of people will not need / or want | 15:46 |
| ttx | Basically if we say that "a castellan-compatible secrets store" is in base services, and Designate depends on Barbican itself, that creates a shift | 15:46 |
| dims | mugsie : so folks who need that can barbican directly | 15:46 |
| dims | ttx : a small segment of designate users | 15:47 |
| ttx | Imagine the case of a Nova/Cinder/Neutron deployment that opts to use Castellan+Vault | 15:47 |
| dims | yes | 15:47 |
| ttx | Basically they will never use Designate since that would mean ditching Vault for barbican | 15:47 |
| ttx | whereas if castellan exposed the signing API... | 15:48 |
| mugsie | I would be worried about even the hint of needing a non base service would hurt us right now | 15:48 |
| mugsie | ttx: if we could find a way of having the signing api be secure, without us writing code to do it, that would be great | 15:49 |
| dims | ttx : is there any other use case other than the DNSSEC/designate? | 15:49 |
| mugsie | but the likes of vault will not have a signing api :/ | 15:49 |
| mugsie | dims: doesn't octavia use it for SSL ? | 15:49 |
| ttx | Basically saying that you can count on "a castellan-compatible secrets storage" being present and then having a hard depend on Barbican oin one of the project is just not consistent | 15:49 |
| ttx | Imagine that a project had a hard-depend on Postgresql | 15:50 |
| ttx | or ZeroMQ | 15:50 |
| ttx | So if Barbican exposes functionality that can't be replicated easily with other backends, maybe we should make Barbican a base service | 15:51 |
| dims | mugsie : seen this? https://www.vaultproject.io/api/secret/pki/index.html | 15:51 |
| ttx | rather than "a castellan-compatible secrets storage backend" | 15:51 |
| mugsie | dims: I have not | 15:51 |
| mugsie | will have a dig through it | 15:51 |
| ttx | Now if Vault can do the same signing stuff, then maybe that should be exposed in Castellan itself | 15:51 |
| ttx | we just can't have it both ways | 15:52 |
| mugsie | its just SSL :/ | 15:52 |
| mugsie | but that could work for octavia | 15:53 |
| mugsie | but I would not like to speak on their behalf | 15:53 |
| johnsom | mugsie What are you signing us up for? grin | 15:53 |
| mugsie | :D | 15:53 |
| *** cdent has joined #openstack-tc | 15:53 | |
| ttx | we should be having that discussion on -dev since it's not really a TC thing and could use wider input | 15:54 |
| * dims blames cdent and johnthetubaguy :) | 15:54 | |
| dims | mugsie : would be great if you can help define what additional API is needed in castellan for designate | 15:55 |
| ttx | yes, that's definitely new data that wasn't taken into account when that was discussed in ATL | 15:55 |
| cdent | dims: I accept that blame and raise you “you started it" | 15:56 |
| dims | LOL | 15:56 |
| * ttx checks | 15:57 | |
| ttx | err, I probably need to fold since you raised | 15:57 |
| *** emagana has quit IRC | 15:58 | |
| cdent | TC Poker Night | 15:59 |
| cdent | now with buzzword bingo | 15:59 |
| *** emagana has joined #openstack-tc | 15:59 | |
| sdague | I honestly think the rest of the conversation is mostly circular until there is something like a spec | 15:59 |
| cdent | it’s certainly unclear to me what the real goals and use cases are | 16:00 |
| cdent | so a spec like thing would help that | 16:00 |
| *** emagana has quit IRC | 16:03 | |
| *** emagana has joined #openstack-tc | 16:06 | |
| *** emagana has quit IRC | 16:59 | |
| EmilienM | what happens if a project doesn't have PTL again? | 17:05 |
| EmilienM | I always forgot | 17:05 |
| cdent | we make EmilienM do it | 17:07 |
| EmilienM | NO ! | 17:07 |
| cdent | you mean if no one volunteers? | 17:08 |
| EmilienM | cdent: yes | 17:13 |
| EmilienM | cdent: I'm not sure we'll have someone for Puppet OpenStack | 17:13 |
| EmilienM | cdent: also, I'm not sure we *need* someone for this project | 17:13 |
| EmilienM | but that's a personal opinion | 17:13 |
| *** dtantsur is now known as dtantsur|afk | 17:13 | |
| ttx | If no candidate, the TC finds and appoints someone | 17:13 |
| ttx | or drops the team altogether :) | 17:13 |
| cdent | so, like I said, we make EmilienM do it ;) | 17:14 |
| * ttx digs up resolution | 17:14 | |
| ttx | https://governance.openstack.org/tc/resolutions/20141128-elections-process-for-leaderless-programs.html | 17:14 |
| ttx | complete with old "program" language -- new linguo is "project team" | 17:15 |
| ttx | but you get the gist | 17:15 |
| cdent | EmilienM: fwiw, I agree with you: I’m not sure all projects need a PTL, but on the other hand if a project doesn’t need a PTL, being the proxy PTL is probably not too onerous | 17:15 |
| ttx | right, you still need a contact point | 17:15 |
| ttx | to answer for "the team" | 17:16 |
| ttx | when organizing things cross-project you can't deal with every team being organized differently | 17:16 |
| *** mwhahaha has joined #openstack-tc | 17:16 | |
| EmilienM | let me invite alex | 17:16 |
| mwhahaha | hey | 17:16 |
| EmilienM | mwhahaha is Alex Schultz (in case people wonder), the PTL of Puppet OpenStack | 17:17 |
| ttx | "the PTL" is about the only thing all teams have in common | 17:17 |
| ttx | so when organizing things like release management, or events like Forum/PTG it's precious | 17:17 |
| EmilienM | it's safe to say Alex and I are the main mainteners / reviewers of Puppet OpenStack - we have other reviewers, but we're basically taking care of releases/CI | 17:17 |
| ttx | If we had to remember which teams have 0 PTL and which teams have 3, that would be a mess | 17:18 |
| EmilienM | ttx: I agree | 17:18 |
| EmilienM | so iiuc, if we want to keep Puppet OpenStack team under governance, we need a PTL | 17:19 |
| ttx | yes | 17:19 |
| EmilienM | AFIK we won't have sessions at PTG | 17:19 |
| ttx | call that a "contact point" if that helps :) | 17:19 |
| EmilienM | we stopped (today) doing weekly meetings | 17:19 |
| EmilienM | because we have nothing to say | 17:19 |
| mwhahaha | we haven't really had anything at the summit/ptg lately so the openstack ptl just does releases at this point | 17:19 |
| ttx | EmilienM: maybe it should be marked maintenance-mode | 17:19 |
| mwhahaha | since we're not adding features but just enabling end users to be able to configure the existing upstream stuff | 17:20 |
| EmilienM | maybe | 17:20 |
| ttx | mwhahaha: isn't there some effort keeping up with new projects being added ? | 17:20 |
| EmilienM | yup | 17:20 |
| mwhahaha | reviewing | 17:20 |
| ttx | the fact that you don't need much coordination or meetings doesn't mean you should disappear | 17:21 |
| EmilienM | we support most of OpenStack projects | 17:21 |
| mwhahaha | since we basicaly already have everything stubbed out it's minor | 17:21 |
| mwhahaha | we aren't disappearing necessarily but operators are 3+ releases behind | 17:21 |
| mwhahaha | so folks don't need new stuff until much later | 17:21 |
| mwhahaha | it's always been a problem where we're ahead of our actual consumers and it's only getting more noticable now | 17:21 |
| ttx | I'd say the role of the Puppet PTL is probably limited to release management, and answer "no" when asked whether the team wants a room at PTG | 17:22 |
| ttx | and that's fine | 17:22 |
| mwhahaha | yea that's probably it | 17:22 |
| ttx | shouldn't be too hard to convince someone to cover that | 17:23 |
| * ttx needs to run | 17:23 | |
| ttx | aka eat | 17:23 |
| EmilienM | mwhahaha wrote a tool to release Puppet OpenStack modules in 1 click | 17:23 |
| mwhahaha | i'll probably just do it next cycle and we'll work on figuring out what to do for R | 17:24 |
| cdent | Who are the big/main consumers of puppet openstack these days? | 17:24 |
| EmilienM | we said that last cycle ^ | 17:24 |
| EmilienM | cdent: more than we think | 17:24 |
| cdent | I’m sure | 17:24 |
| EmilienM | cdent: tripleo as an "official" consummer | 17:24 |
| EmilienM | but a lot of deployments use it | 17:24 |
| EmilienM | CERN included | 17:24 |
| cdent | Is tripleo going to move all the way to ansible eventually? | 17:24 |
| mwhahaha | but like i said most are so many releases behind they don't know what's happeniung :/ | 17:25 |
| EmilienM | yes we are working on it | 17:25 |
| EmilienM | but I can't tell if it happens tomorrow or next year | 17:25 |
| EmilienM | we're prototyping stuffs right now | 17:25 |
| cdent | maybe someone from CERN wants to be the PTL? | 17:28 |
| EmilienM | cdent: they don't contribute to our modules | 17:28 |
| cdent | maybe they should ;) | 17:28 |
| EmilienM | if we need to put a name on puppet PTL it has to be me or alex, imho | 17:28 |
| EmilienM | because nobody else steps up to release or fix ci | 17:29 |
| EmilienM | or even step up at all | 17:29 |
| * cdent is well aware of EmilienM’s fixing ci heroics | 17:29 | |
| * cdent gives EmilienM a big cookie | 17:29 | |
| EmilienM | :) | 17:29 |
| EmilienM | it's a team work | 17:29 |
| EmilienM | mwhahaha: do you mind if I send an email about the situation? | 17:30 |
| mwhahaha | sure | 17:30 |
| EmilienM | mwhahaha: and you to reply to the thread if I missed something | 17:30 |
| EmilienM | mwhahaha: ok thx, just want to run that in public again | 17:30 |
| *** emagana has joined #openstack-tc | 17:37 | |
| smcginnis | The term "Puppet PTL" kind of makes me laugh. :) | 17:39 |
| EmilienM | sounds like we have a volunteer | 17:44 |
| EmilienM | thanks so much smcginnis | 17:44 |
| EmilienM | DONE | 17:44 |
| smcginnis | Hah! | 17:44 |
| *** EmilienM is now known as emacchi | 18:14 | |
| *** emacchi is now known as EmilienM | 18:14 | |
| *** emagana has quit IRC | 19:30 | |
| *** emagana has joined #openstack-tc | 19:33 | |
| sdague | I'm assuming no meeting this week ... | 19:37 |
| cdent | sdague: yeah: | 19:40 |
| cdent | http://lists.openstack.org/pipermail/openstack-dev/2017-July/120280.html | 19:40 |
| openstackgerrit | Sean McGinnis proposed openstack/project-team-guide master: Document process for lib release during freeze https://review.openstack.org/489723 | 19:41 |
| openstackgerrit | Sean McGinnis proposed openstack/project-team-guide master: Document process for lib release during freeze https://review.openstack.org/489723 | 19:45 |
| openstackgerrit | Sean McGinnis proposed openstack/project-team-guide master: Document process for lib release during freeze https://review.openstack.org/489723 | 19:55 |
| *** emagana has quit IRC | 20:10 | |
| *** emagana has joined #openstack-tc | 20:11 | |
| *** emagana has quit IRC | 20:16 | |
| *** emagana has joined #openstack-tc | 20:21 | |
| *** emagana has quit IRC | 20:39 | |
| *** emagana has joined #openstack-tc | 20:40 | |
| *** marst has quit IRC | 21:09 | |
| *** emagana has quit IRC | 21:34 | |
| *** emagana has joined #openstack-tc | 21:36 | |
| *** emagana has quit IRC | 22:14 | |
| *** emagana has joined #openstack-tc | 22:16 | |
| *** emagana has quit IRC | 22:17 | |
| *** emagana has joined #openstack-tc | 22:17 | |
| *** emagana has quit IRC | 22:17 | |
| *** emagana has joined #openstack-tc | 22:18 | |
| *** sdague has quit IRC | 22:35 | |
| *** hongbin has quit IRC | 23:30 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!