| *** annabelleB has quit IRC | 00:02 | |
| *** zhipeng has joined #openstack-tc | 01:19 | |
| *** kumarmn has joined #openstack-tc | 01:21 | |
| *** annabelleB has joined #openstack-tc | 01:25 | |
| *** kumarmn has quit IRC | 01:27 | |
| *** annabelleB has quit IRC | 01:33 | |
| *** annabelleB has joined #openstack-tc | 01:59 | |
| *** annabelleB has quit IRC | 02:07 | |
| *** kumarmn has joined #openstack-tc | 02:33 | |
| *** zhipeng has quit IRC | 03:06 | |
| *** kumarmn has quit IRC | 03:21 | |
| *** annabelleB has joined #openstack-tc | 03:23 | |
| *** harlowja has quit IRC | 03:24 | |
| *** annabelleB has quit IRC | 03:39 | |
| *** ianychoi__ has joined #openstack-tc | 03:47 | |
| *** ianychoi_ has quit IRC | 03:50 | |
| *** harlowja has joined #openstack-tc | 03:59 | |
| *** dklyle has quit IRC | 04:26 | |
| *** ianychoi__ is now known as ianychoi | 04:29 | |
| *** harlowja has quit IRC | 06:06 | |
| *** chandankumar has quit IRC | 07:04 | |
| *** chandankumar has joined #openstack-tc | 07:09 | |
| *** jpich has joined #openstack-tc | 07:49 | |
| *** cdent has joined #openstack-tc | 08:22 | |
| *** dtantsur|afk is now known as dtantsur | 10:55 | |
| dims_ | o/ | 12:22 |
|---|---|---|
| cdent | o/ | 12:23 |
| ttx | Looks like we are 99% set on Sept 10 week for next PTG (in North America) | 12:39 |
| ttx | Can't remember who asked | 12:39 |
| persia | \o/ | 12:39 |
| cdent | we've had a few different people come in here and ask over the past few days | 12:43 |
| cdent | is 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-tc | 12:55 | |
| cdent | we should meet in my back yard, I'll do the foundation a deal | 12:55 |
| cdent | http://beachubator.org/ | 12:55 |
| persia | I 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-tc | 12:58 | |
| cdent | airport (reachable from london, manchester and dublin) is 30 minute walk from that beach | 12:58 |
| jroll | cdent: +1000 | 12:59 |
| cdent | I'm sure flaper87 will go for it | 12:59 |
| ttx | No, location can't be confirmed right now, beyond "in North America" | 13:02 |
| dhellmann | we have beaches here, too | 13:04 |
| persia | beaches 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 | |
| persia | I have been to beaches with good power, but not every beach is well wired. | 13:05 |
| dhellmann | cdent : oh, yes, I did overlook that aspect of the plan | 13:06 |
| * jroll would also support fungi's back yard | 13:06 | |
| *** mriedem has joined #openstack-tc | 13:10 | |
| *** zhipeng has joined #openstack-tc | 13:16 | |
| dhellmann | even if we're not at a beach, we should make the theme of the next ptg "the beach" | 13:17 |
| zhipeng | would be great to swing by laguna beach or huntington beach :P | 13:23 |
| *** hongbin has joined #openstack-tc | 13:49 | |
| smcginnis | +1 for letting cdent stay home. | 13:51 |
| dtroyer | dhellmann: I'm not sure I want the tag #sandystack to be a thing | 14:02 |
| smcginnis | As long as it's not s/st/cr/ | 14:09 |
| fungi | jroll: you're welcome to come to my backyard any time you like | 14:20 |
| fungi | either chill on my dock, or it's a 15-minute walk across the island to the ocean side | 14:20 |
| fungi | _getting_ here is the real challenge | 14:21 |
| jroll | fungi: I will gladly take you up on that one day :) | 14:21 |
| jroll | the drive from here isn't terrible, I've done it before | 14:21 |
| fungi | cool, lmk and as long as i'm not away for a trip i'm happy to have people | 14:23 |
| jroll | <3 | 14:23 |
| * cdent hires a boat | 14:23 | |
| fungi | cdent: it would be a lengthy trip by boat from you, but might be fun to try | 14:24 |
| cdent | exactly | 14:24 |
| fungi | in a cabin cruiser large enough to not get swamped on the open ocean, you're probably looking at a few weeks minimum | 14:24 |
| fungi | just 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 stripes | 14:26 |
| fungi | but beware the shoals, they've claimed many a seafaring vessel over the centuries | 14:26 |
| * cdent takes a clipper | 14:28 | |
| mugsie | PTG on a boat? :D | 14:29 |
| dtroyer | now there's an idea! | 14:30 |
| smcginnis | Hey, they used to do the perl conferences on cruise ships, right? | 14:32 |
| SamYaple | i vote boat | 14:36 |
| * SamYaple goes to start some rumors | 14:36 | |
| dims_ | hahaha ... nooooooooooo! | 14:36 |
| dims_ | i vote for cdent's backyard/beach | 14:37 |
| cdent | if it is in international waters that helps with some of the visa problems | 14:38 |
| SamYaple | and we get to fight pirates! | 14:38 |
| mugsie | just need to charter a helicopter to shuttle people back and forth :D | 14:38 |
| * smcginnis is surprised no one has suggested a container ship :) | 14:39 | |
| cdent | smcginnis: you should be totally ashamed of yourself. The punning you've done lately... well... | 14:40 |
| smcginnis | cdent: You pretend like you don't think I'm funny, but I know it's just a front. :P | 14:41 |
| cdent | :D | 14:41 |
| TheJulia | SamYaple: Excellent positive point to a boat! | 14:43 |
| TheJulia | smcginnis: I can confirm, I laughed | 14:44 |
| SamYaple | TheJulia: im picturing swords and scurvy everywhere | 14:44 |
| smcginnis | TheJulia: :) | 14:44 |
| TheJulia | I'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 |
| smcginnis | SamYaple: I've hear rum is good for scurvy. We can ration out grog. | 14:45 |
| mugsie | TheJulia: now thats an idea :D | 14:45 |
| TheJulia | Then, as cat staff, the cats would be unhappy and would need to come along. | 14:45 |
| *** david-lyle has joined #openstack-tc | 14:45 | |
| SamYaple | i see nothing wrong with this | 14:46 |
| mugsie | my dogs may not like it, but we shall see | 14:48 |
| *** zhipeng has quit IRC | 14:49 | |
| *** annabelleB has joined #openstack-tc | 14:51 | |
| fungi | tc-members: office hour? | 15:00 |
| ttx | indeed | 15:00 |
| cdent | hello | 15:00 |
| smcginnis | Howdy | 15:00 |
| dtroyer | o/ | 15:00 |
| EmilienM | hi | 15:00 |
| pabelanger | present | 15:00 |
| dims_ | yo | 15:01 |
| fungi | smcginnis: i believe rum/grog is only good for scurvy if you add lemons or limes... maybe stick to mojitos? | 15:01 |
| smcginnis | That works. | 15:01 |
| *** annabelleB has quit IRC | 15:02 | |
| TheJulia | o/ | 15:02 |
| TheJulia | so mojitos replace??? | 15:02 |
| fungi | mojitos are merely a convenient means of combining limes with rum | 15:03 |
| TheJulia | I guess that makes sense, mint being a plus | 15:04 |
| fungi | the little umbrella is also useful to keep it from getting diluted if it starts to rain | 15:04 |
| ttx | cdent 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 ICYMI | 15:04 |
| smcginnis | Both comments had some very good points. | 15:05 |
| cdent | those were good answers ttx, but as you note, some of the harder deeper questions are left open | 15:05 |
| smcginnis | I 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-tc | 15:06 | |
| smcginnis | s/on/own/ | 15:06 |
| mugsie | I 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 |
| mugsie | but I can see the microAPI having issues | 15:06 |
| smcginnis | That's my dilemma. It both helps interop and has huge potential to hurt it. | 15:07 |
| cmurphy | o/ | 15:08 |
| mugsie | and, if clouds are doing this internally anyway, does it actually impact interop? | 15:08 |
| dtroyer | If 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 concerns | 15:08 |
| smcginnis | mugsie: That's kind of where I keep going back to. | 15:08 |
| smcginnis | I would assume all public clouds are doing something like this. | 15:08 |
| mugsie | but it does set a "we think you should be able to extend APIs via plugin code" precent | 15:08 |
| smcginnis | So this at least makes it done in a somewhat consistent way. | 15:08 |
| dtroyer | it does affect it as the examples that keep being used are consumer-facing | 15:08 |
| smcginnis | I 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 |
| smcginnis | A little more concerning if it is a consumer accessible API. | 15:09 |
| mugsie | dtroyer: sure, but that stuff is already non interoperable, as each cloud has a different system for it | 15:10 |
| fungi | i 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 backends | 15:10 |
| EmilienM | mnaser: hey, if you around, do you have something like Adjutant in your public cloud? | 15:11 |
| mugsie | the hope would be as more things get added to the core of adjunct the tasks on each cloud would become eventually consistant | 15:11 |
| cdent | EmilienM: good idea. less speculation, more data. | 15:11 |
| dtroyer | mugsie: 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 reason | 15:11 |
| mnaser | EmilienM: our own little tooling, not adjutant itself, but we really have two operations | 15:12 |
| mnaser | create user in keystone, delete user in keystone (and purge resources) | 15:12 |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Official projects should not keep tagging rights https://review.openstack.org/557737 | 15:12 |
| EmilienM | mnaser: thanks for confirming that there is a need of something on that regard | 15:13 |
| smcginnis | mugsie: I guess I could live with eventual consistency. | 15:13 |
| EmilienM | mnaser: how do you deal with password reset for example? | 15:13 |
| ttx | smcginnis: dhellmann ^ that is what we just discussed in #openstack-release | 15:13 |
| EmilienM | mnaser: if any question is too confidential you can just tell me :D | 15:13 |
| smcginnis | ttx: ack | 15:13 |
| mnaser | EmilienM: our openstack credentials are not tied into our customer 'billing' credential. our billing system is a different setup and set of credentials | 15:13 |
| fungi | dtroyer: 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 |
| EmilienM | cdent: yes I think we need to collect data before speculating what the community needs | 15:13 |
| mnaser | EmilienM: no problem, once you sign up, you get openstack credentials and that's all the billing system does (provision accounts) | 15:14 |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Official projects should not keep tagging rights https://review.openstack.org/557737 | 15:14 |
| EmilienM | mnaser: oh I see, like an ldap or something external. | 15:14 |
| EmilienM | so when the users change their password, the system deals with another API but OpenStack, iiuc | 15:14 |
| ttx | now with depends-on / needed-by | 15:14 |
| dtroyer | fungi: except that this appears to _also_ be for consumer-facing APIs. am I wrong about that? I haven't seen a clear statement anywhere | 15:15 |
| fungi | dtroyer: yeah, i expect we need more clarity on that front | 15:15 |
| mnaser | EmilienM: 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 billing | 15:15 |
| cdent | oh totally jinx in gerrit review by mugsie | 15:15 |
| dtroyer | if 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 that | 15:15 |
| EmilienM | to me, (and I'm probably wrong), but I currently think that Adjutant is adding features that are missing in some services/APIs | 15:16 |
| mugsie | cdent: :) | 15:16 |
| mugsie | and thanks to smcginnis for the ultra quick clarification :) | 15:16 |
| smcginnis | ;) | 15:16 |
| smcginnis | EmilienM: So you think keystone should have account create and password reset APIs? | 15:17 |
| EmilienM | yes | 15:17 |
| cdent | hmmm. clearly the release management team is trying to take away my guns | 15:17 |
| EmilienM | that's exactly what I think, thanks for putting words on it | 15:17 |
| mugsie | smcginnis: for sql based domains, yes | 15:17 |
| EmilienM | and same for quotas | 15:17 |
| smcginnis | cdent: Hah | 15:17 |
| dtroyer | EmilienM: 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 concern | 15:17 |
| * dhellmann slips into the back of the room late | 15:17 | |
| pabelanger | smcginnis: I think it should, especially if it wants to be used as a stand alone service | 15:17 |
| mnaser | i'd personally disagree and prefer that stuff stays outside the openstack world because then it starts to tie into business workflows | 15:18 |
| smcginnis | "business workflows" is a good term for what I was thinking. | 15:18 |
| EmilienM | take this code: https://github.com/openstack/adjutant/blob/master/adjutant/actions/v1/users.py#L372-L434 | 15:18 |
| pabelanger | smcginnis: +1 | 15:18 |
| smcginnis | There are some operations that seem better done _on_ OpenStack rather than _in_ OpenStack. | 15:18 |
| EmilienM | don't you think this could reside in Keystone? | 15:18 |
| cdent | smcginnis: very true, and of courese that begs: where's the boundary (to bring it back to that common q) | 15:19 |
| mnaser | EmilienM: 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 this | 15:19 |
| EmilienM | cdent: exactly, there is a boundary here. | 15:19 |
| mnaser | and i don't think it would have been an issue to merge it | 15:19 |
| *** gagehugo has joined #openstack-tc | 15:19 | |
| pabelanger | EmilienM: I always seen something like that happening in horizon, if it was broken out into a front-end just for keystone | 15:20 |
| pabelanger | but that's just me | 15:20 |
| cmurphy | it's a little tricky because email isn't a real attribute for keystone users | 15:20 |
| mnaser | ^ yeah that too, we don't even use it | 15:20 |
| cmurphy | so there would be some policy problems for users updating their own emails | 15:20 |
| mnaser | and you can edit a tenant from horizon | 15:20 |
| mnaser | and make that change | 15:20 |
| cmurphy | but it wouldn't be impossible | 15:20 |
| mnaser | (i think? let me double check.) | 15:20 |
| ttx | If Adjutant was more around a clear set of functions, and less of a micro-API factory, that would ease my concerns | 15:21 |
| cmurphy | password reset would also be a little weird | 15:21 |
| cmurphy | but probably doable | 15:21 |
| EmilienM | cmurphy: why would it be weird? | 15:22 |
| cdent | which is interesting, ttx, because many other things we create are abstractions that are factories of stuff used to create something that's actually workable | 15:22 |
| ttx | (even if the same code could be reused to build other micro-APIs) | 15:22 |
| cdent | few people want to use openstack _directly_ | 15:22 |
| cmurphy | EmilienM: if i click the "i forgot my password" button it usually sends me an email with a link | 15:22 |
| cdent | but plenty of tools want to talk to openstack | 15:22 |
| cmurphy | so, keystone would have to know how to send an email | 15:22 |
| cmurphy | and something needs a web frontend for the user to click on | 15:23 |
| mnaser | cmurphy, 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 thing | 15:23 |
| mnaser | i can imagine a private cloud preferring that password resets go through their own procedure/process | 15:23 |
| ttx | I guess I'm concerned about the return of custom extensions | 15:24 |
| cmurphy | EmilienM: 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 workflows | 15:24 |
| EmilienM | cmurphy: I was more thinking at keystone being about to reset a (random) password and that's it | 15:24 |
| TheJulia | From 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 |
| EmilienM | being able* | 15:24 |
| fungi | cmurphy: 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 |
| cmurphy | fungi: ++ | 15:25 |
| fungi | so sort of hard to generalize that as a feature of the keystone api | 15: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 openstack | 15:25 |
| smcginnis | I 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 |
| TheJulia | dhellmann: or perhaps encourage very clear delineation somehow? | 15:26 |
| mnaser | as 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 something | 15:26 |
| dhellmann | I'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 scope | 15:26 |
| dhellmann | TheJulia : maybe. how do you see that working? | 15:26 |
| TheJulia | mnaser: +1 | 15:26 |
| smcginnis | So as long as they still support that minimum, does it matter _that_ much if someone adds some special sauce? | 15:26 |
| pabelanger | EmilienM: cmurphy: FWIW: here is how I did forgot password in horizon years ago: https://github.com/kickstandproject/wildcard/commit/880c123010c7214602decee747eecfd32b9a1782 can't remember what version of keystone / horizon that was | 15:27 |
| mnaser | dhellmann: 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 identity | 15:27 |
| dtroyer | smcginnis: and that is a subset of the stuff actually required to interact with a cloud. way too small a subset imho | 15:27 |
| pabelanger | EmilienM: cmurphy: never got around to doing password reset due to emailing of URL stuff | 15:27 |
| dhellmann | smcginnis : 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 |
| smcginnis | dtroyer: It is small, but even with vanilla OpenStack and all the config options, it's the base set of expected functionality. | 15:28 |
| dhellmann | mnaser : right | 15:28 |
| pabelanger | always thought we could support something like that for horizon | 15:28 |
| dtroyer | smcginnis: so should we encourage exteing the non-covered parts supplied by OpenStack project? | 15:28 |
| TheJulia | dhellmann: 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 |
| TheJulia | In 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 moment | 15:28 |
| smcginnis | dhellmann: "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 |
| smcginnis | dtroyer: I wouldn't say "encourage", but I don't think "prevent". | 15:29 |
| dhellmann | smcginnis : as long as it's possible to use the cloud in standard ways without interacting with the non-standard APIs | 15:29 |
| mnaser | i'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 |
| smcginnis | dhellmann: ++ | 15:29 |
| dhellmann | I think the "workflow" thing is really an implementation detail that is confusing the discussion. | 15:30 |
| mnaser | it'll give them the flexibility of being able to commit things quickly and not rely on the upstream for every single project.. | 15:30 |
| TheJulia | mnaser: except, given other projects capacity... can it really be taken on, or are you suggesting something not under those projects stewardship? | 15:30 |
| EmilienM | mnaser: in your proposal I see an eventual collaboration issue | 15:31 |
| dhellmann | mnaser : that sounds an awful lot like the system we had early in OpenStack's life and that we've been trying to move away from | 15:31 |
| dtroyer | mnaser: that sounds like forcing API extension back in to each API. | 15:31 |
| EmilienM | mnaser: like "Adjutant being a shortcut to implement my api stuff" | 15:31 |
| mnaser | TheJulia: 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 want | 15:31 |
| fungi | is 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 |
| mnaser | right, 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 |
| dhellmann | fungi : 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 ones | 15:32 |
| dhellmann | mnaser : 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 goal | 15:33 |
| mnaser | also, adjutant is all done by a single company right now, so it's important to keep that in mind | 15:34 |
| smcginnis | I 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 |
| smcginnis | *there's | 15:34 |
| EmilienM | unfortunately, a lot of new projects are made by a single company | 15:35 |
| * TheJulia begins to wonder if we're too focused on the low level details as programmers trying to solve problems | 15:35 | |
| cmurphy | mnaser: is your point that their business workflows differ from everyone else's? or just that single vendor is not great? | 15:35 |
| cdent | TheJulia++ | 15:35 |
| dims_ | y probably TheJulia | 15:35 |
| EmilienM | (don't mention that some current projects are also single company :)) | 15:35 |
| cmurphy | EmilienM: s/new projects/projects | 15:35 |
| EmilienM | yeah | 15:35 |
| * EmilienM hides | 15:35 | |
| smcginnis | :) | 15:35 |
| dhellmann | smcginnis : 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 |
| TheJulia | cdent: dims_: then perhaps a step back? and maybe go back to smcginnis's point at the beginning as to more clear guidelines? | 15:36 |
| smcginnis | dhellmann: Participating in the ops midcycles, I'm maybe somewhat optimistic, but I could see it happening. | 15:36 |
| dhellmann | TheJulia : that's why I tried to steer us away from the "workflow" thing back onto "what is the adjutant trying to do?" | 15:36 |
| mugsie | my money would be 50 different APIs, unless adjunct added a default one | 15:36 |
| dtroyer | dhellmann: 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 |
| cdent | What about this for a (strawman) metric: If it's not easy to decide, the answer is "no"? | 15:36 |
| dhellmann | cdent : that's more or less my default, and is in line with our typical consensus approach | 15:37 |
| mnaser | cmurphy: 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 operators | 15:37 |
| smcginnis | cdent: I think that may be true in many of the cases, but not always. | 15:37 |
| EmilienM | dhellmann: only zillions? :-O | 15:37 |
| dhellmann | EmilienM : heh | 15:37 |
| TheJulia | dhellmann: 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 |
| EmilienM | cdent: sure but before saying "no" we should maybe revisit our vision and prepare a common message | 15:38 |
| dtroyer | EmilienM: then we should do that before saying yes too | 15:38 |
| EmilienM | we should revisit our vision anyway :-) many things have changed | 15:39 |
| TheJulia | cdent: 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 |
| mnaser | I 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 |
| TheJulia | EmilienM: very good point | 15:39 |
| cdent | Interesting, I had kind of assumed the default position was closer to yes, because we seem to have a lot of official projects? | 15:40 |
| mugsie | as 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 apply | 15:40 |
| cdent | +1 to revisit vision whatever happens | 15:40 |
| dtroyer | mnaser: 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 madness | 15:40 |
| cmurphy | mugsie: ++ | 15:40 |
| TheJulia | mugsie: agreed | 15:40 |
| cmurphy | cdent: i think as mugsie pointed out, the default position has shifted over the years | 15:40 |
| mugsie | and if every couple of project applications get us to the "what is openstack" question, we need to have a good answer. | 15:41 |
| dhellmann | mugsie : 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 change | 15:42 |
| mugsie | dhellmann: on the face of it, yes. they meet the documented requirements. | 15:42 |
| dhellmann | In 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 |
| TheJulia | dhellmann: 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 |
| mugsie | dtroyer: we have never answered it properly | 15:42 |
| dhellmann | mugsie: it's not clear the tool serves the mission, and I think that's the point we're trying to answer | 15:43 |
| dhellmann | at least it's not clear to me | 15:43 |
| dhellmann | TheJulia : I don't think we should be worried about implementing the features in other projects necessarily | 15:43 |
| mugsie | dhellmann: 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 |
| mugsie | which it does - it builds on top of existing services | 15:44 |
| dtroyer | mugsie: I disagree | 15:44 |
| dhellmann | if 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 project | 15:44 |
| fungi | does it "provide a cloud infrastructure service" or is it merely glue for arbitrary business logic? how do we define the former? | 15:44 |
| dhellmann | mugsie : "help further" is the part I'm stuck on | 15:44 |
| dhellmann | because I'm not convinced that a service that doesn't have a standard API helps | 15:45 |
| dtroyer | dhellmann: ++ (to the well-defined API statement) | 15:45 |
| mugsie | but in the docs, our (current) version of "help further" is providing or building on top of iaas services | 15:45 |
| dhellmann | mugsie : I think that's an extreme reading of those words. | 15:46 |
| fungi | the 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 mission | 15:46 |
| TheJulia | dhellmann: 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 |
| dhellmann | not everything that builds on IaaS helps all openstack clouds. | 15:46 |
| dhellmann | TheJulia : 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 |
| fungi | recall that we pushed back on gluon's application for official inclusion for similar reasons | 15:48 |
| mugsie | dhellmann: compare this to neutron. neutron also allows per backend API changes, which are non interoperable across deployments | 15:48 |
| dhellmann | and 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 overlap | 15:48 |
| dtroyer | mugsie: and that is a bug, not a feature | 15:48 |
| mugsie | dtroyer: a bug that we have allowed since the project was started | 15:49 |
| dhellmann | mugsie : 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 |
| fungi | my 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 authors | 15:49 |
| dhellmann | fungi : yes, that's also my impression | 15:49 |
| TheJulia | dhellmann: and I think that is a fair concern and requires more data to be obtained, at least in my own opinion | 15:49 |
| dhellmann | the networking space seems particularly combative | 15:50 |
| fungi | mugsie: you could consider that as a lesson learned, and a mistake we'd rather not make again | 15:50 |
| dhellmann | TheJulia : sure, data would be good. I'm not saying "no never" I'm saying "not as it is described today" | 15:50 |
| mugsie | fungi: have we ever said that though? | 15:50 |
| fungi | well, we did say well-defined api | 15:50 |
| fungi | and pushed nova to finally drop extensions, much to the protest of some providers | 15:51 |
| mugsie | or is it internal organisational memory that we don't want it? | 15:51 |
| fungi | but i'll skim our resolutions to see if the tc made any official statement on thatposition in the past | 15:51 |
| jroll | it 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 |
| dhellmann | mugsie : are you asking if we've ever written down a policy about wanting interop to be a priority? | 15:52 |
| dtroyer | jroll: nice summary ++ | 15:52 |
| dhellmann | or something else? | 15:52 |
| mugsie | jroll: yeah, that seems to sum it up | 15:52 |
| fungi | mugsie: it seems to me that we have adjusted our documentation about applying for official inclusion to reflect our desire for consistent, interoperable, non-variable apis | 15:52 |
| fungi | another example is the unfortunate situation with the glance "tasks api" | 15:52 |
| cdent | I'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 thing | 15:52 |
| dhellmann | jroll : I don't get the idea from Adrian's response to my saying something similar that that approach fits with the team's goals | 15:53 |
| cdent | that's a zone we want to exist, but not _in_ openstack | 15:53 |
| dhellmann | cdent : that's a fair point | 15:53 |
| dhellmann | I 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 |
| jroll | cdent: 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 dreaming | 15:54 |
| dhellmann | Even if the ultimate implementation of those is very different. | 15:54 |
| cdent | I'd also consider blocking simply because the house is full. | 15:55 |
| mnaser | and again, most of the stuff in adjutant is actual openstack api that exists except a select few. for example, https://github.com/openstack/adjutant/blob/master/adjutant/actions/v1/projects.py -- NewProjectAction, NewProjectWithUserAction, AddDefaultUsersToProjectAction is all things you can do by hitting the keystone api. | 15:55 |
| EmilienM | cdent: I'm afraid this statement is not clear for everyone and isn't documented anywhere | 15:55 |
| ttx | While I'm sympathetic to the feeling, "the house is full" supposes a zero-sum-game, which it never was | 15:56 |
| mnaser | https://github.com/openstack/adjutant/blob/master/adjutant/actions/v1/users.py has NewUserAction, ResetUserPasswordAction (which is actually more like change password), EditUserRolesAction, UpdateUserEmailAction .. all of these are just keystone api calls/requests | 15:56 |
| cdent | Sorry, I should rephrase: House of full is loaded. I basically meant: because it's not IaaS | 15:56 |
| TheJulia | At the same time, saying "the house is full" prohibits growing the house or adding more rooms to it when it maeks sense. | 15:56 |
| jroll | cdent: 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 |
| dhellmann | mnaser : are you saying they are re-implementing keystone features, or that they are using them? | 15:56 |
| mnaser | dhellmann: they are just consuming the openstack api and exposing it in a different way | 15:57 |
| dhellmann | hmm, thanks for pointing that out | 15:57 |
| jroll | cdent: (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 |
| mnaser | dhellmann: example of new user -- https://github.com/openstack/adjutant/blob/master/adjutant/actions/v1/users.py#L23-L154 | 15:57 |
| dhellmann | I wonder if that's because the existing APIs are "too low level" or what | 15:57 |
| EmilienM | mnaser: thanks, that what I was also trying to point out | 15:57 |
| dtroyer | in that regard (wrapping APIs) it is parallel to oaktree, but without the explicit purpose to further interoperability | 15:58 |
| ttx | right 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 sad | 15:58 |
| mnaser | dtroyer: i agree with that | 15:58 |
| dhellmann | because I know we needed some logic like that to integrate our backend with horizon at dreamhost | 15:58 |
| mnaser | well, see i'm confused at why adjutant decided to make itself a service | 15:59 |
| mnaser | i'd think it would be great if it was all within https://github.com/openstack/adjutant-ui | 15:59 |
| ttx | I 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* OpenStack | 15:59 |
| dhellmann | mnaser : my understanding was that they needed a way for users to self-service trigger those operations | 15:59 |
| dhellmann | without requiring those users to write all of their own versions of that logic | 15:59 |
| *** kumarmn has quit IRC | 15:59 | |
| mnaser | dhellmann: but those are not self service operations afaik, those are admin ops (i need a new project, etc, let me double check) | 15:59 |
| mnaser | and 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 anymore | 16:00 |
| fungi | mnaser: so what we've traditionally termed a "proxy api"? | 16:00 |
| dhellmann | mnaser : 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 work | 16:00 |
| TheJulia | mnaser: I think we've forgotten the whole self service nature in this entire discussion | 16:00 |
| dhellmann | so it's a very useful way to provide self-service customer support features, for example | 16:00 |
| cmurphy | mnaser: ++ | 16:01 |
| *** kumarmn has joined #openstack-tc | 16:01 | |
| mnaser | dhellmann, TheJulia: i see, i may have jumped in a bit late on this | 16:01 |
| dhellmann | fungi : in this case it's not a straight pass-through, though, right? it's like a client with the workflow approval layer on top | 16:01 |
| fungi | ahh, sounded like it was directly re-exposing keystone api calls at a different endpoint | 16:02 |
| dhellmann | again, 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 |
| cmurphy | but if keystone had its admin-ness problem fixed then a lot of these workflows wouldn't be necessary | 16:03 |
| mnaser | quotas is the only thing i see that would remain | 16:04 |
| dhellmann | perhaps. there are useful customer service-y features other than changing passwords and quotas. | 16:04 |
| dhellmann | I 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 things | 16:04 |
| TheJulia | cmurphy: 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 openstack | 16:05 |
| TheJulia | if it no longer meets or exceeds the requirements. | 16:05 |
| * fungi considers e-mail to be an api, just not a very rest-ish one | 16:05 | |
| dhellmann | my impression was they were trying to build a service to do those things, just not in any sort of standard way | 16:05 |
| TheJulia | fungi: email is very much a human as a service thing.... :) | 16:06 |
| cmurphy | TheJulia: the goal in fixing keystone would be to improve the current security model, not to loosen it | 16:06 |
| fungi | TheJulia: i interact with plenty of systems which take automated commands via e-mail | 16:07 |
| cmurphy | TheJulia: and this is work that is under way, not an "it would be nice" kind of idea | 16: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 |
| TheJulia | cmurphy: 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 |
| dhellmann | I 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 https://github.com/openstack/adjutant/blob/master/adjutant/actions/v1/users.py#L23-L154 that handles creating users that don't exist but supporting existing users, etc. | 16:09 |
| dhellmann | it 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 OSC | 16:10 |
| TheJulia | cmurphy: 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 |
| cmurphy | dhellmann: yes that workflow would be multiple low level operations in keystone | 16:11 |
| dhellmann | that's what I thought | 16:11 |
| cdent | a potential question comes out of that: are we in the business of anything other than low-level? | 16:13 |
| TheJulia | cdent: that is perhaps the best question fo the day | 16:14 |
| TheJulia | of the day | 16:14 |
| dhellmann | it would be disappointing if we took the position that we were limited to low level APIs that *require* more work to be useful | 16:14 |
| cdent | it takes a _lot_ of effort to use a plain openstack | 16:15 |
| dhellmann | indeed | 16:15 |
| * dhellmann needs lunch | 16:16 | |
| TheJulia | it seems like we should be in the business of encouraging things that makes that easier, in the grand scheme of things | 16: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/CloudFoundry | 16:17 |
| dims_ | a typical run looks like this http://paste.openstack.org/show/716654/ | 16:17 |
| 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 stuff | 16:18 |
| dims_ | project is here - https://github.com/cloudfoundry-incubator/cf-openstack-validator | 16:18 |
| dhellmann | wow | 16:18 |
| dhellmann | that feels like stuff the interop group would be interested in hearing | 16:18 |
| dims_ | ++ | 16:19 |
| TheJulia | wow.... | 16:19 |
| * cdent pastes a link to mark | 16:20 | |
| johnthetubaguy | cdent: +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 hard | 16:20 |
| dims_ | mrhillsman and i have been digging up on how BOSH/CF works and uncovered this gem | 16:20 |
| dims_ | from a SAP team | 16:20 |
| mrhillsman | ++ | 16:22 |
| clarkb | dims_: thats essentially why oscc exists too | 16:24 |
| clarkb | dims_: because as a user its really hard to know particular things about a cloud | 16:24 |
| mrhillsman | this is part makes me think rally could possibly be that | 16:24 |
| mrhillsman | s/is/in | 16:24 |
| clarkb | dims_: 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 |
| mrhillsman | unfortunately i do not know enough about rally but when i did use it before it seemed to have very similar setup and output | 16:25 |
| fungi | i thought rally's primary focus was performance testing | 16:27 |
| fungi | but maybe i'm behind the times | 16:27 |
| cdent | i think they branched out to validation and various bits of scenario testing too, and I think I heard some talk of chaos monkey behaviors | 16:28 |
| mrhillsman | it is for benchmarking yes | 16:28 |
| mrhillsman | what cdent said | 16:28 |
| clarkb | it is interesting that they check your security group rules rather than just setting the rules they need | 16:29 |
| clarkb | and require floating IPs which won't work with ipv6 clouds | 16:29 |
| mrhillsman | yeah, we engaged them to help provide space for them to increase the velocity of the cpi development through openlab | 16:31 |
| mrhillsman | they are having a time just having newer versions setup to use so probably just the same with any other configuration/setup | 16:32 |
| mrhillsman | scrolling back up and reading, does this speak to having healthy SDKs? | 16:34 |
| mrhillsman | and i could be misusing the term also | 16:35 |
| dims_ | clarkb : we have to bring them to newer OpenStack releases too (so OpenLab) | 16:37 |
| clarkb | ya 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 them | 16:38 |
| clarkb | this is also why infra relies on so few actual openstack features in production | 16:39 |
| clarkb | because you can't count on them existing in most places | 16:39 |
| *** jpich has quit IRC | 16:46 | |
| dims_ | ack clarkb ... a bit sad at that | 16:54 |
| clarkb | some 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 capacity | 16:57 |
| persia | Personally, 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 |
| persia | makes 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 IRC | 17:10 | |
| *** david-lyle has quit IRC | 17:15 | |
| *** dtantsur is now known as dtantsur|afk | 17:15 | |
| *** chkumar246 has joined #openstack-tc | 17:27 | |
| openstackgerrit | Michael Johnson proposed openstack/governance master: Octavia assert tests-lower-dependency-bounds tag https://review.openstack.org/557785 | 17:52 |
| cdent | Anyone 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-tc | 18:01 | |
| *** david-lyle has joined #openstack-tc | 18:05 | |
| cdent | tc-members I've tried to add a potential forum topic to the etherpad https://etherpad.openstack.org/p/YVR-forum-TC-sessions (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 so | 18:15 |
| smcginnis | cdent: I think that's a fair enough topic description to get the discussion started. | 18:22 |
| *** zaneb has quit IRC | 18:23 | |
| cdent | roger | 18:23 |
| *** annabelleB has quit IRC | 18:29 | |
| *** annabelleB has joined #openstack-tc | 18:45 | |
| dhellmann | cdent : thanks | 18:54 |
| pabelanger | I have a feeling fungi is going to be happy with the ML very shortly | 19:10 |
| fungi | i take it we've gotten a no back on solar | 19:11 |
| dtroyer | fungi: prepare your emoji | 19:11 |
| * fungi clearly needs to hurry up and get our four-byte utf-8 support for storyboard merged | 19:12 | |
| clarkb | I'll need to get a stein into source code pro monospace | 19:12 |
| * dtroyer s/emoji/unicode code point/ ?? | 19:12 | |
| pabelanger | fungi: yup, looks like it trademark counsel said it was a high risk (solar) | 19:13 |
| smcginnis | Is refusing to use the word emoji the digital equivalent of yelling at kids to stay off your lawn? :) | 19:13 |
| fungi | smcginnis: i think sticking to ascii is the digital equivalent of yelling at kids to stay off your lawn | 19:13 |
| smcginnis | Hah, fair enough. | 19:14 |
| dtroyer | hows this: ||) | 19:14 |
| smcginnis | +1 | 19:14 |
| smcginnis | U) | 19:14 |
| fungi | looks tasty enough to drink | 19:14 |
| dtroyer | (|| for lefties | 19:14 |
| * dmsimard raises mug for fungi | 19:15 | |
| fungi | could also make one with LP though that looks a bit more like a coffee mug and could also be confused for a bug tracker | 19:15 |
| smcginnis | Cheers? (// \\) | 19:15 |
| pabelanger | ||) | 19:15 |
| pabelanger | nice | 19:15 |
| cmurphy | so in german stein actually means stone not mug https://translate.google.com/#de/en/stein | 19:16 |
| cmurphy | so we went from release rocky to release rock | 19:16 |
| dmsimard | heh | 19:16 |
| jroll | I've always liked cU for a coffee mug | 19:16 |
| dmsimard | cmurphy: so you're saying we should name openstack releases after kind of rocks then | 19:17 |
| dmsimard | or rock adjectives | 19:17 |
| fungi | cmurphy: that's awesome! | 19:17 |
| cmurphy | dmsimard: i'm saying that seems to be the trend ;) | 19:17 |
| dmsimard | well I mean OpenStack kind of rocks anyway | 19:17 |
| dmsimard | :D | 19:17 |
| cmurphy | this is true | 19:17 |
| fungi | we're rocking releases | 19:17 |
| dmsimard | does that make us rock stars ? | 19:18 |
| dmsimard | oh it never ends | 19:18 |
| fungi | so the release's namesake, steinstraße translates as "stone street" i expect | 19:18 |
| cmurphy | ja | 19:19 |
| clarkb | this is the second street name we've taken too right? | 19:19 |
| clarkb | icehouse was also a street | 19:19 |
| fungi | yep | 19:19 |
| smcginnis | Better watch with the puns, you're going to set cdent off. :) | 19:20 |
| cdent | shit | 19:20 |
| fungi | though interestingly, translate.g.o also says the word for english "stein" is also "stein" in deutsche | 19:21 |
| cdent | I was just ready to quit IRC | 19:21 |
| cdent | but now I can't because it will seem I quit in a huff over puns | 19:21 |
| dtroyer | but now you can quit because that declaration makes it no so | 19:21 |
| fungi | though bierkrug seems to be the preferred translation of beer stein | 19:22 |
| cdent | thank you dtroyer | 19:23 |
| *** cdent has quit IRC | 19:24 | |
| dhellmann | cmurphy : we need to make sure ttx or jbryce mention that in a keynote | 19:30 |
| cmurphy | :D | 19:31 |
| dhellmann | or maybe we make you get up on stage and say that in front of everyone ;-) | 19:32 |
| * cmurphy hides | 19:35 | |
| cmurphy | my face is already on the landing page for the summit for some reason >.< | 19:36 |
| smcginnis | cmurphy: Then you definitely are a rock star. :) | 19:36 |
| cmurphy | lol | 19:37 |
| * dhellmann groans | 19:39 | |
| dmsimard | +1 | 19:40 |
| fungi | cmurphy: 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 |
| cmurphy | could be both | 19:46 |
| dhellmann | well now we *have* to get you up on stage to talk about "stein" | 19:52 |
| clarkb | I really want beer steins as swag now | 19:55 |
| smcginnis | That better be a no brainer, or else a lot of marketing people need a stern talking to. | 19:55 |
| *** kumarmn_ has joined #openstack-tc | 20:25 | |
| *** kumarmn has quit IRC | 20:28 | |
| *** zaneb has joined #openstack-tc | 20:50 | |
| * fungi is just waiting for the "stackenstein" jokes to start rolling in | 21:13 | |
| *** zaneb has quit IRC | 21:13 | |
| *** annabelleB has quit IRC | 21:40 | |
| *** annabelleB has joined #openstack-tc | 21:50 | |
| *** kumarmn_ has quit IRC | 22:01 | |
| *** kumarmn has joined #openstack-tc | 22:19 | |
| *** kumarmn has quit IRC | 22:24 | |
| *** hongbin has quit IRC | 22:34 | |
| openstackgerrit | Tony Breeds proposed openstack/project-team-guide master: Update Stable policy for Extended Maintenance https://review.openstack.org/552733 | 22:39 |
| *** gagehugo has left #openstack-tc | 22:40 | |
| *** zaneb has joined #openstack-tc | 23:18 | |
| *** kumarmn has joined #openstack-tc | 23:21 | |
| *** kumarmn has quit IRC | 23:32 | |
| *** jroll has quit IRC | 23:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!