Tuesday, 2017-08-01

fungidhellmann: 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
fungifor some reason my irc client wasn't displaying my nick highlights for this channel suddenly, dunno why00:02
dimsfungi : whew glad to hear00:11
smcginnisfungi: Yeah, glad to hear you aren't too negatively impacted.00:35
*** emagana has quit IRC00:47
*** emagana has joined #openstack-tc00:53
*** emagana has quit IRC00:58
*** sdague has quit IRC01:08
*** emagana has joined #openstack-tc03:10
*** lbragstad_ has joined #openstack-tc03:14
*** lbragstad has quit IRC03:14
*** marst has joined #openstack-tc03:36
*** emagana has quit IRC05:15
*** dtantsur|afk is now known as dtantsur07:01
*** emagana has joined #openstack-tc07:27
*** emagana has quit IRC07:31
*** dtantsur is now known as dtantsur|bbl07:47
openstackgerritMerged openstack/governance master: Mark Cinder complete for Pike uWSGI goal  https://review.openstack.org/48605308:24
openstackgerritMerged openstack/governance master: Adds oswin-tempest-plugin for Winstackers  https://review.openstack.org/48610708:25
ttxTC office hour !09:00
ttxIf anyone's around, wanted to discuss which item should be our next top-5-help-wanted thing09:01
ttxSingling out Glance seems to have helped09:01
*** cdent has joined #openstack-tc09:02
ttxI was wondering about pushing Designate/Barbican, as those both need a final push before they are part of base-compute/any deploys09:02
cdentI’m conflicted on that.09:03
cdentPart me says of “of course we should both of those as without them things are not great”09:03
cdentAnother 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
johnthetubaguydoes everyone need encryption, I guess its a total deal breaker for some, crazy overhead for others09:04
ttxcdent: I think Barbican is more in the 1st category, Designate might be in the second09:05
ttxI 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 storage09:06
ttxbut we need the "good secrets storage" story to void every project to badly reinvent it locally09:06
ttxIt's more of a tech debt reduction thing than a feature imho09:07
ttxDesignate, arguably, is a different story09:07
cdentI 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
ttxBasically I want Barbican to be in the "base services" list, and it needs a push to make it to mainstream09:08
johnthetubaguycdent: I like interop being the lens here09:08
ttxI don't think we can push it to the base services list until we declare it as strategic09:08
ttx(and the top-5 list is a way to do that)09:09
johnthetubaguyso where are the critical places we need the secret storage?09:09
ttxGood question, having a definitive list would certainly help09:10
johnthetubaguyI know encryption (especially when shared between services) is important09:10
johnthetubaguysigning stuff (like images) is another that keeps coming up09:11
ttxoffering it as a service for app developers to store secrets is also a good thing09:12
ttxbut it's secondary09:12
ttxI'm more concerned with Nova or Cinder reinventing it locally09:12
ttxjust so that they can encrypt properly09:13
johnthetubaguyso they all use barbican today, with the option of a crazy thing that distracts, AFAIK09:13
johnthetubaguyI know dims was looking at that09:13
johnthetubaguyall can use, I should probably say09:14
johnthetubaguynow those features are largely untested last time I checked, mostly as few seem to use them09:14
johnthetubaguyor at least, you couldn't reboot a server for many releases, and no one really complained09:14
johnthetubaguythat is probably not the same things, just a strange data point09:15
johnthetubaguy... so I am tempted by more work on thinking about OpenStack as an application platform09:15
johnthetubaguyI mean we are making progress there now, but it feels crazy important to build a healthy ecosystem09:16
johnthetubaguyits mostly another way to think about interop I guess09:16
johnthetubaguybuilding an app that runs on all certified OpenStack clouds, etc09:16
cdentinterop tends to be where most of these conversations end up, and rightly so09:17
* johnthetubaguy nods09:17
johnthetubaguybeing talking to folks building Scientific Gateways, you really want that to run on any OpenStack09:18
ttxFriendly reminder if you haven't done so already -- please register to the PTG if you intend to come :)09:19
johnthetubaguythe *aaS moving up the stack09:19
johnthetubaguyttx: yeah, I just got budget agreed for that, so I need to go do all that09:19
* cdent arrives on the saturday before09:19
ttxIf 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 things09:19
ttx(not so many alternate hotels nearby)09:20
johnthetubaguyyeah, seems like its all gone, I should have done that friday, damm it09:20
*** sdague has joined #openstack-tc09:20
ttxYou can try to book directly at the hotel. I'll see if there is any way to extend the block09:21
cdentwith 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
ttxI think it's hard to make it a base service until it's more polished09:23
ttxso it needs that extra bump in attention to make it to the other side of the hill09:23
cdentthat’s what I would think too09:23
cdentDo 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
ttxcdent: I read the recent Glance report as a sign that it "worked"... At least being able to point people to a list really helps09:25
ttxBut the list needs to be filled before we advertise it even more09:26
johnthetubaguygetting permission to change what you do was probably easier with it being on the list, but we should check09:26
ttxa top-5 list of 2 looks a bit funny09:26
johnthetubaguyheh, true09:27
johnthetubaguyalthough I like how it invites others to make suggestions09:27
cdentIf we’ve moved on from that topic, I have some comments about tags to point at.09:30
ttxcdent: please do09:31
cdentthe discussion around ironic on https://review.openstack.org/#/c/482759/09:31
cdentin the comments there are several issues (some raised by me, some by others)09:31
* ttx reads latest situation09:32
cdentquestions about who the real audience of tags are, and whether they “matter”09:32
cdentif they apply differently to project, repo, deliverable, how do we know from just looking at the tag09:32
ttxIn the YAML format they either apply to team or to deliverable09:33
ttxtraditionally only the team diversity tags were "team tags"09:33
ttxeverything else applied to deliverable level09:34
cdentexcept that some repos have more than one deliverable, is one of the questions brought up on that review09:34
ttxThe  recent status:maintenance-mode tag changed that09:34
ttxyou mean some deliverables have more than one repo09:34
cdentand whoever is consuming the tags (still not clear on that one) do they know about those distinctions09:34
ttxBasically if a deliverable contains more than one repo it is a single thing spread across multiple git repos09:35
cdentno, I mean, some repos have more than one deliverable. for example, openstack/nova produces the nova api and the placement api09:35
ttxsame versioing, same rules applied across09:35
ttxOh, you mean some repositories produce multiple *services*09:35
ttx"deliverable" is a release term09:35
ttxmeans repositories released together09:36
ttxI see your point09:36
cdentWell this is exactly my point: whoever is consuming the tags doesn’t care about service, deliverble, release, team, project, repo09:36
cdentnone of those thigns09:36
cdentThey care about whether they can find good stuff09:36
cdenttags, 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 consumers09:37
ttxcdent: at some point they need to line up "stuff" with one of those constructs though09:38
ttxWell, let's take practical questions they may have09:38
cdent(not disagreeing, just trying to get to the real point of tags)09:38
*** marst_ has joined #openstack-tc09:38
ttxThey want, for example, to know if the team behind a certain "stuff" has diverse affiliation and therefore is more solid09:38
*** marst has quit IRC09:38
ttxOr they want to know if a certain "stuff" follows a determined rule for deprecation, or stable maintenance09:39
cdentwhich 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
cdentthey are thinking about whether the code exists and does what it says on the tin09:40
ttxcdent: as the tags are reproduced on the project-navigator and concur in producing a "maturity score", yes, they care09:40
cdent_we_ worry about things like diversity (because it is indeed a good sign of health)09:40
ttxcdent: 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" means09:41
ttxSo we provide them a number of metrics that they can match to their definition of maturity09:41
ttxThose are exposed on the project navigator09:41
ttxDefining the tags is just a way to build that information09:42
ttxso that it can be exposed in a way that is consumable by users09:42
ttxTo answer your question, users don't read the tags from projects.yaml09:42
ttxThey do, however, read the project navigator09:42
ttxwhich conveniently blurs team/project/repo/deliverable/service into a "stuff" thing09:43
ttxcdent: if the diveristy was only useful to us, it has nothing to do as a tag09:43
ttxTags need to provide a useful data point, that answers a question users may have09:44
ttxIf some tags are so far off that they do not provide an interesting data point for users, they should be removed09:44
ttxException being the tc-approved-release which is a thing that the bylaws define09:44
ttxand that we need to define one way or another09:44
ttx(could be something different from a tag though)09:45
cdentso, 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
cdentBut 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
ttxcdent: yes, that's the idea09:45
ttxcdent: now I wouldn't paint them as a total success :)09:46
ttxthe "stuff" mapping done at the project-navigator level is kinda fuzzy09:46
ttxresulting in weird corner cases (like Telemetry)09:46
cdentAre 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
ttxcdent: not sure09:47
ttxBUT we have been having that discussion lately:09:47
cdentbecause it _seems_ that the reason people choose certain project is because other people have alread chosen it09:47
cdentwhich is normal and fine, but suggests that tags are overhead09:48
ttxtags/project-navigator is a bit of a reactive thing. You describe things as they are, not as you want them to be09:48
ttxWe might want to paint a more aggressive picture of how things should be, even if we are a bit off09:48
cdentI agree that we should be painting future pictures much more.09:49
ttxi.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 yet09:49
ttxput things in a "ops-tools" bucket or a "deployment-tools" bucket09:49
ttx(that's the work being done/explored with mapping09:49
ttxTrying to segment things based on the role they have in the system09:50
cdentunconstrained growth is cancer?09:50
ttxBut also potentially based on how mature they are09:50
cdentSo, 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 to09:57
ttxI'll plead guilty that the tags system was an engineer solution to an essentially-marketing problem09:57
cdentand when evaluating the creation of tags we need to think primarily in terms of their usefulness on the navigator09:57
ttxThat said, the marketing folks were asking us to produce data that they could remix, so that's what we gave them09:57
cdentI tend to think that when people are looking at the navigator they are looking at projects09:57
cdentso tags that apply to something other than projects may be moot09:58
ttxyes, that's a good point09:58
ttxties back into the need to create buckets09:58
ttxpython-novaclient has nothing in common with nova-the-service09:58
ttxexcept they are both produced by the same team09:58
ttxexposing them on the same level anywhere just adds confusion09:59
* cdent nods09:59
ttxIf they were called services/nova and clients/nova that would be much clearer09:59
ttxor even core-iaas/nova and pythonclients/nova09:59
ttxanyway, hopefully we should have a plan to present by Denver10:00
ttxstill very much in brainstorming phase10:00
ttxso thanks for sharing your concerns10:00
cdentI think they can be useful as long as we keep them relatively simple and easy to judge.10:01
cdentOnce we start having to ask questions about what they mean, then boom10:01
cdent(I’m still confused about maintenance-mode, for example)10:01
ttxThe whole diversity tagging could be replaced by a regular repoort10:01
ttxwhich would allow for much more detailed analysis and information10:02
ttxAs engineers, we like the idea of a magic formula, but in reality we need to apply some analysis on top10:02
* cdent is not an engineer10:03
cdentI’ve always bristled at the concept of “software engineer”10:03
ttxlike, diversity doesn't matter if your project just has a couple commits per cycle10:03
* cdent nods10:03
ttxPeople want to know health and resiliency of the contributor base, not exactly how manu organizations it takes to do 80% of core reviews10:04
ttxThey want to know "can I bet the future of my organization on this project"10:05
ttxIt feels like they might read a regularly-produced contribution report more than a set of tags10:05
* cdent continues to wonder who “they” are10:11
*** dtantsur|bbl is now known as dtantsur10:11
*** mugsie has quit IRC10:22
*** mugsie has joined #openstack-tc10:25
*** mugsie has quit IRC10:25
*** mugsie has joined #openstack-tc10:25
*** mugsie has quit IRC10:31
*** mugsie has joined #openstack-tc10:33
*** mugsie has quit IRC10:33
*** mugsie has joined #openstack-tc10:33
openstackgerritSean Handley proposed openstack/governance master: Add public cloud WG.  https://review.openstack.org/48955510:41
openstackgerritSean Handley proposed openstack/governance master: Add public cloud WG.  https://review.openstack.org/48955510:49
openstackgerritAlexander Chadin proposed openstack/governance master: Add watcher-tempest-plugin to watcher project  https://review.openstack.org/48955710:52
sdaguettx: 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 them11:22
sdaguettx: 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 welcomed11:23
openstackgerritSean Handley proposed openstack/governance master: Add public cloud WG.  https://review.openstack.org/48955511:37
*** cdent has quit IRC12:32
dimsttx : 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
mugsieshould we not add easier to run production backends to barbican?13:24
mugsiebarbican itself is not too bad from what I remember, the complexity was in the backends, especially the ones you should run in production13:26
dimsmugsie : leaning towards, not running one more thing and a minimum api that can be better guaranteed to work13:26
mugsieI 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
dimsmugsie : right, are those needed by majority of use cases is the question.13:31
mugsieI would be afraid of people trying to re-implement them if barbican is not there, or worse having an `if barbican .. else ` block13:32
*** cdent has joined #openstack-tc13:32
mugsiefor 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 head13:34
dimsmugsie : then designate should do barbican directly, and evangelize to operators why that's the best choice. no?13:35
mugsieyeah - but if it is not a base service we can't rely on it13:35
mugsieit is the chicken and egg problem13:35
cdentrely on it and they will come?13:36
mugsieor people will just disable DNSSEC :)13:36
dimscdent : not sure if we should lean towards easier ops take by providing options (or) towards the dev concern mugsie pointed out13:37
cdentdims: I think the “omg too many services” concern is a red herring13:37
*** hongbin has joined #openstack-tc13:38
cdentonce you automate 5 things, 10 things is not actually 5 more13:38
mugsiefor 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 storage13:38
dimsmugsie : yes, and most enterprise will have one or more already13:39
mugsieat which point, barbican can use the HSMs that are pre deployed13:40
mugsiehaving it inside  a single service makes complicance, and segragation easier from an ops side13:40
dimsmugsie : is there any other alternative to make everyone switch on barbican?13:42
mugsiedims: 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 project13:44
cdentwe insist on keystone being a, uh, keystone, and require that people shim to their enterprise infrastructure13:45
cdentwhy can’t barbican be the same?13:45
mugsiefor 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
cdentand we require barbican13:45
mugsiecdent: yeah, thats true13:45
dimscdent : we are not in a position to twist arms anymore13:45
cdentI find it hard to believe that we _actually_ ever were. People just kind of went with it.13:47
cdentI think rather than trying to predict outcomes, we should create a solution and see if it works.13:48
cdentRespond to feedback rather than predicting feedback.13:48
dimscdent : 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 is13:49
dimscastellan is a oslo-like library13:49
*** emagana has joined #openstack-tc13:50
cdentdims: which interfaces to a variety of keystores, including barbican?13:54
dimsyes, barbican is done. kmip/vault in progress13:55
cdentdims: 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
cdentbut isn’t the point of castellan to mask that?14:03
dimscdent : castellan is a subset of the functionality14:04
mugsieCastellan only provides secret storage and retrival14:04
*** lbragstad_ is now known as lbragstad14:04
dimscdent : if someone needed full barbican functionality, they can use barbicanclient14:04
cdentIs secret storage and retrieval the key need?14:05
dimscdent : that was the belief for starting the castellan library14:05
cdentbut now?14:06
dimscdent : see the nova+cinder encryption scenario14:06
dimscastellan is enough. no need for full barbican functionality14:06
cdentand where is it not enough?14:07
dimscdent : mugsie's scenario with DNSSEC14:07
cdentI’m sorry if I sound like I’m being obtuse or obstreperous, just trying to get things clear so there aren’t some hidden assumptions14:08
cdentI’d like to figure out some way to move something forward14:08
cdentwe often seem like we’re going in circles14:08
dimscdent : not at all. happy to share what i know14:09
cdentso next question: are there roadblocks in the way of using castellan for the cinder scenario?14:10
smcginnisCinder switched to using Castellan in Ocata, though I'm actually not 100% on it's full use.14:11
cdentmugsie: what do you think would happen if you just declared: from pike on, designate requires barbican ?14:14
* dtroyer catches up14:15
dtroyerre: 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
dtroyerAlso, DNSSEC is opaque enough to many that another service to support a solid implementation should be a small price to pay14:19
sdaguedo we know what is required to make castellan enough14:19
dtroyerFor DNSSEC?  I think it would be for it to proxy all of Barbican14:20
dtroyermaybe not all, but the signing APIs14:20
sdagueI 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 backends14:20
sdagueok, so lets be specific, what set of APIs are needed to get added.14:21
dtroyerI saw mugsie mention signing above.  I don't think DNSSEC uses the CA bits14:23
*** marst_ has quit IRC14:28
mugsiesorry, I went for a coffee, an missed all this :)14:34
*** marst has joined #openstack-tc14:35
mugsieso, for designate, we will use (as yet un written, but we have discussed it in principal with barbican) signing api14:35
mugsiewhich, 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 back14:36
mugsieso, it will be a signing using a private key in barbican API14:36
mugsieand users will put a key in barbican, and gran us access, (i imagine much like they do in octavia right now)14:37
dtroyerI think sdague's question is whether the signing APIs should also be routed through Castellan like the secrets are now14:37
mugsiewell, I am not sure that we would be able to find something else to back castellan that would support it, would we?14:39
dtroyerif I understand ttx's response to that earlier the answer is 'just use Barbican directly' in this case14:39
dtroyerwill Barbican implement the signing directly or use a back-end for that part?14:39
mugsiecdent: I don't think we would require barbican for all uage of designate - just if you have DNSSEC turned on.14:39
cdentfrom a packagers standpoint that means designate requires barbican14:40
mugsieI do think if it is not a base service, a different, also not base service that required it, would just not be installed14:40
dimsdtroyer : that functionality is already in barbicanclient... why duplicate?14:40
mugsiecdent: it could be a recommends, instead of a requries for a packager14:40
dtroyerdims: in the client directly?  so it isn't a REST API, but a python lib?14:40
cdentmugsie: what I mean is that the packager would have to package barbican if they package designate14:41
mugsiecdent: oh, humm. yes - probably14:41
dimsdtroyer : i meant, there's no point making everything available through barbicanclient (making REST calls to barbican), from castellan14:41
mugsiedtroyer: from our discussions in the past, it looked like it was in barbican, but i can't speak for that team14:41
sdaguedims: where I get concerned is that if we piecemealing together security features through multiple libs, things get wonky14:41
dimsright sdague14:42
sdagueso... 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
openstackgerritMerged openstack/project-team-guide master: Update feature branch creation details  https://review.openstack.org/48929314:42
sdaguebecause we're picking appart things based on really partial information14:43
dtroyerI may have misunderstood then, dims you are just talking about what the app calls (barbicanclient vs castellan) and not where the signing code lives.  gotcha14:43
dimsyep sdague14:43
mugsiesdague: yeap14:43
sdaguethis 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
sdagueI don't care where the artifact is, but this problem going through that kind of process would be good14:44
dimssdague : 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 stuff14:45
sdaguedims: 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 now14:46
dimssdague : dtroyer : i have heard many folks have their own implementations (including huawei)14:46
sdaguedims: that would be great to capture, and to capture why14:46
dimsagree that we don't know enough to make a good decision sdague14:47
*** cdent has quit IRC15:21
* ttx reads scrollback15:29
dimssmcginnis : w00t on the release ptl candidacy15:39
smcginnisdims: ;)15:39
ttxmugsie: 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 feature15:43
dimsttx : why overload castellan? why not let designate use barbican directly?15:44
mugsiettx: exposing it in castellan means that the key has to be loaded in designate's memory, right?15:44
mugsiewhich is not some thing I am keen to introduce15:44
ttxmugsie: not necessarily, in case of Barbican that could be a pass-through to Barbican's signing15:45
* dims still curious15:45
mugsieunless we write a custom backend for castellan, at which point, we should just use barbican15:45
dimsright mugsie15:45
dimsjust to understand what exists, i am writing a castellan driver for vault - https://review.openstack.org/#/c/483080/15:46
ttxdims: I'm concerned about the added dependency hampering adoption of Designate15:46
mugsiebut -keep in mind, this for an optional feature, and we would not need it unless you wanted DNSSEC15:46
mugsiewhich 99% of people will not need / or want15:46
ttxBasically if we say that "a castellan-compatible secrets store" is in base services, and Designate depends on Barbican itself, that creates a shift15:46
dimsmugsie : so folks who need that can barbican directly15:46
dimsttx : a small segment of designate users15:47
ttxImagine the case of a Nova/Cinder/Neutron deployment that opts to use Castellan+Vault15:47
ttxBasically they will never use Designate since that would mean ditching Vault for barbican15:47
ttxwhereas if castellan exposed the signing API...15:48
mugsieI would be worried about even the hint of needing a non base service would hurt us right now15:48
mugsiettx: if we could find a way of having the signing api be secure, without us writing code to do it, that would be great15:49
dimsttx : is there any other use case other than the DNSSEC/designate?15:49
mugsiebut the likes of vault will not have a signing api :/15:49
mugsiedims: doesn't octavia use it for SSL ?15:49
ttxBasically 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 consistent15:49
ttxImagine that a project had a hard-depend on Postgresql15:50
ttxor ZeroMQ15:50
ttxSo if Barbican exposes functionality that can't be replicated easily with other backends, maybe we should make Barbican a base service15:51
dimsmugsie : seen this? https://www.vaultproject.io/api/secret/pki/index.html15:51
ttxrather than "a castellan-compatible secrets storage backend"15:51
mugsiedims: I have not15:51
mugsiewill have a dig through it15:51
ttxNow if Vault can do the same signing stuff, then maybe that should be exposed in Castellan itself15:51
ttxwe just can't have it both ways15:52
mugsieits just SSL :/15:52
mugsiebut that could work for octavia15:53
mugsiebut I would not like to speak on their behalf15:53
johnsommugsie What are you signing us up for?  grin15:53
*** cdent has joined #openstack-tc15:53
ttxwe should be having that discussion on -dev since it's not really a TC thing and could use wider input15:54
* dims blames cdent and johnthetubaguy :)15:54
dimsmugsie : would be great if you can help define what additional API is needed in castellan for designate15:55
ttxyes, that's definitely new data that wasn't taken into account when that was discussed in ATL15:55
cdentdims: I accept that blame and raise you “you started it"15:56
* ttx checks15:57
ttxerr, I probably need to fold since you raised15:57
*** emagana has quit IRC15:58
cdentTC Poker Night15:59
cdentnow with buzzword bingo15:59
*** emagana has joined #openstack-tc15:59
sdagueI honestly think the rest of the conversation is mostly circular until there is something like a spec15:59
cdentit’s certainly unclear to me what the real goals and use cases are16:00
cdentso a spec like thing would help that16:00
*** emagana has quit IRC16:03
*** emagana has joined #openstack-tc16:06
*** emagana has quit IRC16:59
EmilienMwhat happens if a project doesn't have PTL again?17:05
EmilienMI always forgot17:05
cdentwe make EmilienM do it17:07
EmilienMNO !17:07
cdentyou mean if no one volunteers?17:08
EmilienMcdent: yes17:13
EmilienMcdent: I'm not sure we'll have someone for Puppet OpenStack17:13
EmilienMcdent: also, I'm not sure we *need* someone for this project17:13
EmilienMbut that's a personal opinion17:13
*** dtantsur is now known as dtantsur|afk17:13
ttxIf no candidate, the TC finds and appoints someone17:13
ttxor drops the team altogether :)17:13
cdentso, like I said, we make EmilienM do it ;)17:14
* ttx digs up resolution17:14
ttxcomplete with old "program" language -- new linguo is "project team"17:15
ttxbut you get the gist17:15
cdentEmilienM: 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 onerous17:15
ttxright, you still need a contact point17:15
ttxto answer for "the team"17:16
ttxwhen organizing things cross-project you can't deal with every team being organized differently17:16
*** mwhahaha has joined #openstack-tc17:16
EmilienMlet me invite alex17:16
EmilienMmwhahaha is Alex Schultz (in case people wonder), the PTL of Puppet OpenStack17:17
ttx"the PTL" is about the only thing all teams have in common17:17
ttxso when organizing things like release management, or events like Forum/PTG it's precious17:17
EmilienMit'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/CI17:17
ttxIf we had to remember which teams have 0 PTL and which teams have 3, that would be a mess17:18
EmilienMttx: I agree17:18
EmilienMso iiuc, if we want to keep Puppet OpenStack team under governance, we need a PTL17:19
EmilienMAFIK we won't have sessions at PTG17:19
ttxcall that a "contact point" if that helps :)17:19
EmilienMwe stopped (today) doing weekly meetings17:19
EmilienMbecause we have nothing to say17:19
mwhahahawe haven't really had anything at the summit/ptg lately so the openstack ptl just does releases at this point17:19
ttxEmilienM: maybe it should be marked maintenance-mode17:19
mwhahahasince we're not adding features but just enabling end users to be able to configure the existing upstream stuff17:20
ttxmwhahaha: isn't there some effort keeping up with new projects being added ?17:20
ttxthe fact that you don't need much coordination or meetings doesn't mean you should disappear17:21
EmilienMwe support most of OpenStack projects17:21
mwhahahasince we basicaly already have everything stubbed out it's minor17:21
mwhahahawe aren't disappearing necessarily but operators are 3+ releases behind17:21
mwhahahaso folks don't need new stuff until much later17:21
mwhahahait's always been a problem where we're ahead of our actual consumers and it's only getting more noticable now17:21
ttxI'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 PTG17:22
ttxand that's fine17:22
mwhahahayea that's probably it17:22
ttxshouldn't be too hard to convince someone to cover that17:23
* ttx needs to run17:23
ttxaka eat17:23
EmilienMmwhahaha wrote a tool to release Puppet OpenStack modules in 1 click17:23
mwhahahai'll probably just do it next cycle and we'll work on figuring out what to do for R17:24
cdentWho are the big/main consumers of puppet openstack these days?17:24
EmilienMwe said that last cycle ^17:24
EmilienMcdent: more than we think17:24
cdentI’m sure17:24
EmilienMcdent: tripleo as an "official" consummer17:24
EmilienMbut a lot of deployments use it17:24
EmilienMCERN included17:24
cdentIs tripleo going to move all the way to ansible eventually?17:24
mwhahahabut like i said most are so many releases behind they don't know what's happeniung :/17:25
EmilienMyes we are working on it17:25
EmilienMbut I can't tell if it happens tomorrow or next year17:25
EmilienMwe're prototyping stuffs right now17:25
cdentmaybe someone from CERN wants to be the PTL?17:28
EmilienMcdent: they don't contribute to our modules17:28
cdentmaybe they should ;)17:28
EmilienMif we need to put a name on puppet PTL it has to be me or alex, imho17:28
EmilienMbecause nobody else steps up to release or fix ci17:29
EmilienMor even step up at all17:29
* cdent is well aware of EmilienM’s fixing ci heroics17:29
* cdent gives EmilienM a big cookie17:29
EmilienMit's a team work17:29
EmilienMmwhahaha: do you mind if I send an email about the situation?17:30
EmilienMmwhahaha: and you to reply to the thread if I missed something17:30
EmilienMmwhahaha: ok thx, just want to run that in public again17:30
*** emagana has joined #openstack-tc17:37
smcginnisThe term "Puppet PTL" kind of makes me laugh. :)17:39
EmilienMsounds like we have a volunteer17:44
EmilienMthanks so much smcginnis17:44
*** EmilienM is now known as emacchi18:14
*** emacchi is now known as EmilienM18:14
*** emagana has quit IRC19:30
*** emagana has joined #openstack-tc19:33
sdagueI'm assuming no meeting this week ...19:37
cdentsdague: yeah:19:40
openstackgerritSean McGinnis proposed openstack/project-team-guide master: Document process for lib release during freeze  https://review.openstack.org/48972319:41
openstackgerritSean McGinnis proposed openstack/project-team-guide master: Document process for lib release during freeze  https://review.openstack.org/48972319:45
openstackgerritSean McGinnis proposed openstack/project-team-guide master: Document process for lib release during freeze  https://review.openstack.org/48972319:55
*** emagana has quit IRC20:10
*** emagana has joined #openstack-tc20:11
*** emagana has quit IRC20:16
*** emagana has joined #openstack-tc20:21
*** emagana has quit IRC20:39
*** emagana has joined #openstack-tc20:40
*** marst has quit IRC21:09
*** emagana has quit IRC21:34
*** emagana has joined #openstack-tc21:36
*** emagana has quit IRC22:14
*** emagana has joined #openstack-tc22:16
*** emagana has quit IRC22:17
*** emagana has joined #openstack-tc22:17
*** emagana has quit IRC22:17
*** emagana has joined #openstack-tc22:18
*** sdague has quit IRC22:35
*** hongbin has quit IRC23:30

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!