Thursday, 2018-03-29

*** annabelleB has quit IRC00:02
*** zhipeng has joined #openstack-tc01:19
*** kumarmn has joined #openstack-tc01:21
*** annabelleB has joined #openstack-tc01:25
*** kumarmn has quit IRC01:27
*** annabelleB has quit IRC01:33
*** annabelleB has joined #openstack-tc01:59
*** annabelleB has quit IRC02:07
*** kumarmn has joined #openstack-tc02:33
*** zhipeng has quit IRC03:06
*** kumarmn has quit IRC03:21
*** annabelleB has joined #openstack-tc03:23
*** harlowja has quit IRC03:24
*** annabelleB has quit IRC03:39
*** ianychoi__ has joined #openstack-tc03:47
*** ianychoi_ has quit IRC03:50
*** harlowja has joined #openstack-tc03:59
*** dklyle has quit IRC04:26
*** ianychoi__ is now known as ianychoi04:29
*** harlowja has quit IRC06:06
*** chandankumar has quit IRC07:04
*** chandankumar has joined #openstack-tc07:09
*** jpich has joined #openstack-tc07:49
*** cdent has joined #openstack-tc08:22
*** dtantsur|afk is now known as dtantsur10:55
ttxLooks like we are 99% set on Sept 10 week for next PTG (in North America)12:39
ttxCan't remember who asked12:39
cdentwe've had a few different people come in here and ask over the past few days12:43
cdentis it safe to share the location yet ttx?12:43
* persia presumes "No", as there is only 99% confidence, which implies the booking is not sufficiently confirmed: announcing a date lets the gathering move to a backup location if needed, but announcing date+location makes any backup plan really expensive (as the provider feels no competitive pressure)12:53
*** kumarmn has joined #openstack-tc12:55
cdentwe should meet in my back yard, I'll do the foundation a deal12:55
persiaI remember requirements for power, network, lodging, and convenient flights.  I don't recall anyone indicating a requrement for a roof in any future-of-PTG discussions.12:56
*** rosmaita has joined #openstack-tc12:58
cdentairport (reachable from london, manchester and dublin) is 30 minute walk from that beach12:58
jrollcdent: +100012:59
cdentI'm sure flaper87 will go for it12:59
ttxNo, location can't be confirmed right now, beyond "in North America"13:02
dhellmannwe have beaches here, too13:04
persiabeaches are good for network, as there tends to be excellent line of sight and few conductive structural elements.13:05
* cdent thinks maybe dhellmann is missing one of the best aspects of this plan: I stay home.13:05
persiaI have been to beaches with good power, but not every beach is well wired.13:05
dhellmanncdent : oh, yes, I did overlook that aspect of the plan13:06
* jroll would also support fungi's back yard13:06
*** mriedem has joined #openstack-tc13:10
*** zhipeng has joined #openstack-tc13:16
dhellmanneven if we're not at a beach, we should make the theme of the next ptg "the beach"13:17
zhipengwould be great to swing by laguna beach or huntington beach :P13:23
*** hongbin has joined #openstack-tc13:49
smcginnis+1 for letting cdent stay home.13:51
dtroyerdhellmann: I'm not sure I want the tag #sandystack to be a thing14:02
smcginnisAs long as it's not s/st/cr/14:09
fungijroll: you're welcome to come to my backyard any time you like14:20
fungieither chill on my dock, or it's a 15-minute walk across the island to the ocean side14:20
fungi_getting_ here is the real challenge14:21
jrollfungi: I will gladly take you up on that one day :)14:21
jrollthe drive from here isn't terrible, I've done it before14:21
fungicool, lmk and as long as i'm not away for a trip i'm happy to have people14:23
* cdent hires a boat14:23
fungicdent: it would be a lengthy trip by boat from you, but might be fun to try14:24
fungiin a cabin cruiser large enough to not get swamped on the open ocean, you're probably looking at a few weeks minimum14:24
fungijust head southwest and i'm near the lighthouse with the horizontal black and white stripes just north of the taller one with the helical black and white stripes14:26
fungibut beware the shoals, they've claimed many a seafaring vessel over the centuries14:26
* cdent takes a clipper14:28
mugsiePTG on a boat? :D14:29
dtroyernow there's an idea!14:30
smcginnisHey, they used to do the perl conferences on cruise ships, right?14:32
SamYaplei vote boat14:36
* SamYaple goes to start some rumors14:36
dims_hahaha ... nooooooooooo!14:36
dims_i vote for cdent's backyard/beach14:37
cdentif it is in international waters that helps with some of the visa problems14:38
SamYapleand we get to fight pirates!14:38
mugsiejust need to charter a helicopter to shuttle people back and forth :D14:38
* smcginnis is surprised no one has suggested a container ship :)14:39
cdentsmcginnis: you should be totally ashamed of yourself. The punning you've done lately... well...14:40
smcginniscdent: You pretend like you don't think I'm funny, but I know it's just a front. :P14:41
TheJuliaSamYaple: Excellent positive point to a boat!14:43
TheJuliasmcginnis: I can confirm, I laughed14:44
SamYapleTheJulia: im picturing swords and scurvy everywhere14:44
smcginnisTheJulia: :)14:44
TheJuliaI'm sure enough of us have a balanced diet such that scurvy will not be an issue... as long as it is not an entire development cycle on a boat.....14:45
smcginnisSamYaple: I've hear rum is good for scurvy. We can ration out grog.14:45
mugsieTheJulia: now thats an idea :D14:45
TheJuliaThen, as cat staff, the cats would be unhappy and would need to come along.14:45
*** david-lyle has joined #openstack-tc14:45
SamYaplei see nothing wrong with this14:46
mugsiemy dogs may not like it, but we shall see14:48
*** zhipeng has quit IRC14:49
*** annabelleB has joined #openstack-tc14:51
fungitc-members: office hour?15:00
fungismcginnis: i believe rum/grog is only good for scurvy if you add lemons or limes... maybe stick to mojitos?15:01
smcginnisThat works.15:01
*** annabelleB has quit IRC15:02
TheJuliaso mojitos replace???15:02
fungimojitos are merely a convenient means of combining limes with rum15:03
TheJuliaI guess that makes sense, mint being a plus15:04
fungithe little umbrella is also useful to keep it from getting diluted if it starts to rain15:04
ttxcdent started a good discussion on the Adjutant review on how to consider project additions in OpenStack in 2018, I tried to answer with my current rule of thumb in a comment there ICYMI15:04
smcginnisBoth comments had some very good points.15:05
cdentthose were good answers ttx, but as you note, some of the harder deeper questions are left open15:05
smcginnisI do wish we had a little more straightforward decision tree around these, but it does seem each one has its on slight nuances that make that difficult.15:06
*** annabelleB has joined #openstack-tc15:06
mugsieI personally think by bring it into the fold we can help interop for some things (like a standard password reset, quota request mechanism, etc)15:06
mugsiebut I can see the microAPI having issues15:06
smcginnisThat's my dilemma. It both helps interop and has huge potential to hurt it.15:07
mugsieand, if clouds are doing this internally anyway, does it actually impact interop?15:08
dtroyerIf the exposed APIs were well-defined and the glue in the middle being the only bits that ops would alter it would go a long way to easing my concerns15:08
smcginnismugsie: That's kind of where I keep going back to.15:08
smcginnisI would assume all public clouds are doing something like this.15:08
mugsiebut it does set a "we think you should be able to extend APIs via plugin code" precent15:08
smcginnisSo this at least makes it done in a somewhat consistent way.15:08
dtroyerit does affect it as the examples that keep being used are consumer-facing15:08
smcginnisI was better with it when I assumed they were just going to be APIs the operators used to plumb in custom UI actions.15:09
smcginnisA little more concerning if it is a consumer accessible API.15:09
mugsiedtroyer: sure, but that stuff is already non interoperable, as each cloud has a different system for it15:10
fungii expect it's done that way to make it easier to tie in disparate systems which may be involved in account management, but does run the increased risk that those will be kept private/proprietary even for commonly-used backends15:10
EmilienMmnaser: hey, if you around, do you have something like Adjutant in your public cloud?15:11
mugsiethe hope would be as more things get added to the core of adjunct the tasks on each cloud would become eventually consistant15:11
cdentEmilienM: good idea. less speculation, more data.15:11
dtroyermugsie: that is fine what you do outside of OpenStack.  an official project should not allow/encourage that sort of thing.  we removed API extensions in many places for exactly this reason15:11
mnaserEmilienM: our own little tooling, not adjutant itself, but we really have two operations15:12
mnasercreate user in keystone, delete user in keystone (and purge resources)15:12
openstackgerritThierry Carrez proposed openstack/governance master: Official projects should not keep tagging rights
EmilienMmnaser: thanks for confirming that there is a need of something on that regard15:13
smcginnismugsie: I guess I could live with eventual consistency.15:13
EmilienMmnaser: how do you deal with password reset for example?15:13
ttxsmcginnis: dhellmann ^ that is what we just discussed in #openstack-release15:13
EmilienMmnaser: if any question is too confidential you can just tell me :D15:13
smcginnisttx: ack15:13
mnaserEmilienM: our openstack credentials are not tied into our customer 'billing' credential.  our billing system is a different setup and set of credentials15:13
fungidtroyer: well, removal of api extensions in services was because they were user-facing apis... if this is effectively an internal-only api (acting as glue between the webui and other services) then the only real interoperability risk is that cloud providers can't easily share/reuse each others' webui implementations, right?15:13
EmilienMcdent: yes I think we need to collect data before speculating what the community needs15:13
mnaserEmilienM: no problem, once you sign up, you get openstack credentials and that's all the billing system does (provision accounts)15:14
openstackgerritThierry Carrez proposed openstack/governance master: Official projects should not keep tagging rights
EmilienMmnaser: oh I see, like an ldap or something external.15:14
EmilienMso when the users change their password, the system deals with another API but OpenStack, iiuc15:14
ttxnow with depends-on / needed-by15:14
dtroyerfungi: except that this appears to _also_ be for consumer-facing APIs.  am I wrong about that?  I haven't seen a clear statement anywhere15:15
fungidtroyer: yeah, i expect we need more clarity on that front15:15
mnaserEmilienM: if someone needs to change their keystone pw, they can do it themselves via the api.  for their 'billing' account, they would use the built in reset password for the billing15:15
cdentoh totally jinx in gerrit review by mugsie15:15
dtroyerif this is web only, I am MUCH less concerned, many ops tweak Horizon or replace it altogether as it is, rarely does anything non-human need to handle that15:15
EmilienMto me, (and I'm probably wrong), but I currently think that Adjutant is adding features that are missing in some services/APIs15:16
mugsiecdent: :)15:16
mugsieand thanks to smcginnis for the ultra quick clarification :)15:16
smcginnisEmilienM: So you think keystone should have account create and password reset APIs?15:17
cdenthmmm. clearly the release management team is trying to take away my guns15:17
EmilienMthat's exactly what I think, thanks for putting words on it15:17
mugsiesmcginnis: for sql based domains, yes15:17
EmilienMand same for quotas15:17
smcginniscdent: Hah15:17
dtroyerEmilienM: it totally is, being built over shade/SDK.  Using that functionality is at leas standardized, if the API infront of it is too I have less concern15:17
* dhellmann slips into the back of the room late15:17
pabelangersmcginnis: I think it should, especially if it wants to be used as a stand alone service15:17
mnaseri'd personally disagree and prefer that stuff stays outside the openstack world because then it starts to tie into business workflows15:18
smcginnis"business workflows" is a good term for what I was thinking.15:18
EmilienMtake this code:
pabelangersmcginnis: +115:18
smcginnisThere are some operations that seem better done _on_ OpenStack rather than _in_ OpenStack.15:18
EmilienMdon't you think this could reside in Keystone?15:18
cdentsmcginnis: very true, and of courese that begs: where's the boundary (to bring it back to that common q)15:19
mnaserEmilienM: i guess that could.  though, on the other hand, i don't think if the person behind that commit could have pushed up a keystone change to alllow something like this15:19
EmilienMcdent: exactly, there is a boundary here.15:19
mnaserand i don't think it would have been an issue to merge it15:19
*** gagehugo has joined #openstack-tc15:19
pabelangerEmilienM: I always seen something like that happening in horizon, if it was broken out into a front-end just for keystone15:20
pabelangerbut that's just me15:20
cmurphyit's a little tricky because email isn't a real attribute for keystone users15:20
mnaser^ yeah that too, we don't even use it15:20
cmurphyso there would be some policy problems for users updating their own emails15:20
mnaserand you can edit a tenant from horizon15:20
mnaserand make that change15:20
cmurphybut it wouldn't be impossible15:20
mnaser(i think? let me double check.)15:20
ttxIf Adjutant was more around a clear set of functions, and less of a micro-API factory, that would ease my concerns15:21
cmurphypassword reset would also be a little weird15:21
cmurphybut probably doable15:21
EmilienMcmurphy: why would it be weird?15:22
cdentwhich is interesting, ttx, because many other things we create are abstractions that are factories of stuff used to create something that's actually workable15:22
ttx(even if the same code could be reused to build other micro-APIs)15:22
cdentfew people want to use openstack _directly_15:22
cmurphyEmilienM: if i click the "i forgot my password" button it usually sends me an email with a link15:22
cdentbut plenty of tools want to talk to openstack15:22
cmurphyso, keystone would have to know how to send an email15:22
cmurphyand something needs a web frontend for the user to click on15:23
mnasercmurphy, EmilienM: but that would mean that now keystone is sitting in business workflows.  i much rather have keystone not be this way, and have other processes that handle that sort of thing15:23
mnaseri can imagine a private cloud preferring that password resets go through their own procedure/process15:23
ttxI guess I'm concerned about the return of custom extensions15:24
cmurphyEmilienM: mnaser we could maybe find a way for keystone to expose just enough of the right bits so that horizon or some other tool could take over the business workflows15:24
EmilienMcmurphy: I was more thinking at keystone being about to reset a (random) password and that's it15:24
TheJuliaFrom an operational standpoint, it kind of makes sense to keep such things separated because some things are going to be generally useful in some contexts, and in other contexts they will need to have configuration switches to be explicitly disabled because otherwise it might not meet the security requirements.15:24
EmilienMbeing able*15:24
fungicmurphy: also, for a variety of account backends keystone may not have access to change passwords, or they may not even have the concept of a "password" in a traditional sense (think otp and the like)15:24
cmurphyfungi: ++15:25
fungiso sort of hard to generalize that as a feature of the keystone api15:25
dhellmann"custom extensions" have been my concern, too. I have no doubt that clouds use them, so the question is should we bring in a project that makes it even easier to do in a way that makes it less clear those things are not "part of" what we call openstack15:25
smcginnisI know end users don't know or care, but we do publish what the common set of functionality is expected for an "OpenStack Powered" cloud.15:26
TheJuliadhellmann: or perhaps encourage very clear delineation somehow?15:26
mnaseras much as we like to keep openstack 'vanilla', id be more than happy of seeing cloud deployments taking advantage of extensions for their own requirements, as long as it doesn't change the existing api and adds a new endpoint or something15:26
dhellmannI'm less concerned with the idea that some of these things could go into existing official projects (like keystone). I agree that sometimes you want to isolate account operations and keystone already has a well-defined scope15:26
dhellmannTheJulia : maybe. how do you see that working?15:26
TheJuliamnaser: +115:26
smcginnisSo as long as they still support that minimum, does it matter _that_ much if someone adds some special sauce?15:26
pabelangerEmilienM: cmurphy: FWIW: here is how I did forgot password in horizon years ago: can't remember what version of keystone / horizon that was15:27
mnaserdhellmann: i was thinking about that... "Keystone is an OpenStack service that provides API client authentication, service discovery, and distributed multi-tenant authorization by implementing OpenStack’s Identity API." .. nothing about managing identity15:27
dtroyersmcginnis: and that is a subset of the stuff actually required to interact with a cloud.  way too small a subset imho15:27
pabelangerEmilienM: cmurphy: never got around to doing password reset due to emailing of URL stuff15:27
dhellmannsmcginnis : for me it's a matter of intent of the project. If the intent is to provide a specific set of well-known APIs and it happens to be extensible, that's one thing. But if the intent is to be the place that all random APIs live, that feels different.15:27
smcginnisdtroyer: It is small, but even with vanilla OpenStack and all the config options, it's the base set of expected functionality.15:28
dhellmannmnaser : right15:28
pabelangeralways thought we could support something like that for horizon15:28
dtroyersmcginnis: so should we encourage exteing the non-covered parts supplied by OpenStack project?15:28
TheJuliadhellmann: I haven't had enough time to really think that through, but it seems we need to balance generally useful and solves a problem against does something make sense and fill a need. We can't just say this is a reason to add x feature to y project to solve a single problem, especially when only so many operators are going to need or want such tooling. In some contexts, such tooling would undoubtably be forbidden.15:28
TheJuliaIn a sense, it does start going to powered, but it is really a workflow tool in my mind, so I'm not sure how to cleanly deliniate that at the moment15:28
smcginnisdhellmann: "All random APIs" would be a concern, but as long as they don't change existing expected API behaviour, I'm a little less concerned.15:29
smcginnisdtroyer: I wouldn't say "encourage", but I don't think "prevent".15:29
dhellmannsmcginnis : as long as it's possible to use the cloud in standard ways without interacting with the non-standard APIs15:29
mnaseri'd love to see adjutant as a bunch of api extensions for different projects to fulfill their needs rather than its own thing.15:29
smcginnisdhellmann: ++15:29
dhellmannI think the "workflow" thing is really an implementation detail that is confusing the discussion.15:30
mnaserit'll give them the flexibility of being able to commit things quickly and not rely on the upstream for every single project..15:30
TheJuliamnaser: except, given other projects capacity... can it really be taken on, or are you suggesting something not under those projects stewardship?15:30
EmilienMmnaser: in your proposal I see an eventual collaboration issue15:31
dhellmannmnaser : that sounds an awful lot like the system we had early in OpenStack's life and that we've been trying to move away from15:31
dtroyermnaser: that sounds like forcing API extension back in to each API.15:31
EmilienMmnaser: like "Adjutant being a shortcut to implement my api stuff"15:31
mnaserTheJulia: the idea is that adjutant remains there, but for example, nova api extensions (dunno if they're a thing still) would be under the adjutant package where it would install adjutant.nova.extensions which anyone can mount into their app if they want15:31
fungiis the argument for extensible apis in adjutant that operators/vendors will need to match them to business logic of backend account management systems?15:32
mnaserright, but if keystone doesn't care about you changing your email and wouldn't want to merge things, then you can just use the adjutant extension which could at least deliver *some* sort of standard way across clouds if those extensions are available, but i'm just throwing thoughts out loud.15:32
dhellmannfungi : my understanding is that the adjutant team didn't want to try to predict what APIs a deployer might need, so they designed it to make it easy to add new ones15:32
dhellmannmnaser : that presumes that there would be 1 adjutant API for changing the email of an account, which the adjutant team doesn't seem to be saying is their goal15:33
mnaseralso, adjutant is all done by a single company right now, so it's important to keep that in mind15:34
smcginnisI could actually see getting to a point where theirs an "Adjutant Forge" repo where cloud operators could share and use "business workflow" additions to help them run their clouds. That actually seems like a very good thing in the long run to enable the potential for.15:34
EmilienMunfortunately, a lot of new projects are made by a single company15:35
* TheJulia begins to wonder if we're too focused on the low level details as programmers trying to solve problems15:35
cmurphymnaser: is your point that their business workflows differ from everyone else's? or just that single vendor is not great?15:35
dims_y probably TheJulia15:35
EmilienM(don't mention that some current projects are also single company :))15:35
cmurphyEmilienM: s/new projects/projects15:35
* EmilienM hides15:35
dhellmannsmcginnis : do you think that would happen? or would we have 50 different email changing APIs like we have zillions of purpose-built container images or ansible roles?15:35
TheJuliacdent: dims_: then perhaps a step back? and maybe go back to smcginnis's point at the beginning as to more clear guidelines?15:36
smcginnisdhellmann: Participating in the ops midcycles, I'm maybe somewhat optimistic, but I could see it happening.15:36
dhellmannTheJulia : that's why I tried to steer us away from the "workflow" thing back onto "what is the adjutant trying to do?"15:36
mugsiemy money would be 50 different APIs, unless adjunct added a default one15:36
dtroyerdhellmann: that is my concern, as each one of those will have a local tweak to meet a specific need.  Who in the world is going to consume these APIs?  will each installation of adjutant need its own clients?15:36
cdentWhat about this for a (strawman) metric: If it's not easy to decide, the answer is "no"?15:36
dhellmanncdent : that's more or less my default, and is in line with our typical consensus approach15:37
mnasercmurphy: we’re looking at how one vendor needs specific workflows that happens to be open sourced and making it to be a “requirement” (can’t think of a better word) for other operators15:37
smcginniscdent: I think that may be true in many of the cases, but not always.15:37
EmilienMdhellmann: only zillions? :-O15:37
dhellmannEmilienM : heh15:37
TheJuliadhellmann: That is a good point, although it feels like also doing that we may miss the entire collective meaning. At least, that is just my feeling.15:38
EmilienMcdent: sure but before saying "no" we should maybe revisit our vision and prepare a common message15:38
dtroyerEmilienM: then we should do that before saying yes too15:38
EmilienMwe should revisit our vision anyway :-) many things have changed15:39
TheJuliacdent: I'm with dhellmann that is kind of the default, but we should kind of be clear that "we are not read, and have yet to reach consensus" as opposed to outright rejection in the terms of "no"15:39
mnaserI was always confused by the existence of adjutant since it was announced a while back.  It seemed to reimplement a lot of the existing OpenStack APIs which already exist minus a few select ones. I really don’t understand the purpose at the moment for it.15:39
TheJuliaEmilienM: very good point15:39
cdentInteresting, I had kind of assumed the default position was closer to yes, because we seem to have a lot of official projects?15:40
mugsieas someone who went through both "incubation" and "big tent" applications, and has watched the last few project applications, we need to have documented this stuff *before* people apply. We cannot contiunually change the goal posts as projects apply15:40
cdent+1 to revisit vision whatever happens15:40
dtroyermnaser: I totally get why it exists, and frankly would love to use such a thing to build saner APIs out of what we have.  But to make it in a why that encourages each deployment to modify that is madness15:40
cmurphymugsie: ++15:40
TheJuliamugsie: agreed15:40
cmurphycdent: i think as mugsie pointed out, the default position has shifted over the years15:40
mugsieand if every couple of project applications get us to the "what is openstack" question, we need to have a good answer.15:41
dhellmannmugsie : do you think we're moving the goal posts?15:41
dtroyer"what is openstack" keeps coming up because there are plenty of people that don't like the answer and want it to change15:42
mugsiedhellmann:  on the face of it, yes. they meet the documented requirements.15:42
dhellmannIn this context, I define openstack as a collection of tools for building a cloud, with interoperability being key when the cloud includes a given component.15:42
TheJuliadhellmann: we're trying to quantify what it is actually doing and how we can solve the same low level problems in other projects, that seems like we're trying to rationally adjust the goal post to force contribution to the other projects when that might not be appropriate for every deployment.15:42
mugsiedtroyer: we have never answered it properly15:42
dhellmannmugsie: it's not clear the tool serves the mission, and I think that's the point we're trying to answer15:43
dhellmannat least it's not clear to me15:43
dhellmannTheJulia : I don't think we should be worried about implementing the features in other projects necessarily15:43
mugsiedhellmann: the line for that is :15:43
mugsie> It should help further the OpenStack mission, by providing a cloud infrastructure service, or directly building on an existing OpenStack infrastructure service.15:43
mugsiewhich it does - it builds on top of existing services15:44
dtroyermugsie: I disagree15:44
dhellmannif adjutant was a new service with a well-defined API for handling integration with deployment-specific backends I'd be happy to say that works towards the mission and meets my criteria for adding a project15:44
fungidoes it "provide a cloud infrastructure service" or is it merely glue for arbitrary business logic? how do we define the former?15:44
dhellmannmugsie : "help further" is the part I'm stuck on15:44
dhellmannbecause I'm not convinced that a service that doesn't have a standard API helps15:45
dtroyerdhellmann: ++ (to the well-defined API statement)15:45
mugsiebut in the docs, our (current) version of "help further" is providing or building on top of iaas services15:45
dhellmannmugsie : I think that's an extreme reading of those words.15:46
fungithe sentence there is also phrased misleadingly, in that it implies the two ways to further the mission are by either providing a cloud infrastructure service or directly building on existing ones, and could be further interpreted to mean that if it does either of those things then it is automatically considered to be furthering the mission15:46
TheJuliadhellmann: but we can't use the "ability to" in other projects as a quantifier if it is within or outside of goal posts. I think we need to look at it as a whole from a standpoint of is this generally useful and does it solve a problem in a semi-logical fashion that integrates and builds upon the other components.15:46
dhellmannnot everything that builds on IaaS helps all openstack clouds.15:46
dhellmannTheJulia : sure. I think adjutant will be useful to many deployers. I'm looking at it from a community perspective, and I'm concerned that the lack of scope and lack of interop will not help the community meet it's goals.15:47
fungirecall that we pushed back on gluon's application for official inclusion for similar reasons15:48
mugsiedhellmann: compare this to neutron. neutron also allows per backend API changes, which are non interoperable across deployments15:48
dhellmannand it does seem to sit in a different place than existing services (although I haven't studied every plugin they have) so I'm no longer concerned about perceived overlap15:48
dtroyermugsie: and that is a bug, not a feature15:48
mugsiedtroyer: a bug that we have allowed since the project was started15:49
dhellmannmugsie : yes, and if neutron was applying today I would make the same argument against allowing it in. History being what it is, that wasn't the criteria used when neutron was added.15:49
fungimy understanding is that the neutron team is (slowly) working to fix that issue similar to how nova did a few years back, but are having to fight battles with the various driver authors15:49
dhellmannfungi : yes, that's also my impression15:49
TheJuliadhellmann: and I think that is a fair concern and requires more data to be obtained, at least in my own opinion15:49
dhellmannthe networking space seems particularly combative15:50
fungimugsie: you could consider that as a lesson learned, and a mistake we'd rather not make again15:50
dhellmannTheJulia : sure, data would be good. I'm not saying "no never" I'm saying "not as it is described today"15:50
mugsiefungi: have we ever said that though?15:50
fungiwell, we did say well-defined api15:50
fungiand pushed nova to finally drop extensions, much to the protest of some providers15:51
mugsieor is it internal organisational memory that we don't want it?15:51
fungibut i'll skim our resolutions to see if the tc made any official statement on thatposition in the past15:51
jrollit seems to me that nobody would block adjutant if they did the following: 1) remove the api extension framework. 2) build well-defined APIs with a pluggable backend. 3) (naturally) accept changes and additions to those APIs. should we consider suggesting this path to the adjutant team and see how they feel about it? it seems like it could still solve their problems.15:51
dhellmannmugsie : are you asking if we've ever written down a policy about wanting interop to be a priority?15:52
dtroyerjroll: nice summary ++15:52
dhellmannor something else?15:52
mugsiejroll: yeah, that seems to sum it up15:52
fungimugsie: it seems to me that we have adjusted our documentation about applying for official inclusion to reflect our desire for consistent, interoperable, non-variable apis15:52
fungianother example is the unfortunate situation with the glance "tasks api"15:52
cdentI'd consider blocking because of some of the reasons mnaser mentioned: the layer at which this stuff is pitched is optimal for customizations, a zone where different places will very likely want their own thing15:52
dhellmannjroll : I don't get the idea from Adrian's response to my saying something similar that that approach fits with the team's goals15:53
cdentthat's a zone we want to exist, but not _in_ openstack15:53
dhellmanncdent : that's a fair point15:53
dhellmannI can see some benefit to having a standard way to ask for a password reset or quota change or several of the other examples given in their docs.15:54
jrollcdent: yes, fair. I'm hoping that these problems can be solved behind a consistent API, rather than in the API itself. I could be just dreaming15:54
dhellmannEven if the ultimate implementation of those is very different.15:54
cdentI'd also consider blocking simply because the house is full.15:55
mnaserand again, most of the stuff in adjutant is actual openstack api that exists except a select few.  for example, -- NewProjectAction, NewProjectWithUserAction, AddDefaultUsersToProjectAction is all things you can do by hitting the keystone api.15:55
EmilienMcdent: I'm afraid this statement is not clear for everyone and isn't documented anywhere15:55
ttxWhile I'm sympathetic to the feeling, "the house is full" supposes a zero-sum-game, which it never was15:56
mnaser has NewUserAction, ResetUserPasswordAction (which is actually more like change password), EditUserRolesAction, UpdateUserEmailAction .. all of these are just keystone api calls/requests15:56
cdentSorry, I should rephrase: House of full is loaded. I basically meant: because it's not IaaS15:56
TheJuliaAt the same time, saying "the house is full" prohibits growing the house or adding more rooms to it when it maeks sense.15:56
jrollcdent: also fair - I'm kind of intentionally skipping the higher-level questions because we're bad at trying to answer those when we have a specific instance of those questions in front of us.15:56
dhellmannmnaser : are you saying they are re-implementing keystone features, or that they are using them?15:56
mnaserdhellmann: they are just consuming the openstack api and exposing it in a different way15:57
dhellmannhmm, thanks for pointing that out15:57
jrollcdent: (then again, we struggle with coming back to answer those until there is another instance of the questions, and it's a vicious circle)15:57
mnaserdhellmann: example of new user --
dhellmannI wonder if that's because the existing APIs are "too low level" or what15:57
EmilienMmnaser: thanks, that what I was also trying to point out15:57
dtroyerin that regard (wrapping APIs) it is parallel to oaktree, but without the explicit purpose to further interoperability15:58
ttxright someone mentioned that proposing at as a separate project might also be a run around (more) difficult feature addition in a range of existing projects, which would be sad15:58
mnaserdtroyer: i agree with that15:58
dhellmannbecause I know we needed some logic like that to integrate our backend with horizon at dreamhost15:58
mnaserwell, see i'm confused at why adjutant decided to make itself a service15:59
mnaseri'd think it would be great if it was all within
ttxI mean I understand why you would implement it this way if you need the code in your implementation -- but not sure we should encourage taht approach *within* OpenStack15:59
dhellmannmnaser : my understanding was that they needed a way for users to self-service trigger those operations15:59
dhellmannwithout requiring those users to write all of their own versions of that logic15:59
*** kumarmn has quit IRC15:59
mnaserdhellmann: but those are not self service operations afaik, those are admin ops (i need a new project, etc, let me double check)15:59
mnaserand if these are user facing ops like adding a project, this goes back to pushing the whole issue about admin-ness in keystone and this wouldn't be needed anymore16:00
fungimnaser: so what we've traditionally termed a "proxy api"?16:00
dhellmannmnaser : right, but that's the point. somewhere in the discussion Adrian said they needed to enable users to ask for things that only admins could do. So adjutant lets them do that, and asks an admin to approve, and then does the work16:00
TheJuliamnaser: I think we've forgotten the whole self service nature in this entire discussion16:00
dhellmannso it's a very useful way to provide self-service customer support features, for example16:00
cmurphymnaser: ++16:01
*** kumarmn has joined #openstack-tc16:01
mnaserdhellmann, TheJulia: i see, i may have jumped in a bit late on this16:01
dhellmannfungi : in this case it's not a straight pass-through, though, right? it's like a client with the workflow approval layer on top16:01
fungiahh, sounded like it was directly re-exposing keystone api calls at a different endpoint16:02
dhellmannagain, I think this tool would be *really* useful. But the way it is presented and the stated goals of the team make me reluctant to bring it in.16:02
cmurphybut if keystone had its admin-ness problem fixed then a lot of these workflows wouldn't be necessary16:03
mnaserquotas is the only thing i see that would remain16:04
dhellmannperhaps. there are useful customer service-y features other than changing passwords and quotas.16:04
dhellmannI don't know if adjutant does them, yet, but think about anything you've ever had to ask a cloud admin to do for you and think about what it would look like if there was a standard way (other than email) to trigger those things16:04
TheJuliacmurphy: At that same time, if it did, would it still meet/pass the same information security auditing that it undergoes now in terms of an operator being audited for some sort of contractor or regulatory compliance. I think we need a LOT of more data or we need those who may be impacted by that change to speak up in the discussion because we would then directly impact their ability to consume new versions of openstack16:05
TheJuliaif it no longer meets or exceeds the requirements.16:05
* fungi considers e-mail to be an api, just not a very rest-ish one16:05
dhellmannmy impression was they were trying to build a service to do those things, just not in any sort of standard way16:05
TheJuliafungi: email is very much a human as a service thing.... :)16:06
cmurphyTheJulia: the goal in fixing keystone would be to improve the current security model, not to loosen it16:06
fungiTheJulia: i interact with plenty of systems which take automated commands via e-mail16:07
cmurphyTheJulia: and this is work that is under way, not an "it would be nice" kind of idea16:07
fungi(subscription management in a variety of listservs, debbugs, et cetera... taking structured commands via e-mail and acting on them is a relatively common pattern if you know where to look for it)16:08
TheJuliacmurphy: awesome! except our perception of fixing might not be agreeable to everyone in every situation. At least that is what I'm trying to say.16:08
dhellmannI wonder if keystone's API for adding a user to a project will be the typical low-level thing we tend to build, or the higher level version from that handles creating users that don't exist but supporting existing users, etc.16:09
dhellmannit makes sense to me for keystone to stick with the low level for flexibility, and to allow a higher level service to make things easier -- just like OSC16:10
TheJuliacmurphy: at least, without some collection of knobs, dials, switches, etc that is represented in configuration that can be enforced/tracked via external configuration management/accounting tools.16:11
cmurphydhellmann: yes that workflow would be multiple low level operations in keystone16:11
dhellmannthat's what I thought16:11
cdenta potential question comes out of that: are we in the business of anything other than low-level?16:13
TheJuliacdent: that is perhaps the best question fo the day16:14
TheJuliaof the day16:14
dhellmannit would be disappointing if we took the position that we were limited to low level APIs that *require* more work to be useful16:14
cdentit takes a _lot_ of effort to use a plain openstack16:15
* dhellmann needs lunch16:16
TheJuliait seems like we should be in the business of encouraging things that makes that easier, in the grand scheme of things16:17
dims_so one data point here ... the BOSH/cloudfoundry folks have a cf-openstack-validator that they run to try to figure out of a given endpoint can support running BOSH/CloudFoundry16:17
dims_a typical run looks like this
dims_it's insane!16:17
dims_until they wrote this, they could not tell when/if a given openstack would be able to run their stuff16:18
dims_project is here -
dhellmannthat feels like stuff the interop group would be interested in hearing16:18
* cdent pastes a link to mark16:20
johnthetubaguycdent: +1 your comment, I hit a new empty project on a system I had not accessed before, without get me a network, oh my its hard16:20
dims_mrhillsman and i have been digging up on how BOSH/CF works and uncovered this gem16:20
dims_from a SAP team16:20
clarkbdims_: thats essentially why oscc exists too16:24
clarkbdims_: because as a user its really hard to know particular things about a cloud16:24
mrhillsmanthis is part makes me think rally could possibly be that16:24
clarkbdims_: it is less focused on application specific requirements and instead on communicating certain features being present or not and how to generally interact with cloud (what image format, etc)16:25
mrhillsmanunfortunately i do not know enough about rally but when i did use it before it seemed to have very similar setup and output16:25
fungii thought rally's primary focus was performance testing16:27
fungibut maybe i'm behind the times16:27
cdenti think they branched out to validation and various bits of scenario testing too, and I think I heard some talk of chaos monkey behaviors16:28
mrhillsmanit is for benchmarking yes16:28
mrhillsmanwhat cdent said16:28
clarkbit is interesting that they check your security group rules rather than just setting the rules they need16:29
clarkband require floating IPs which won't work with ipv6 clouds16:29
mrhillsmanyeah, we engaged them to help provide space for them to increase the velocity of the cpi development through openlab16:31
mrhillsmanthey are having a time just having newer versions setup to use so probably just the same with any other configuration/setup16:32
mrhillsmanscrolling back up and reading, does this speak to having healthy SDKs?16:34
mrhillsmanand i could be misusing the term also16:35
dims_clarkb : we have to bring them to newer OpenStack releases too (so OpenLab)16:37
clarkbya I think it is a great thing to have that sort of testing. Just pointing out that this isn't a unique problem and we have some tools out there today to address some of it though they tend to be more about identifying features/functionality rather than any explicit requirements on them16:38
clarkbthis is also why infra relies on so few actual openstack features in production16:39
clarkbbecause you can't count on them existing in most places16:39
*** jpich has quit IRC16:46
dims_ack clarkb ... a bit sad at that16:54
clarkbsome of it is sad, but at the same time I think we've learned you really don't need to have a ton of shiny features to be effective. You do need some fundamental features like boot my own image, get me a public IP for when I need it, and some method to add storage capacity16:57
persiaPersonally, I find the loose coupling to be a good example of the strength of OpenStack.  If features are tightly aligned with infra requirements, it often leads to a single monolithic environment, where anything different fails, which makes it hard for independent organisations to consume.  That OpenStack is consumable without interaction with anyone who is in the channel (or even awareness of the structures that cause this channel to exist)16:59
persiamakes it a sensible choice for many.  Those that consume are then able to gather resources, and those resources often find it more effective to do their work with the rest of us.16:59
*** chandankumar has quit IRC17:10
*** david-lyle has quit IRC17:15
*** dtantsur is now known as dtantsur|afk17:15
*** chkumar246 has joined #openstack-tc17:27
openstackgerritMichael Johnson proposed openstack/governance master: Octavia assert tests-lower-dependency-bounds tag
cdentAnyone care to summarize office hours? I was there the whole time but I'm not sure I can summarize.17:54
*** harlowja has joined #openstack-tc18:01
*** david-lyle has joined #openstack-tc18:05
cdenttc-members I've tried to add a potential forum topic to the etherpad (line 25) for trying to address some of the difficulties from above, but it may need a bit of tweaking, please feel free to do so18:15
smcginniscdent: I think that's a fair enough topic description to get the discussion started.18:22
*** zaneb has quit IRC18:23
*** annabelleB has quit IRC18:29
*** annabelleB has joined #openstack-tc18:45
dhellmanncdent : thanks18:54
pabelangerI have a feeling fungi is going to be happy with the ML very shortly19:10
fungii take it we've gotten a no back on solar19:11
dtroyerfungi: prepare your emoji19:11
* fungi clearly needs to hurry up and get our four-byte utf-8 support for storyboard merged19:12
clarkbI'll need to get a stein into source code pro monospace19:12
* dtroyer s/emoji/unicode code point/ ??19:12
pabelangerfungi: yup, looks like it trademark counsel said it was a high risk (solar)19:13
smcginnisIs refusing to use the word emoji the digital equivalent of yelling at kids to stay off your lawn? :)19:13
fungismcginnis: i think sticking to ascii is the digital equivalent of yelling at kids to stay off your lawn19:13
smcginnisHah, fair enough.19:14
dtroyerhows this:  ||)19:14
fungilooks tasty enough to drink19:14
dtroyer(|| for lefties19:14
* dmsimard raises mug for fungi19:15
fungicould also make one with LP though that looks a bit more like a coffee mug and could also be confused for a bug tracker19:15
smcginnisCheers? (// \\)19:15
cmurphyso in german stein actually means stone not mug
cmurphyso we went from release rocky to release rock19:16
jrollI've always liked cU for a coffee mug19:16
dmsimardcmurphy: so you're saying we should name openstack releases after kind of rocks then19:17
dmsimardor rock adjectives19:17
fungicmurphy: that's awesome!19:17
cmurphydmsimard: i'm saying that seems to be the trend ;)19:17
dmsimardwell I mean OpenStack kind of rocks anyway19:17
cmurphythis is true19:17
fungiwe're rocking releases19:17
dmsimarddoes that make us rock stars ?19:18
dmsimardoh it never ends19:18
fungiso the release's namesake, steinstraße translates as "stone street" i expect19:18
clarkbthis is the second street name we've taken too right?19:19
clarkbicehouse was also a street19:19
smcginnisBetter watch with the puns, you're going to set cdent off. :)19:20
fungithough interestingly, translate.g.o also says the word for english "stein" is also "stein" in deutsche19:21
cdentI was just ready to quit IRC19:21
cdentbut now I can't because it will seem I quit in a huff over puns19:21
dtroyerbut now you can quit because that declaration makes it no so19:21
fungithough bierkrug seems to be the preferred translation of beer stein19:22
cdentthank you dtroyer19:23
*** cdent has quit IRC19:24
dhellmanncmurphy : we need to make sure ttx or jbryce mention that in a keynote19:30
dhellmannor maybe we make you get up on stage and say that in front of everyone ;-)19:32
* cmurphy hides19:35
cmurphymy face is already on the landing page for the summit for some reason >.<19:36
smcginniscmurphy: Then you definitely are a rock star. :)19:36
* dhellmann groans19:39
fungicmurphy: i love the way that your speaker photo makes it unclear whether you'll be presenting, or whether there will be an 18-inch replica stonehenge on stage (a la spinal tap)19:42
cmurphycould be both19:46
dhellmannwell now we *have* to get you up on stage to talk about "stein"19:52
clarkbI really want beer steins as swag now19:55
smcginnisThat better be a no brainer, or else a lot of marketing people need a stern talking to.19:55
*** kumarmn_ has joined #openstack-tc20:25
*** kumarmn has quit IRC20:28
*** zaneb has joined #openstack-tc20:50
* fungi is just waiting for the "stackenstein" jokes to start rolling in21:13
*** zaneb has quit IRC21:13
*** annabelleB has quit IRC21:40
*** annabelleB has joined #openstack-tc21:50
*** kumarmn_ has quit IRC22:01
*** kumarmn has joined #openstack-tc22:19
*** kumarmn has quit IRC22:24
*** hongbin has quit IRC22:34
openstackgerritTony Breeds proposed openstack/project-team-guide master: Update Stable policy for Extended Maintenance
*** gagehugo has left #openstack-tc22:40
*** zaneb has joined #openstack-tc23:18
*** kumarmn has joined #openstack-tc23:21
*** kumarmn has quit IRC23:32
*** jroll has quit IRC23:37

Generated by 2.15.3 by Marius Gedminas - find it at!