| *** markvoelker has quit IRC | 00:05 | |
| *** markvoelker has joined #openstack-meeting-cp | 01:05 | |
| *** markvoelker has quit IRC | 01:11 | |
| *** nikhil_k has joined #openstack-meeting-cp | 01:54 | |
| *** johnthetubaguy has quit IRC | 01:54 | |
| *** nikhil has quit IRC | 01:56 | |
| *** johnthetubaguy has joined #openstack-meeting-cp | 01:57 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:07 | |
| *** markvoelker has quit IRC | 03:12 | |
| *** markvoelker has joined #openstack-meeting-cp | 05:07 | |
| *** markvoelker has quit IRC | 05:12 | |
| *** [1]evgenyf has joined #openstack-meeting-cp | 06:59 | |
| *** markvoelker has joined #openstack-meeting-cp | 07:08 | |
| *** markvoelker has quit IRC | 07:13 | |
| *** dims_ has joined #openstack-meeting-cp | 07:26 | |
| *** markvoelker has joined #openstack-meeting-cp | 09:09 | |
| *** markvoelker has quit IRC | 09:14 | |
| *** markvoelker has joined #openstack-meeting-cp | 10:25 | |
| *** markvoelker has quit IRC | 10:29 | |
| *** [1]evgenyf has quit IRC | 10:49 | |
| *** dims_ has quit IRC | 11:04 | |
| *** markvoelker has joined #openstack-meeting-cp | 12:26 | |
| *** markvoelker has quit IRC | 12:30 | |
| *** [1]evgenyf has joined #openstack-meeting-cp | 12:40 | |
| *** notmyname has quit IRC | 12:57 | |
| *** notmyname has joined #openstack-meeting-cp | 12:57 | |
| *** markvoelker has joined #openstack-meeting-cp | 13:08 | |
| *** dims has joined #openstack-meeting-cp | 13:43 | |
| *** dims has quit IRC | 13:48 | |
| *** dims_ has joined #openstack-meeting-cp | 13:57 | |
| *** nikhil_k is now known as nikhil | 14:00 | |
| *** [1]evgenyf has quit IRC | 14:25 | |
| *** cdent has joined #openstack-meeting-cp | 14:50 | |
| sdague | who is around for the service catalog meeting? | 15:02 |
|---|---|---|
| bknudson | I'll be listening in. | 15:02 |
| * bknudson lurks | 15:02 | |
| cdent | o/ | 15:02 |
| sdague | we seem to be missing annegentle... that will make this a little hard | 15:03 |
| sdague | but let me get things rolling | 15:03 |
| * jroll also lurking | 15:03 | |
| sdague | #startmeeting service-catalog-tng | 15:03 |
| openstack | Meeting started Thu Dec 10 15:03:24 2015 UTC and is due to finish in 60 minutes. The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:03 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:03 |
| *** openstack changes topic to " (Meeting topic: service-catalog-tng)" | 15:03 | |
| openstack | The meeting name has been set to 'service_catalog_tng' | 15:03 |
| sdague | #link Agenda - https://wiki.openstack.org/wiki/Meetings/ServiceCatalogTNG#Service_Catalog_TNG_Meeting | 15:04 |
| *** breton has joined #openstack-meeting-cp | 15:04 | |
| sdague | ok, this is sparse and missing anne, so I'll try to provide some summary kickoff | 15:04 |
| sdague | #topic overview | 15:04 |
| *** openstack changes topic to "overview (Meeting topic: service-catalog-tng)" | 15:04 | |
| sdague | #link https://wiki.openstack.org/wiki/ServiceCatalogTNG | 15:04 |
| sdague | there is a service catalog main wiki page with what we are trying to do, which is mostly make the service catalog something that gets more used going forward | 15:05 |
| sdague | the cross project spec - https://review.openstack.org/#/c/181393/ has some of the background on weirdnesses we currently have | 15:05 |
| sdague | #topic Realistic Goals for Mitaka | 15:06 |
| *** openstack changes topic to "Realistic Goals for Mitaka (Meeting topic: service-catalog-tng)" | 15:06 | |
| sdague | anne and I were discussing this the other day, and trying to establish what those goals would be | 15:06 |
| bknudson | https://wiki.openstack.org/wiki/ServiceCatalogTNG#Mitaka_Goals ? | 15:07 |
| cdent | (is it the case that, as usual, swift is special?) | 15:07 |
| sdague | yes, that's our current best guess of things | 15:07 |
| sdague | cdent: well, the project_id in swift is semantically meaningful | 15:08 |
| cdent | yeah | 15:08 |
| sdague | which is really not true for other projects | 15:08 |
| bknudson | have we identified the projects? | 15:08 |
| *** agentle has joined #openstack-meeting-cp | 15:08 | |
| bknudson | that need the project_id removed | 15:08 |
| agentle | o/ sorry I'm late | 15:08 |
| *** ayoung has joined #openstack-meeting-cp | 15:09 | |
| ayoung | MEETING PARTY CRASHER | 15:09 |
| ayoung | Sorry | 15:09 |
| sdague | bknudson: I don't have the complete list, that would be a good thing to capture here. nova, and things that forked out from nova mostly | 15:09 |
| sdague | #action need to capture authoritative list of projects that use project_id | 15:10 |
| sdague | that could use a volunteer, if anyone wants to pitch in | 15:10 |
| ayoung | sdague, notmorgan was doing a POC and identified the ones he tripped over | 15:10 |
| ayoung | I think it might be a very short list | 15:11 |
| sdague | ayoung: yes, it's not huge | 15:11 |
| agentle | sdague: I think Thomas Goirand had one, I'll find it | 15:11 |
| sdague | agentle: great | 15:11 |
| ayoung | it really is only an issue if project_id is in the service catalog itselfm, and not in the URL | 15:11 |
| sdague | ayoung: right, that's what I mean, if project_id is dynamically serviced by the service catalog | 15:11 |
| ayoung | that we can tell by the SC generated by devstack | 15:12 |
| ayoung | I only ever saw a problem with Nova | 15:12 |
| ayoung | but I tend to do limited deployments... | 15:12 |
| sdague | ok, so agentle can I sign you up for having the athoritative list by next week? | 15:13 |
| sdague | or is there someone else that would like to volunteer for that? | 15:13 |
| sdague | it's probably about 2 hrs worth of work tops | 15:13 |
| agentle | sdague: Yep, by next week thurs. | 15:14 |
| sdague | agentle: sounds great | 15:14 |
| sdague | #action (annegentle) capture authoritative list of projects that use project_id in catalog entries | 15:14 |
| ayoung | how definitive tdoes this need to be? Everything in the Big Tent? | 15:14 |
| agentle | ayoung: i'll use the list of service catalogs we gathered round the world | 15:14 |
| agentle | #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog | 15:15 |
| sdague | ayoung: as authoritative as we can get it | 15:15 |
| sdague | ok, given that the goals get somewhat duplicated in the next set of topics, lets go through the topics in order | 15:15 |
| sdague | #topic Service Catalog Spec | 15:15 |
| *** openstack changes topic to "Service Catalog Spec (Meeting topic: service-catalog-tng)" | 15:15 | |
| sdague | agentle: the update was on your plate, what additional things do you need before pushing the next update? | 15:16 |
| sdague | agentle: ? | 15:17 |
| agentle | sdague: I think we have a response for John er, notmyname, but I might update that vision section for the focus this release | 15:17 |
| agentle | sorry slow typing this morning :) | 15:17 |
| sdague | agentle: ok, no prob | 15:17 |
| agentle | sdague: I can't get the eavesdrop for the first part, is the focus: project id and? | 15:18 |
| sdague | agentle: ok, are you able to get things into shape by next meeting? | 15:18 |
| agentle | sdague: ayup | 15:18 |
| sdague | #action (annegentle) update service catalog cross project spec by next meeting | 15:18 |
| * agentle gets all the actions today | 15:18 | |
| sdague | well, so far :) | 15:18 |
| agentle | heh | 15:18 |
| sdague | #topic Project Id Optionality in projects | 15:19 |
| *** openstack changes topic to "Project Id Optionality in projects (Meeting topic: service-catalog-tng)" | 15:19 | |
| sdague | ok, so we have the action for anne about building the complete list of services | 15:19 |
| bknudson | next step is to get the projects to support no project id | 15:20 |
| sdague | we've got a nova functional patch up https://review.openstack.org/#/c/233076/ that's mostly waiting on some refactoring of our in tree testing to get it landable | 15:20 |
| sdague | #action check in on nova patch for next week's meeting | 15:20 |
| bknudson | that his a lot of files | 15:20 |
| sdague | I'm hopeful that is ready to go next week | 15:20 |
| sdague | it's router changes in 3 files, and microversion bumps | 15:21 |
| sdague | a microversion bump changes a constant in about 6 places in the tree, it's pretty small change really | 15:21 |
| bknudson | looks pretty easy | 15:22 |
| bknudson | devstack change, too? | 15:22 |
| sdague | there is a devstack change to set the catalog as well | 15:22 |
| agentle | sdague: and I wonder what docs will need updating | 15:22 |
| sdague | #link https://review.openstack.org/#/c/233079/ | 15:23 |
| sdague | that's the devstack change, it works with that nova change | 15:23 |
| bknudson | there's a novaclient change, too? | 15:23 |
| sdague | bknudson: yes, it's already landed | 15:23 |
| sdague | it was mostly about discovery | 15:23 |
| ayoung | I wonder if this is going to be a problem with Policy enforcement. If the projectID is dropped from the URL, is it possible that a check will also be dropped? | 15:23 |
| bknudson | kind of scary, but whatever | 15:23 |
| sdague | ayoung: do you have an example of where such a policy enforcement check is today? | 15:24 |
| ayoung | sdague, I can show you nova's | 15:24 |
| bknudson | ayoung: are you worried the project ID won't be in the context? | 15:24 |
| sdague | ayoung: yeh, link would be great | 15:24 |
| ayoung | so...not sure, but | 15:24 |
| sdague | the project_id is still in the context | 15:24 |
| ayoung | the token has a proj id that is used to generate the url...the url then has a project Id that needs to match that of the resource | 15:25 |
| ayoung | say...and image or a vm | 15:25 |
| sdague | the code in nova litterally only cared about project_id in url for 10 lines of code | 15:25 |
| sdague | where it did a project_id == context.project_id or die | 15:25 |
| sdague | and the url was fully ignored beyond that | 15:25 |
| cdent | death++ | 15:25 |
| ayoung | right. that is important, though. Still need a check like that, but it is not sufficient | 15:26 |
| agentle | interesting | 15:26 |
| sdague | ayoung: it's not though, because the acl is enforced on the uuid of the server as well | 15:26 |
| ayoung | I need to think this through...I'll come back | 15:26 |
| sdague | you can't just find someone else's uuid of server, put it under your project id, and delete it | 15:26 |
| ayoung | sdague, meaning context.project_iod == server.proejct_id or die? | 15:27 |
| sdague | so, I'd recommend looking at the nova patch directly if there are concerns there | 15:27 |
| sdague | because I'm pretty sure things are fully covered | 15:27 |
| sdague | ok, lets move on to next topic | 15:28 |
| ayoung | I suspect it is fine, but we should be testing | 15:28 |
| cdent | presumably there is test coverage for this sort of thing already? | 15:28 |
| sdague | cdent: there is, we had to change a tempest test though because it was no longer possible to ask for servers by wrong project id when project_id is not in the url | 15:29 |
| cdent | ✔ | 15:29 |
| sdague | we could determine if there is another test that's appropriate here | 15:29 |
| sdague | cdent: anything you might want to look at? :) | 15:30 |
| sdague | given you are diving into nova now | 15:30 |
| ayoung | sdague, the token.project_id should be different from the one requested. Suspect that is already tested | 15:30 |
| sdague | ayoung: yes, already tested | 15:30 |
| cdent | I'm hesitant to make any commitments just yet because I don't know the lay of the land, but this is definitely an area where I'm very interested | 15:30 |
| cdent | So I'm trying to get myself oriented so I can safely say "yupppers, I'm on that" | 15:31 |
| sdague | ok, no prob | 15:31 |
| sdague | #action nova functional test to ensure we don't loose any safety in removing project_id from url | 15:32 |
| sdague | we'll see who ends up with that | 15:32 |
| sdague | ok, really next topic | 15:32 |
| sdague | #topic What URLs are needed | 15:32 |
| *** openstack changes topic to "What URLs are needed (Meeting topic: service-catalog-tng)" | 15:32 | |
| sdague | this is part of coming up with a draft schema for the service catalog | 15:32 |
| cdent | I found the mailing list thread on this topic challenging to parse. | 15:32 |
| sdague | today, we have 3 things: publicURL, adminURL, internalURL | 15:32 |
| notmorgan | sdague: and unfortunately it's different dependint on the catalog version | 15:33 |
| ayoung | do we have defintions of what is meant by those? | 15:33 |
| sdague | #link http://lists.openstack.org/pipermail/openstack-operators/2015-December/009061.html | 15:33 |
| bknudson | I think adminURL was only there for for keystone since we have admin and public APIs | 15:33 |
| notmorgan | so really we have 6 iirc. :( | 15:33 |
| bknudson | (in v2) | 15:33 |
| sdague | there is an openstack operators thread on this | 15:33 |
| sdague | notmorgan: ok, sure, well really we have N | 15:33 |
| sdague | because that's all convention, and not enforced anywhere | 15:34 |
| ayoung | OK. I know what they are supposed to mean in Keystone. | 15:34 |
| sdague | and as such gets used wildly inconsistently | 15:34 |
| bknudson | I think operators like internalURL and publicURL for services. I want my internal users to use internalURL and outside users only have publicURL | 15:34 |
| sdague | as can been seen by some of the responses there | 15:34 |
| ayoung | THey are not such horrible ideas, but we should probably taylor the SC to return the right ones | 15:34 |
| bknudson | maybe there's a better way to do internal/public access | 15:35 |
| sdague | bknudson: honestly, it sounded like from that thread a lot of operators don't like the current split | 15:35 |
| ayoung | bknudson, different hostnames is really the best option. | 15:35 |
| sdague | bluebox uses hosts overrides | 15:35 |
| ayoung | THat way you can have different interfaces on the same machine handle them | 15:35 |
| ayoung | its a firewall issue | 15:35 |
| sdague | to always get internal users to the right address | 15:35 |
| sdague | for instance | 15:35 |
| sdague | I would recommend everyone read and comment on the operator thread | 15:36 |
| ayoung | different ports was always sketchy, but that was an impl detail we could work around | 15:36 |
| bknudson | y, putting the knowledge in the network makes sense | 15:36 |
| bknudson | since otherwise apps have to provide config options or know where they're running somehow | 15:36 |
| sdague | #action (sdague) revisit operator thread try to reexpress current common themes | 15:36 |
| ayoung | So, here is what they are supposed to mean, and this is not Keystone specific: | 15:37 |
| sdague | I think the one thing that did arrise that was new was the desire that services have dedicated urls for them to talk to each other | 15:37 |
| david-lyle | so I can say the HP Public Cloud (RIP) used adminURL for nova at least | 15:37 |
| ayoung | Public is what users outside the firewall get for normal useage | 15:37 |
| ayoung | admin is the same, but an higher level of control and security | 15:37 |
| agentle | yes david-lyle same for Rackspace also | 15:37 |
| david-lyle | certain extensions were only enabled when going through adminURL rather than public | 15:37 |
| ayoung | some deployments want to put that inside dfirewall | 15:37 |
| ayoung | internal is service to service | 15:37 |
| bknudson | if HPE and RAX both find this useful/necessary then seems like we'd keep it? | 15:38 |
| ayoung | We don't Need them per-se, as there are other ways to do the same thing, but this was not a horrible approach | 15:38 |
| sdague | david-lyle: for keystone only, right? | 15:38 |
| david-lyle | no for nova | 15:38 |
| ayoung | However...we could also deduce which one to return based on the caller | 15:38 |
| sdague | david-lyle: hmmm... it doesn't appear in the catalog that was captured | 15:39 |
| sdague | https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog#HP | 15:39 |
| ayoung | IE, the nova service user gets the right Keystone URL, and the right Glance url, both internal | 15:39 |
| agentle | sdague: that catalog is the public one not the "I'm a cloud admin" one | 15:39 |
| sdague | ah, ok, so you only get an adminURL if you are an admin? | 15:39 |
| agentle | sdague: I'm not an admin on any cloud to test that theory :) | 15:39 |
| david-lyle | that catalog is not from sufficiently empowered I think | 15:40 |
| ayoung | sdague, so, I'm not certain about that. It is more likely that is supposed to be location aware | 15:40 |
| david-lyle | that's the end user view | 15:40 |
| ayoung | if you are inside the firewall, and a regular user, I don't know which you would get | 15:40 |
| sdague | so, maybe we really should step back and describe the personas here | 15:40 |
| sdague | perhaps that's the next step | 15:41 |
| notmorgan | sdague: ++ | 15:41 |
| cdent | that's a good idea | 15:41 |
| ayoung | The idea is that you want to do more than just Token securet (heh) if you are, say, adding a user. You only want that done from inside the firewall. Good concept, don't think the SC is the right way to enforce it | 15:41 |
| ayoung | m,ayeb add user is a bad example, tho9ugh | 15:41 |
| ayoung | more like adding a service or endpoint | 15:41 |
| cdent | I get the sense that there are some conflicts between the technical goals and the user stories... | 15:41 |
| sdague | ok, anyone interested in starting to hack out the personas? That seems like an etherpad activity. | 15:41 |
| sdague | cdent: yeh | 15:42 |
| bknudson | ayoung: I think david-lyle says it's not inside/outside firewall at all, but the user's auth. | 15:42 |
| ayoung | bknudson, I said that | 15:42 |
| ayoung | bknudson, it is a case of userauth + more security | 15:42 |
| ayoung | at least, that was the concept | 15:42 |
| ayoung | we could do it with just user auth, but that is not sufficient for some people | 15:42 |
| ayoung | they want to reduce their attack surface | 15:42 |
| ayoung | ask gyee, this is his kind of thing 2FA and all that | 15:43 |
| sdague | yeh, the "more security" seems weird though. If you don't trust keystone to enforce security correctly on 1 url, I'm not sure why 2 makes it better :) | 15:43 |
| ayoung | sdague, cuz tokens suck | 15:43 |
| ayoung | you want to make it if an admin user loses a token in the wild, the server can't even be reached and it is not attackable for the sensitive operations | 15:43 |
| sdague | #info we need a personas document to really determine what data / urls will be needed in a new catalog | 15:44 |
| bknudson | I think we'll need more operator feedback into personas | 15:44 |
| ayoung | this is just the rationalization I have been able to piece together over the years. I was not there for the initial discussion | 15:44 |
| notmorgan | ayoung: i also don't think most operators actually do that. | 15:44 |
| notmorgan | ayoung: HP is one of the few. | 15:44 |
| ayoung | notmorgan, Heh, neither do I | 15:44 |
| notmorgan | ayoung: i also think it's a false set of security. | 15:45 |
| sdague | ok, I'm going to move us to open discussion | 15:45 |
| sdague | #topic Open Discussion | 15:45 |
| *** openstack changes topic to "Open Discussion (Meeting topic: service-catalog-tng)" | 15:45 | |
| sdague | so, a few things quick | 15:45 |
| ayoung | notmorgan, I'm guessing you would argue "if you need to be inside the firewall, use a CLI with direct access to the machine" is the right approach? | 15:45 |
| sdague | 1) volutneers wanted / needed if we are going to make real progress here | 15:45 |
| *** yarkot has joined #openstack-meeting-cp | 15:45 | |
| notmorgan | ayoung: that is my general view - if it's something that really is *that* sensitive, you probably shouldn't be exposing it via a REST API and it should be CMS | 15:46 |
| sdague | the idea is this meeting becomes more of a status check in. less discussion. disucssion should go to the lists. | 15:46 |
| ayoung | sdague, got iot | 15:46 |
| ayoung | it | 15:46 |
| agentle | stand up :) | 15:47 |
| cdent | sdague: keep after me to be an active part of this | 15:47 |
| agentle | thanks cdent | 15:47 |
| bknudson | I posted a related change to devstack, removing /v2.0 from the identity entry in the catalog: https://review.openstack.org/#/c/255294/ | 15:47 |
| sdague | related, notmorgan and I have been working towards having nova know how to talk to glance via service catalog entries | 15:47 |
| ayoung | notmorgan, I think that makes sense. | 15:47 |
| sdague | as it's the last service nova talks to with hardcoded values only | 15:47 |
| ayoung | sdague, the MOC guys are working on that too. | 15:48 |
| sdague | link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:glance_image_config,n,z | 15:48 |
| notmorgan | sdague: actually... i think neutron needs work. | 15:48 |
| bknudson | which version of the service catalog are you using? | 15:48 |
| bknudson | also, which endpoint? | 15:48 |
| ayoung | I'll ask them to comment and contriubte | 15:48 |
| sdague | ayoung: MOC? | 15:48 |
| ayoung | Mass Open Cloud. Resourece Federation | 15:49 |
| sdague | notmorgan: ok, cool, I thought we had base infrastructure for that | 15:49 |
| sdague | ayoung: ah great | 15:49 |
| ayoung | say glance and Nova are owned by two different orgs | 15:49 |
| notmorgan | sdague: ran into this with my POC | 15:49 |
| sdague | ok, any other related work from people to highlight that we should keep an eye on things? | 15:49 |
| ayoung | sdague, add gsilvis to any reviews you have along those lines | 15:49 |
| sdague | ayoung: ok, will do | 15:49 |
| sdague | ok, anything else, or time to end meeting? | 15:50 |
| sdague | next week we'll start with outstanding actions from this week | 15:50 |
| sdague | then a 2 week hiatus re:holidays | 15:50 |
| sdague | then back with a furry in 2016 | 15:50 |
| cdent | what kind of furry? a teddy bear? reindeer? kitty cat? ;) | 15:51 |
| sdague | cat bus | 15:51 |
| cdent | YES | 15:51 |
| bknudson | new year's resolution will be to fix the service catalog | 15:51 |
| cdent | \o/ | 15:51 |
| sdague | I brought one back for my daughter | 15:51 |
| sdague | it's awesome | 15:51 |
| sdague | ok, thanks for showing up to our kickoff, see you all next week | 15:51 |
| sdague | #endmeeting | 15:51 |
| *** openstack changes topic to "cross-project liaisons (Meeting topic: crossproject)" | 15:51 | |
| openstack | Meeting ended Thu Dec 10 15:51:54 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:51 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/service_catalog_tng/2015/service_catalog_tng.2015-12-10-15.03.html | 15:51 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/service_catalog_tng/2015/service_catalog_tng.2015-12-10-15.03.txt | 15:51 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/service_catalog_tng/2015/service_catalog_tng.2015-12-10-15.03.log.html | 15:52 |
| sdague | I guess only last thing, there is no dedicated channel for this effort, please just use #openstack-dev | 15:52 |
| *** agentle has quit IRC | 15:55 | |
| *** cdent has left #openstack-meeting-cp | 16:03 | |
| *** yarkot has quit IRC | 16:52 | |
| *** david-lyle has quit IRC | 16:53 | |
| *** dims_ has quit IRC | 17:06 | |
| *** dims has joined #openstack-meeting-cp | 17:12 | |
| *** dims has quit IRC | 17:16 | |
| *** dims has joined #openstack-meeting-cp | 17:17 | |
| *** dims has quit IRC | 17:24 | |
| *** dims has joined #openstack-meeting-cp | 17:47 | |
| *** dims has quit IRC | 17:53 | |
| *** dims has joined #openstack-meeting-cp | 17:57 | |
| *** dims has quit IRC | 18:12 | |
| *** dims has joined #openstack-meeting-cp | 18:36 | |
| *** harlowja has quit IRC | 18:56 | |
| *** harlowja has joined #openstack-meeting-cp | 18:56 | |
| *** yarkot has joined #openstack-meeting-cp | 19:19 | |
| *** yarkot has quit IRC | 20:32 | |
| *** dims has quit IRC | 20:35 | |
| *** dims has joined #openstack-meeting-cp | 20:35 | |
| *** yarkot has joined #openstack-meeting-cp | 20:46 | |
| *** dslevin has joined #openstack-meeting-cp | 21:48 | |
| *** yarkot has quit IRC | 22:12 | |
| *** yarkot has joined #openstack-meeting-cp | 22:13 | |
| *** yarkot has quit IRC | 22:17 | |
| *** david-lyle has joined #openstack-meeting-cp | 22:20 | |
| *** dslevin has quit IRC | 22:42 | |
| *** dslevin has joined #openstack-meeting-cp | 22:43 | |
| *** david-lyle has quit IRC | 22:55 | |
| *** dslevin has quit IRC | 22:55 | |
| *** dslevin_ has joined #openstack-meeting-cp | 23:29 | |
| *** dslevin_ has quit IRC | 23:33 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!