| *** angdraug has quit IRC | 00:08 | |
| *** dims has joined #openstack-meeting-cp | 00:23 | |
| *** docaedo has quit IRC | 00:31 | |
| *** dims has quit IRC | 00:32 | |
| *** docaedo has joined #openstack-meeting-cp | 00:32 | |
| *** markvoelker has joined #openstack-meeting-cp | 00:40 | |
| *** vilobhmm11 has quit IRC | 00:53 | |
| *** sdake has joined #openstack-meeting-cp | 00:55 | |
| *** dims has joined #openstack-meeting-cp | 00:56 | |
| *** sdake has quit IRC | 01:10 | |
| *** markvoelker has quit IRC | 01:14 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 01:22 | |
| *** vilobhmm111 has joined #openstack-meeting-cp | 01:27 | |
| *** vilobhmm11 has quit IRC | 01:29 | |
| *** cshahani has quit IRC | 01:38 | |
| *** cshahani has joined #openstack-meeting-cp | 01:39 | |
| *** cshahani has quit IRC | 01:55 | |
| *** vilobhmm111 has quit IRC | 02:00 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 02:03 | |
| *** cshahani has joined #openstack-meeting-cp | 02:28 | |
| *** dims has quit IRC | 02:38 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:11 | |
| *** vilobhmm11 has quit IRC | 03:19 | |
| *** markvoelker has quit IRC | 03:44 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 03:45 | |
| *** sdake has joined #openstack-meeting-cp | 04:06 | |
| *** sdake_ has joined #openstack-meeting-cp | 04:09 | |
| *** sdake has quit IRC | 04:11 | |
| *** sdake_ has quit IRC | 04:19 | |
| *** sdake has joined #openstack-meeting-cp | 05:16 | |
| *** askb has joined #openstack-meeting-cp | 05:33 | |
| *** askb has quit IRC | 05:33 | |
| *** sdake has quit IRC | 05:33 | |
| *** askb has joined #openstack-meeting-cp | 05:34 | |
| *** markvoelker has joined #openstack-meeting-cp | 05:41 | |
| *** markvoelker has quit IRC | 06:14 | |
| *** askb has quit IRC | 06:24 | |
| *** belmoreira has joined #openstack-meeting-cp | 07:58 | |
| *** markvoelker has joined #openstack-meeting-cp | 08:12 | |
| *** vilobhmm11 has quit IRC | 08:32 | |
| *** markvoelker has quit IRC | 08:44 | |
| *** sdague has joined #openstack-meeting-cp | 10:01 | |
| *** markvoelker has joined #openstack-meeting-cp | 10:42 | |
| *** dims has joined #openstack-meeting-cp | 11:12 | |
| -openstackstatus- NOTICE: Gerrit is going to be restarted | 11:13 | |
| *** markvoelker has quit IRC | 11:15 | |
| *** dims has quit IRC | 11:20 | |
| *** dims has joined #openstack-meeting-cp | 11:21 | |
| *** dims has quit IRC | 11:21 | |
| *** dims has joined #openstack-meeting-cp | 11:21 | |
| -openstackstatus- NOTICE: Gerrit had to be restarted because was not responsive. As a consequence, some of the test results have been lost, from 08:30 UTC to 10:30 UTC approximately. Please recheck any affected jobs by this problem. | 11:33 | |
| -openstackstatus- NOTICE: Gerrit had to be restarted because was not responsive. As a consequence, some of the test results have been lost, from 09:30 UTC to 11:30 UTC approximately. Please recheck any affected jobs by this problem. | 11:36 | |
| *** belmoreira has quit IRC | 12:07 | |
| *** raildo-afk is now known as raildo | 12:16 | |
| *** cshahani has quit IRC | 12:21 | |
| *** dims has quit IRC | 12:25 | |
| *** dims has joined #openstack-meeting-cp | 12:26 | |
| *** ninag has joined #openstack-meeting-cp | 12:53 | |
| *** markvoelker has joined #openstack-meeting-cp | 12:53 | |
| *** sdake has joined #openstack-meeting-cp | 13:08 | |
| *** ninag_ has joined #openstack-meeting-cp | 13:23 | |
| *** ninag has quit IRC | 13:26 | |
| *** sdake has quit IRC | 13:38 | |
| *** askb has joined #openstack-meeting-cp | 13:59 | |
| *** sdake has joined #openstack-meeting-cp | 14:25 | |
| *** askb has quit IRC | 14:51 | |
| -openstackstatus- NOTICE: Launchpad OpenID SSO is currently experiencing issues preventing login. The Launchpad team is working on the issue | 14:58 | |
| *** ChanServ changes topic to "Launchpad OpenID SSO is currently experiencing issues preventing login. The Launchpad team is working on the issue" | 14:58 | |
| *** markvoelker has quit IRC | 15:00 | |
| *** ChanServ changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 15:31 | |
| -openstackstatus- NOTICE: Launchpad SSO is back to normal - happy hacking | 15:31 | |
| *** askb has joined #openstack-meeting-cp | 15:33 | |
| *** askb has quit IRC | 15:33 | |
| *** askb has joined #openstack-meeting-cp | 15:33 | |
| *** ninag_ has quit IRC | 16:09 | |
| *** ninag has joined #openstack-meeting-cp | 16:12 | |
| *** ninag has quit IRC | 16:18 | |
| *** ninag has joined #openstack-meeting-cp | 16:19 | |
| *** kazuIchikawa has joined #openstack-meeting-cp | 16:20 | |
| *** markvoelker has joined #openstack-meeting-cp | 16:25 | |
| *** sdake_ has joined #openstack-meeting-cp | 16:31 | |
| *** sdake has quit IRC | 16:34 | |
| *** ninag has quit IRC | 17:44 | |
| *** kazuIchikawa has quit IRC | 17:57 | |
| *** ninag has joined #openstack-meeting-cp | 17:59 | |
| *** dims_ has joined #openstack-meeting-cp | 18:03 | |
| *** dims has quit IRC | 18:03 | |
| *** askb has quit IRC | 18:16 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 18:20 | |
| *** dims_ has quit IRC | 18:29 | |
| *** sdake_ has quit IRC | 18:34 | |
| *** thinrichs has joined #openstack-meeting-cp | 18:36 | |
| *** thinrichs has quit IRC | 19:02 | |
| *** sdake has joined #openstack-meeting-cp | 19:07 | |
| *** dims has joined #openstack-meeting-cp | 19:12 | |
| *** dims has quit IRC | 19:18 | |
| *** sdake_ has joined #openstack-meeting-cp | 19:21 | |
| *** sdake has quit IRC | 19:23 | |
| *** dims has joined #openstack-meeting-cp | 19:26 | |
| *** tyr_ has joined #openstack-meeting-cp | 19:42 | |
| *** dims has quit IRC | 19:45 | |
| *** thinrichs has joined #openstack-meeting-cp | 19:51 | |
| *** sdake_ has quit IRC | 19:51 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 19:52 | |
| *** annegentle has joined #openstack-meeting-cp | 20:01 | |
| *** aspiers has joined #openstack-meeting-cp | 20:05 | |
| *** fhermeni has joined #openstack-meeting-cp | 20:08 | |
| *** dims has joined #openstack-meeting-cp | 20:11 | |
| *** sdake has joined #openstack-meeting-cp | 20:11 | |
| *** thinrichs has quit IRC | 20:17 | |
| *** samueldmq has joined #openstack-meeting-cp | 20:23 | |
| *** bswartz has quit IRC | 20:29 | |
| *** bswartz has joined #openstack-meeting-cp | 20:30 | |
| *** thinrichs has joined #openstack-meeting-cp | 20:32 | |
| *** thinrichs has quit IRC | 20:32 | |
| *** thinrichs has joined #openstack-meeting-cp | 20:41 | |
| *** SamP has joined #openstack-meeting-cp | 20:47 | |
| *** sdake has quit IRC | 20:50 | |
| *** SamP has left #openstack-meeting-cp | 20:52 | |
| *** sdake has joined #openstack-meeting-cp | 20:53 | |
| *** cdent has joined #openstack-meeting-cp | 20:58 | |
| *** ddeja has joined #openstack-meeting-cp | 21:00 | |
| *** kfox1111 has joined #openstack-meeting-cp | 21:00 | |
| thingee | courtesy ping for Qiming TravT gordc dirk mriedem SergeyLukjanov | 21:00 |
|---|---|---|
| thingee | courtesy ping for daemontool jroll boris-42 redrobot flaper87 rhochmuth | 21:00 |
| thingee | courtesy ping for fungi flwang dims vipul johnthetubaguy rakhmerov | 21:00 |
| thingee | courtesy ping for docaedo stevemar mtreinish bswartz adam_g adrian_otto | 21:00 |
| jroll | \o | 21:00 |
| thingee | courtesy ping for zigo Piet sdake mugsie sheeprine thinrichs | 21:00 |
| thingee | courtesy ping for jklare loquacities smelikyan Daisy skraynev odyssey4me | 21:00 |
| aspiers | o/ | 21:00 |
| kfox1111 | o/ | 21:00 |
| *** samapthP has joined #openstack-meeting-cp | 21:00 | |
| dims | o/ | 21:00 |
| elmiko | o/ | 21:00 |
| nikhil | o/ | 21:00 |
| fungi | hey-hey, kids! | 21:00 |
| thingee | samueldmq ping | 21:01 |
| stevemar | o/ | 21:01 |
| thinrichs | Hi all | 21:01 |
| samueldmq | hi all | 21:01 |
| samueldmq | thingee: hi | 21:01 |
| ddeja | hello | 21:01 |
| thingee | #startmeeting crossproject | 21:01 |
| openstack | Meeting started Tue Mar 15 21:01:25 2016 UTC and is due to finish in 60 minutes. The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 21:01 |
| *** openstack changes topic to " (Meeting topic: crossproject)" | 21:01 | |
| openstack | The meeting name has been set to 'crossproject' | 21:01 |
| nikhil | thingee: am still not on the list | 21:01 |
| * thingee adds nikhil now :( | 21:01 | |
| fhermeni | hello | 21:01 |
| thingee | missed ya'll | 21:02 |
| adam_g | hiya | 21:02 |
| nikhil | thingee: thx | 21:02 |
| cdent | o/ | 21:02 |
| david-lyle | o/ | 21:02 |
| *** annegentle has quit IRC | 21:02 | |
| thingee | agenda today https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda | 21:02 |
| thingee | pretty full so lets get to it! | 21:02 |
| samapthP | o/ | 21:02 |
| *** kencjohnston has joined #openstack-meeting-cp | 21:02 | |
| *** sdake_ has joined #openstack-meeting-cp | 21:02 | |
| thingee | #topic Compute node HA (a.k.a. automatic evacuation of instances | 21:02 |
| *** openstack changes topic to "Compute node HA (a.k.a. automatic evacuation of instances (Meeting topic: crossproject)" | 21:02 | |
| *** mriedem has joined #openstack-meeting-cp | 21:02 | |
| bswartz | .o/ | 21:03 |
| mriedem | o/ | 21:03 |
| kencjohnston | o/ | 21:03 |
| thingee | #link http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html | 21:03 |
| *** angdraug has joined #openstack-meeting-cp | 21:03 | |
| thingee | aspiers: hi! | 21:03 |
| aspiers | hey :) | 21:03 |
| EmilienM | o/ | 21:03 |
| aspiers | conscious that my slot doesn't have too much time | 21:03 |
| angdraug | o/ | 21:03 |
| *** rockyg has joined #openstack-meeting-cp | 21:03 | |
| *** bauzas has joined #openstack-meeting-cp | 21:03 | |
| lifeless | \o/ | 21:03 |
| rockyg | Thanks thingee ! | 21:03 |
| *** dtroyer has joined #openstack-meeting-cp | 21:03 | |
| aspiers | thingee: shall I kick things off? | 21:03 |
| lifeless | \_/o/+ | 21:04 |
| thingee | aspiers: yes | 21:04 |
| dtroyer | o/ | 21:04 |
| aspiers | ok | 21:04 |
| aspiers | hi everyone :) I'm new to cross-project meetings so please bear with me :) | 21:04 |
| aspiers | since Tokyo I've been moderating weekly meetings of the #openstack-ha IRC community | 21:04 |
| aspiers | we've been collaborating on various approaches to implementing automatic "evacuation" of VM instances | 21:04 |
| thingee | #link https://review.openstack.org/#/c/257809/ cross-project spec | 21:04 |
| aspiers | "evacuation" is in quotes, because so far we've really been dealing with resurrection of dead VMs, via nova's evacuate API | 21:04 |
| *** sdake has quit IRC | 21:05 | |
| aspiers | however in the future, proactive evacuation of live VMs based on (say) alarms from ceilometer is certainly a possibility too | 21:05 |
| EmilienM | alarms from Aodh* | 21:05 |
| aspiers | right | 21:05 |
| aspiers | :) | 21:05 |
| aspiers | we've been trying to promote awareness of the various approaches out there | 21:05 |
| *** carolbarrett has joined #openstack-meeting-cp | 21:05 | |
| *** raildo is now known as raildo-afk | 21:05 | |
| *** gordc has joined #openstack-meeting-cp | 21:05 | |
| aspiers | with the ultimate goal of facilitating convergence on a single implementation, if possible | 21:06 |
| aspiers | you can find a summary of all known existing approaches (to resurrection) here: | 21:06 |
| aspiers | #link https://etherpad.openstack.org/p/automatic-evacuation | 21:06 |
| aspiers | first question from my side is: how cross-project is this, really? which projects do we expect to be affected? | 21:06 |
| *** shamail has joined #openstack-meeting-cp | 21:06 | |
| thingee | aspiers: do you mind telling us here and identifying in the spec the projects this involves? | 21:06 |
| thingee | yes | 21:07 |
| thingee | heh | 21:07 |
| aspiers | sure | 21:07 |
| aspiers | IMHO the answer is "probably less than 10 projects": | 21:07 |
| aspiers | 1. obviously nova is involved :) | 21:07 |
| mriedem | heh | 21:07 |
| aspiers | 2. ceilometer | 21:07 |
| aspiers | 3. aodh | 21:08 |
| aspiers | 4. senlin is clearly aiming to be involved | 21:08 |
| aspiers | 5. mistral - Intel have been working on a PoC where mistral orchestrates evacuation (ddeja who is here with us :) | 21:08 |
| *** _gryf has joined #openstack-meeting-cp | 21:08 | |
| aspiers | 6. heat has been aired in the spec linked above as a possible alternative to mistral, not sure how realistic that is | 21:08 |
| aspiers | 7. congress: I expect this to be needed in the future, to accommodate different recovery policies | 21:09 |
| samueldmq | may the subset be defined by "any project involving quota management" + what triggers and what effectively does the ressurection ? | 21:09 |
| aspiers | and maybe 8. cinder? | 21:09 |
| *** sdague has quit IRC | 21:09 | |
| rockyg | what about manila? | 21:09 |
| jroll | I suspect someone wants this for ironic eventually, based on ideas I've seen, but this would just use nova live-migrate or something, right? | 21:09 |
| aspiers | rockyg: I hadn't thought about manila yet :) | 21:09 |
| aspiers | oh yeah of course: also ironic and Triple-O | 21:10 |
| jroll | (so ironic, as a virt driver, would just work) | 21:10 |
| elmiko | i'm curious if there are some criteria for determining if our project is affected? (something akin to what samueldmq said) | 21:10 |
| jroll | (once it has migrate) | 21:10 |
| aspiers | there's the whole question of fencing of compute nodes | 21:10 |
| thingee | gordc, cdent ^ | 21:10 |
| mriedem | 25. watcher? | 21:10 |
| aspiers | elmiko: not yet | 21:10 |
| aspiers | yes quite possibly watcher too :) | 21:10 |
| gordc | thingee: just reading spec now (missed some of earlier chatter) | 21:10 |
| alaski | jroll: I think it's very likely this would use public apis in Nova, so ironic should "just work"(tm) | 21:10 |
| jroll | alaski: cool, that's what I hoped | 21:11 |
| aspiers | if congress is in charge of deciding what triggers workflows, then other projects don't necessarily have to be aware that data collected from them is being used in this way | 21:11 |
| mriedem | yeah, nova already has the APIs for this as far as i know | 21:11 |
| gordc | aspiers: have you look at the events ceilometer captures currently? | 21:11 |
| thinrichs | aspiers: agreed | 21:11 |
| bauzas | I don't see what Nova needs | 21:11 |
| aspiers | gordc: not nearly as much as I should | 21:11 |
| samueldmq | aspiers: elmiko: interesting, I'd expect that we had defined keywords to help identifying involved projects | 21:11 |
| aspiers | bauzas: currently the nova evacuation process is not robust enough (I'm told) | 21:11 |
| mriedem | fwiw, there is an ibm product that already does something like this, event-driven automatic evacuation, i could get names of people involved in that, they might also be invovled in this, | 21:12 |
| mriedem | but they had some nova api extensions i believe | 21:12 |
| mriedem | like rate limiting the migrations off the compute node | 21:12 |
| mriedem | rather than just a huge batch | 21:12 |
| aspiers | mriedem: yes that is one of the problems which needs tackling | 21:12 |
| elmiko | samueldmq: yea, i'm very curious as i could a hypervisor dropout affecting sahara in a negative way | 21:12 |
| aspiers | scalable scheduling | 21:12 |
| elmiko | *i could see | 21:12 |
| gordc | aspiers: i think quite a few of this is already captured in Ceilometer via messages sent from services or the polling done | 21:13 |
| samueldmq | elmiko: ++ | 21:13 |
| shamail | aspiers: +1, the current prototype i’ve seen for Masakari specifies nova hosts for evacuation versus using the scheduler | 21:13 |
| shamail | nova host* | 21:13 |
| gordc | you can tell when a host or instance is up or down and provisioning failures i believe are already sent as events by nova | 21:13 |
| bauzas | aspiers: well, evacuate for instance HA means that you resurrect your instance, and then impacting the users | 21:13 |
| jroll | so, for the sake of time, what's the goal for this meeting? "should we pursue this" or? | 21:13 |
| aspiers | there are lots of architectural considerations | 21:14 |
| bauzas | jroll: ++ | 21:14 |
| aspiers | and jroll is right, we can't discuss them now | 21:14 |
| shamail | I personally see it as instance recovery vs. availability | 21:14 |
| samueldmq | jroll: ++ | 21:14 |
| mriedem | bauzas: also, you can't evacuate unless the compute is donw | 21:14 |
| mriedem | *down | 21:14 |
| aspiers | in the short time we have, I just want to understand how this relates to the cross-project team (if it's called a team, I'm not sure) | 21:14 |
| mriedem | methinks anyway | 21:14 |
| mriedem | aspiers: i'm not sure it does | 21:15 |
| bauzas | yup, I was just explaining the problem about using evacuate for HA | 21:15 |
| gordc | for those interested, comment on spec i guess? i have a feeling most of this is already covered across various projects | 21:15 |
| thingee | aspiers: the spec was proposed in the repo | 21:15 |
| thingee | :) | 21:15 |
| mriedem | aspiers: if you have API needs in nova, then propose those as specs for nova | 21:15 |
| aspiers | thingee: yeah, not by me ;-) | 21:15 |
| thingee | ok, so I think we're saying, sure do this and use existing apis? | 21:15 |
| cdent | thingee: that is what it sounds like | 21:15 |
| thingee | and it shouldn't have been proposed spec as sdague mentioned earlier | 21:15 |
| mriedem | thingee: and if there are gaps in the API, propose project-specific specs to fill those gaps | 21:15 |
| _gryf | mriedem, I think all the api are in place, if we talking about nova | 21:16 |
| thingee | mriedem: +1 | 21:16 |
| alaski | mriedem: +1 | 21:16 |
| aspiers | yup, I agree too | 21:16 |
| jroll | mriedem: ++ | 21:16 |
| thingee | ok will leave a comment to have this spec abandoned | 21:16 |
| aspiers | well | 21:16 |
| thingee | #topic super scheduling | 21:16 |
| *** openstack changes topic to "super scheduling (Meeting topic: crossproject)" | 21:16 | |
| mriedem | aspiers: hunt down jwcroppe if you haven't already | 21:16 |
| aspiers | ok, thanks | 21:16 |
| thingee | fhermeni: hi! | 21:16 |
| fhermeni | hi there | 21:16 |
| samueldmq | it'd be great to have a single bp to use cross-projects (in the topic of changes) | 21:16 |
| thingee | #link https://review.openstack.org/#/c/210549/ spec | 21:16 |
| fhermeni | (first OS meeting, be cool) | 21:17 |
| *** doffm has joined #openstack-meeting-cp | 21:17 | |
| thingee | got a lot of first timers today :) | 21:17 |
| rockyg | fhermeni, we're generally a friendly bunch | 21:18 |
| fhermeni | we’ll see | 21:18 |
| elmiko | lol | 21:18 |
| thingee | so we have no josh harlow, so I want to understand where are we going with this spec. I guess a little intro and what you need from the general cross-project team | 21:18 |
| fhermeni | ok. Indeed, josh is afk (6am local time) | 21:19 |
| fhermeni | so there is 2 objectives | 21:19 |
| fhermeni | 1) expose a single entry for every scheduling aspect to allow to exhibit a higher perspective on scheduling expectations | 21:19 |
| fhermeni | 2) abstract the scheduler a bit to decouple from existing implementation | 21:20 |
| fhermeni | in that sense, you support the spec, you are suitable | 21:20 |
| bswartz | I haven't read the spec yet | 21:20 |
| bswartz | (but I will) | 21:20 |
| fhermeni | so we designed the spec for being extensible, with a very few orthogonal concepts | 21:21 |
| bswartz | does it at least acknowledge that the problem it's trying to solve is really hard? | 21:21 |
| fhermeni | yes of course | 21:21 |
| fhermeni | (I am writing VM placement algorithm since 10 years, I know it is hard ;)) | 21:21 |
| bswartz | okay | 21:21 |
| bswartz | the exception cases are likely to be where it gets tangled up | 21:22 |
| fhermeni | so we drafted a spec and wanted to have feedback from the involved communities | 21:22 |
| thinrichs | fhermeni: I couldn't tell from the spec if you were proposing having a scheduler that makes decisions using all the state/context/data/resources of many different services, or if you were proposing an abstraction that all (local) schedulers would implement. | 21:22 |
| bauzas | fhermeni: so we had kind of this discussion in the past during previous summits | 21:22 |
| lifeless | every summit | 21:22 |
| gordc | lol | 21:23 |
| bauzas | fhermeni: that's why something popped up called Gantt | 21:23 |
| lifeless | I don't think we can call it a summit without a scheduler session | 21:23 |
| fhermeni | it is an abstraction. The backend may or may not fullfil all the expectation (the extensibility concern) | 21:23 |
| bauzas | with the clear intent of splitting out the nova scheduler to be a separate project that others could consume | 21:23 |
| fhermeni | lifeless: it is not a surprise to me | 21:23 |
| *** sdake_ is now known as sdake | 21:23 | |
| bauzas | it was a dead-end for technical reasons at least, but also valid design concerns | 21:24 |
| aspiers | this sounds a bit like a blog post I wrote last year http://blog.adamspiers.org/2015/05/17/cloud-rearrangement/ | 21:24 |
| gordc | bauzas: gnatt isn't active anymore is it? | 21:24 |
| bauzas | gordc: nope, defunct | 21:24 |
| gordc | kk. good to know | 21:24 |
| fhermeni | as an academic, I observe there is about 50 VM placement algorithm that are proposed yearly. No one can propse or test a validation with OS because of the thigh coupling with Nova | 21:24 |
| bauzas | mostly because we weren't having those stable interfaces we were needing to have | 21:25 |
| *** diablo_rojo has quit IRC | 21:25 | |
| fhermeni | decoupling might help | 21:25 |
| gordc | fhermeni: is your scheduler completely original or does it leverage nova's scheduler? | 21:25 |
| bauzas | fhermeni: see, the real problem of that is 2 words : tech debt | 21:25 |
| fhermeni | bauzas: that is one of the point that require nova output | 21:25 |
| fhermeni | bauzas: does the language wrap nova features | 21:26 |
| *** mugsie has joined #openstack-meeting-cp | 21:26 | |
| thingee | so in the interest of time here, I agree with sdague and cdent that probably engagement should happen with nova here? I'm not really sure why this needs a cross-project spec. | 21:26 |
| fhermeni | bauzas: and ofc I cannot reply objectively because I am out of nova and an OS newbie | 21:26 |
| jroll | we keep saying vm placement, but this is about general resource placement, correct? | 21:26 |
| samueldmq | thingee: ++ | 21:26 |
| cdent | thingee: just to be clear sdague and I have different ideas on how that engagement should happen | 21:26 |
| rockyg | jroll, ++ | 21:26 |
| jroll | thingee: ++, I think if something like this gets pulled into nova, then it may require some cross-project work, but it needs to begin with nova | 21:26 |
| bauzas | cdent: and I agree with sdake | 21:27 |
| bauzas | damn | 21:27 |
| bauzas | sdague | 21:27 |
| thingee | cdent: sorry | 21:27 |
| cdent | hoisted on your own tab key bauzas ! | 21:27 |
| cdent | :) | 21:27 |
| bswartz | to do correct global placement is far larger than just nova | 21:27 |
| rockyg | bswartz, ++ | 21:27 |
| bswartz | you need information about storage, networking, compute, and information that exists nowhere in openstack today | 21:28 |
| rockyg | Congress would play a part | 21:28 |
| fhermeni | I am ok discussing with nova ofc. The language is quite simple so I am not affraid about its suitability but it is quite different from the pending spec I read about the proposed generic api for nova | 21:28 |
| rockyg | bswartz, you copied my keyboard! | 21:28 |
| samueldmq | thingee: I think it could be useful to add 'keywords' in a spec, that'd identify what projects are affected | 21:28 |
| nikhil | this will need to know about the placement of services too in such a case? | 21:28 |
| bauzas | bswartz: that's exactly why we need stable interfaces and a correct model for describing resources | 21:28 |
| thingee | samueldmq: sure | 21:28 |
| samueldmq | thingee: so it will be easier to identify proposals that only relate (mostly) to a single project | 21:29 |
| bauzas | both were not the case in nova a couple of months before, and that's gradually improving | 21:29 |
| rockyg | bauzas, which is why this is crossproject. More resources than just vms and compute nodes | 21:29 |
| samueldmq | thingee: I will propose a change to the spec template | 21:29 |
| bswartz | yeah I'm only arguing that while nova involvement is essential, this is in no-way nova-specific | 21:29 |
| thingee | fhermeni: so I would say figure out what happened with gnatt, see if there is a need to revive that. I'm not really hearing much people here having an interest with global placement scheduler though | 21:29 |
| bauzas | rockyg: so, see, I had this convo a lot of times before, and had no clear commitment on resource placement for others than vms | 21:29 |
| fhermeni | thingee: you don’t, don’t worry we have | 21:30 |
| * jroll is curious how many people here know the details of the nova scheduler rework | 21:30 | |
| fhermeni | thingee: watcher is an example | 21:30 |
| jroll | and the plans for the future | 21:30 |
| bauzas | people want x-project affinity for placing instances, but I haven't seen a clear interest for placing something else but instances | 21:30 |
| bswartz | thingee: I think we're all interested, but we've been burned by past failures and fear getting burned again | 21:30 |
| mriedem | jroll: take jaypipes out for lunch | 21:30 |
| jroll | mriedem: oh, I know the plans, but curious about others :) | 21:30 |
| elmiko | jroll: i don't | 21:30 |
| jroll | e.g. "is there a need to revive gaant" | 21:31 |
| rockyg | I'm aware but not in deep | 21:31 |
| jroll | it's too much to describe here, but I think it's good background reading for this topic | 21:31 |
| * jroll finds email | 21:31 | |
| jroll | #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html | 21:31 |
| rockyg | So, there are all sorts of issues in multiregion clouds that include other resources besides vm | 21:31 |
| jroll | folks may want to read that for some context | 21:31 |
| elmiko | jroll++ | 21:32 |
| rockyg | The ops community wants placement related to networking capabilities | 21:32 |
| bauzas | rockyg: I'm certainly sure, I just said I haven't seen user stories yet | 21:32 |
| fhermeni | indeed. For testbed for example, it is a prime feature | 21:32 |
| rockyg | And HPC want placement wrt data storage | 21:33 |
| jroll | so anyway, I agree that the super scheduler folks should chat more with the nova scheduler folks | 21:33 |
| bauzas | rockyg: that's affinity for vms | 21:33 |
| jroll | and figure out how this fits in, if at all | 21:33 |
| fhermeni | HPC as well indeed. network and cache affinity | 21:33 |
| elmiko | yea, i've seen some user asking question about data and compute affinity with respect to hadoop | 21:33 |
| rockyg | bauzas, but global rather than local | 21:33 |
| fhermeni | elmiko: indeed. VM close to the storage for data intensive workload | 21:33 |
| thingee | cdent: can we get some folks interested in engaging with this spec? I think you and sdague are the only from nova that have responded to the spec | 21:33 |
| elmiko | fhermeni: right, and asking for more options in sahara to control the affinity | 21:33 |
| bauzas | could we stop making confusion between x-project affinity for placing vms, vs. placing things like volumes ? | 21:34 |
| bauzas | thingee: I made a very clear statement too | 21:34 |
| cdent | I think it is pretty clear that bauzas should be actively contributing to the discussion on the spec | 21:34 |
| cdent | especially to clarify some of the thing he just clarified here | 21:34 |
| rockyg | cdent, ++ | 21:34 |
| bauzas | I don't see the need for that being a x-project spec honestly | 21:35 |
| rockyg | I'd love to see a session on this at the design summit | 21:35 |
| bauzas | at least now | 21:35 |
| cdent | there's a vast amount of assumptions that people make about the use cases and nobody seems to really agree | 21:35 |
| *** thinrichs has quit IRC | 21:35 | |
| thingee | ok, anyone disagree with bauzas? | 21:35 |
| jroll | bauzas: ++ this needs to start in nova and expand | 21:35 |
| thingee | going | 21:35 |
| jroll | the nova work is making rooms for other resources like network and volumes | 21:35 |
| thingee | ... | 21:35 |
| thingee | going | 21:35 |
| cdent | fdafda | 21:35 |
| fhermeni | ok to me | 21:35 |
| rockyg | gone! | 21:35 |
| jroll | cdent has opinions it seems? | 21:35 |
| cdent | jroll: I do, but not really on where the talk happens | 21:36 |
| thingee | #agreed fhermeni and harlow to work with nova-scheduler folks to further this along to later propose cross-project | 21:36 |
| *** thinrichs has joined #openstack-meeting-cp | 21:36 | |
| jroll | cdent: right on | 21:36 |
| thingee | fhermeni: thanks | 21:36 |
| fhermeni | with pleasure | 21:36 |
| thingee | #topic rolling upgrades | 21:36 |
| *** openstack changes topic to "rolling upgrades (Meeting topic: crossproject)" | 21:36 | |
| thingee | kencjohnston: hi | 21:36 |
| bauzas | fhermeni: http://eavesdrop.openstack.org/#Nova_Scheduler_Team_Meeting | 21:36 |
| kencjohnston | howdy | 21:36 |
| thingee | #link https://review.openstack.org/#/c/290977/1 spec | 21:36 |
| kencjohnston | third first timer... | 21:37 |
| elmiko | nice =) | 21:37 |
| kencjohnston | This spec was copied from a Product Work Group developed User Story | 21:37 |
| kencjohnston | with the intent of providing common problem description and use cases for upgrade improvements | 21:38 |
| bknudson | we didn't get rolling schema upgrades into keystone last release. | 21:38 |
| kencjohnston | realizing that work is underway in many projects on this front | 21:38 |
| *** dansmith has joined #openstack-meeting-cp | 21:38 | |
| *** thinrichs has quit IRC | 21:38 | |
| thingee | so I think dansmith and sdague bring up a good point that this should reflect current use cases that are already in flight and in progress. | 21:39 |
| thingee | we should start there | 21:39 |
| kencjohnston | thingee yeah happy to do so and I wlll incorporate their feedback | 21:39 |
| kfox1111 | this is similar to that ops spec. | 21:39 |
| thingee | however, this spec needs ownership of someone technical that can surface the problem, and agreed concepts of a solution as well as existing shared libraries like oslo.versionobjects | 21:39 |
| kfox1111 | but more narrow in scope. | 21:39 |
| thingee | to be clear, the product working group is trying to engage more with the community in the use cases they receive from things like the user survey. | 21:40 |
| kencjohnston | thingee +1 | 21:40 |
| thingee | but this was received the wrong way I think. mostly because it was looked as a wish list since some of the stuff is not the current direction today. | 21:41 |
| gordc | we already have a tag for this? https://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html | 21:41 |
| thingee | However, I do think it would be good if the product working group was able to find someone who wants to own these repos from the technical side | 21:41 |
| mriedem | gordc: yeah i was going to point that out | 21:41 |
| kencjohnston | thingee Correct, and that is on me. I misunderstood some important direction thingee provided me on that front. | 21:41 |
| gordc | are we trying to find owners for each project? | 21:42 |
| mriedem | if a project doesn't have the rolling upgrades tag, work with each project on what it takes to add rolling upgrade support | 21:42 |
| thingee | gordc: no, and I need to document this better from cross-project perspective... | 21:42 |
| nikhil | is this a guideline spec? | 21:42 |
| nikhil | or technical guideline spec? (first one being generic guideline) | 21:43 |
| thingee | so cross-project specs I feel like should be general problem, general solutions and linking to existing libraries if they exist. | 21:43 |
| *** samapthP has quit IRC | 21:43 | |
| nikhil | or a use these existing tools and stop adding tech debt to my prj spec? | 21:43 |
| thingee | individual projects can do their own spec if they need to hash out particular details that involve their individual services. | 21:43 |
| nikhil | so all three then | 21:43 |
| jroll | seems like most CP specs specify an end goal and recommended solutions | 21:43 |
| jroll | the end goal here is clear - the tag | 21:43 |
| thingee | but we need these general ideas and solutions surfaced up somewhere, instead of what mriedem suggested of having to figure things out and dig for this information. | 21:43 |
| samueldmq | what is a cross-project spec? | 21:43 |
| jroll | the recommended solutions is less clear, as we can't just copy/paste code | 21:44 |
| samueldmq | what does define something as a cp spec? | 21:44 |
| nikhil | yes, then we'd remove the Proposed solution Heading from the spec IMHO | 21:44 |
| thingee | samueldmq: I think it's something that involves more than one project. | 21:44 |
| jroll | but rather should have things that get you there - if you use RPC, you should version that properly. you should do expand/contract style migrations. etc. | 21:44 |
| dansmith | personally, I really don't want us to have a spec to cover all of upgrades | 21:44 |
| dansmith | if we need a spec to distill best practices for versioned RPC, then we can do that | 21:44 |
| nikhil | I just saw the previous 2 specs and the comment from Dan on this one and was confused | 21:44 |
| dansmith | (for example) | 21:45 |
| jroll | dansmith: ++ | 21:45 |
| gordc | dansmith: + | 21:45 |
| thingee | dansmith: sure, if you want to call it that, that's fine with me | 21:45 |
| jroll | there's a number of things (e.g. RPC) that projects do that make upgrades hard | 21:45 |
| thingee | dansmith: that's not different from the logging spec best practice | 21:45 |
| thingee | or eventlet | 21:45 |
| samueldmq | thingee: I got that question after reading cdent's comment in patchset 2 at https://review.openstack.org/#/c/257809/ | 21:45 |
| fungi | yeah, "upgrades" seems like a blanket idea, which can mean many different facets of design to different projects | 21:45 |
| jroll | we could clarify what things those are, and how a project might solve them | 21:45 |
| mriedem | like log guidelines i guess? http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html | 21:45 |
| jroll | (whether that's one spec or many, I'm not opinionated) | 21:45 |
| dansmith | jroll: right, versioned rpc applies to a lot of projects.. versionedobjects will be picked up by fewer of those, and some will use neither | 21:45 |
| thingee | mriedem: exactly what I was mentioning above :) thanks | 21:46 |
| jroll | yep | 21:46 |
| mriedem | thingee: ah you beat me to logging :) | 21:46 |
| jroll | dansmith: there's other solutions too, like "don't change the rpc wire protocol" - crazy but it totally would work | 21:46 |
| jroll | :P | 21:46 |
| thingee | dansmith: I think a best practice is good. | 21:46 |
| dansmith | jroll: right, which is why I kinda hesitate to do any of this, but I think of all the topics, versioned RPC best practices is probably the widest applicability | 21:46 |
| gordc | jroll: that's what we use :) | 21:46 |
| jroll | I do question if a spec is needed for best practices, or if this should be more like a (project guide?) docs thing | 21:47 |
| rockyg | Also the upgrade tag is not the final resolution here, but the indicator that it was reached | 21:47 |
| jroll | or a blog, or a wiki | 21:47 |
| fungi | etching the protocol in stone without possibility of future revision encourages unsavory sorts of data serialization with nasty security vulnerability surface area though | 21:47 |
| nikhil | jroll: ++ | 21:47 |
| jroll | fungi: I was about 10% serious :) | 21:47 |
| dansmith | jroll: yeah, I've tended to put this kind of stuff in blogs | 21:47 |
| fungi | heh | 21:47 |
| thingee | jroll: as mriedem pointed out earlier, this isn't different from best practice of logging or eventlet which we cover today in our repo | 21:47 |
| dansmith | jroll: I'd rather leave specs and TC-blessed things for required stuff | 21:47 |
| jroll | thingee: okay, that's fair precedent | 21:48 |
| jroll | I don't have a strong opinion, I guess. writing things down is what's important to me | 21:48 |
| nikhil | Well I feel that many developers pick cp spec and just assume it to be source of truth | 21:48 |
| * thingee thinks if there is disagreement of what should go in this repo, he should propose what should go in this repo in the project team guide | 21:48 | |
| thingee | dansmith: ^ | 21:48 |
| nikhil | I feel we need to decouple the technical details and emphasize more on best practices | 21:48 |
| fungi | i feel like a lot of the disagreements over cross-project specifications have to do with meaning people are reading into the term "specification" | 21:48 |
| dansmith | nikhil: right, I'd hate for someone to read a spec, think it doesn't work for them, and decide not to pursue upgrades because that's the required solution | 21:48 |
| rockyg | nikhil, if not source of truth, director to the various project sources of truth | 21:48 |
| thingee | and then we can hash it out there. | 21:48 |
| thingee | dansmith: I mean we have precedent of best practices, but we don't have to keep doing that. | 21:49 |
| jroll | fungi: that's a good question | 21:49 |
| thingee | but I think rolling upgrades is a common problem people are trying to solve | 21:50 |
| dansmith | thingee: yeah, I'm not super familiar with the PTG, so I can't really say, but sounds reasonable | 21:50 |
| rockyg | fungi, ++ | 21:50 |
| nikhil | thingee: I like CP specs, but it would be pretty good survey white paper sort of thing that has pointers to best articles or something of such sorts | 21:50 |
| gordc | i don't think it's necessarily a bad thing we realised everything so far is probably overreaching. we're just confirming they are not required for everyone | 21:50 |
| thingee | dansmith: what's ptg here? :P | 21:50 |
| fungi | nova added specifications, then neutron, then others followed suit. then someone thought we should maybe have something like specs to coordinate stuff across multiple projects, but still called that a "specification" | 21:50 |
| thingee | dansmith: oh pwg? | 21:50 |
| thingee | heh | 21:50 |
| dansmith | thingee: project team guide you mentioned above? | 21:50 |
| samueldmq | fungi: yes, either meaning of specification or cross-project :) | 21:50 |
| thingee | dansmith: oh gotcha | 21:51 |
| dansmith | thingee: I think I misread, | 21:51 |
| dansmith | you meant use the PTG to describe what CP specs are for? | 21:51 |
| rockyg | Can't remember which project, but they have RFEs for non developers to describe their needs | 21:51 |
| thingee | dansmith: yes, because there are disagreements here it seems. | 21:51 |
| nikhil | rockyg: ack and I agree to what you said | 21:51 |
| jroll | rockyg: neutron and ironic | 21:51 |
| thingee | sean dague isn't present, I know he had disagreements here. | 21:52 |
| rockyg | And this doc is pretty much an RFE. | 21:52 |
| samueldmq | what does RFE stand for ? | 21:52 |
| fungi | rfe is also known broadly in free software as a "wishlist item" | 21:52 |
| dansmith | request for enhancement | 21:52 |
| rockyg | Request for Enahancement | 21:52 |
| samueldmq | thanks | 21:53 |
| fungi | as in "here's something we'd like to see happen, but we don't know how it should be done or who will actually do it" | 21:53 |
| samueldmq | and I agree it makes sense to have them | 21:53 |
| samueldmq | if we're going to get requirements from non-dev people | 21:53 |
| rockyg | and once the RFE is fleshed out with the stuff we've talked about, either individual project specs or cross project specs or both can be generated by devs | 21:53 |
| thingee | #action thingee to define cross-project specs in project team guide | 21:53 |
| dansmith | fungi: right, usually only happens if money is exchanged somewhere :) | 21:53 |
| samueldmq | rockyg: ++ | 21:53 |
| thingee | kind of a bummer that we have to go back to this, but I don't want us to keep getting blocked here. | 21:54 |
| samueldmq | thingee: nice! should our spec template include something as well? | 21:54 |
| carolbarrett | rockyg +1 | 21:54 |
| kencjohnston | fungi I do want to clarify there is commitment from representatives of companies int he PWG to work on this (this being upgrades) | 21:54 |
| bknudson | I think part of the problem is that as a volunteer org we need devs to be able to work on it | 21:54 |
| carolbarrett | kencjohnston: +1 | 21:54 |
| thingee | #topic stale specs | 21:55 |
| *** openstack changes topic to "stale specs (Meeting topic: crossproject)" | 21:55 | |
| *** mriedem has quit IRC | 21:55 | |
| rockyg | I think we have devs, but not senior devs. We need the cores and drivers to architect the right directions to go with this | 21:55 |
| samueldmq | bknudson: agreed, starting on getting RFEs and writting specs down | 21:55 |
| jroll | so nobody is arguing that we should or should not document best practices for projects that want to do upgrades, rather where it should be | 21:55 |
| thingee | #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089115.html | 21:55 |
| carolbarrett | bknudson: I believe there are devs working on it today and we can continue to ask them to work on this | 21:55 |
| fungi | kencjohnston: carolbarrett: awesome. though it's generally helpful to have the people who will be working on it write up their proposal for how they'd do it so there's more to review | 21:55 |
| thingee | I've listed some stale specs here. | 21:55 |
| thingee | lifeless has a bit :) | 21:55 |
| thingee | jroll: I'm just going to define what the cross-project specs should be for. We can start there. | 21:56 |
| jroll | thingee: cool | 21:56 |
| gordc | thingee: i would abandon them and let them reopen if someone actually cares about it | 21:56 |
| lifeless | thingee: I do :( | 21:56 |
| thingee | so this involves the TC to abandon them. I don't have powers. | 21:56 |
| thingee | but I wanted people to be aware | 21:57 |
| lifeless | backwards compat is ongoing | 21:57 |
| thingee | and revive whatever you care about | 21:57 |
| gordc | thingee: ah i see. :( | 21:57 |
| samueldmq | gordc: ++ | 21:57 |
| lifeless | I need to update it | 21:57 |
| thingee | lifeless: ok! | 21:57 |
| nikhil | thingee: you open to running the bot thing that auto-abandons if not active for 2/3 weeks? | 21:57 |
| lifeless | testr isn't on the map right now, though it is still something I want to do | 21:57 |
| rockyg | So, I'm willing to abandon mine if I can't update it by the summit. I can always come back to it. | 21:57 |
| nikhil | thingee: ah, nvm | 21:57 |
| thingee | #topic open discussion | 21:57 |
| *** openstack changes topic to "open discussion (Meeting topic: crossproject)" | 21:57 | |
| thingee | cdent: ^ | 21:57 |
| fungi | are there really enough cp specs that someone can't just manually abandon them when they seem to be going nowhere any more? | 21:57 |
| samueldmq | thingee: fyi I've talked to ayoung and he agrees with abandoning No global admin (Adam Young) - https://review.openstack.org/#/c/205629 | 21:58 |
| cdent | thanks thingee: I just wanted to point people at this thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/088658.html | 21:58 |
| jroll | fungi: only the owner and the TC has abandon rights, afaik | 21:58 |
| jroll | cdent: this one is so much fun | 21:58 |
| kfox1111 | I've got two specs that are still very important to our group, but I've not had time this cycle to follow up on, since its been a huge amount of work to try and get through. | 21:58 |
| cdent | the death (or dying) of wsme impacts several projects and there's been some discussion about how to formalize or guide people in doing the a better thing | 21:58 |
| kfox1111 | I'm about to deliver a production system so I'm hoping I'll have time coming up to push some more. | 21:58 |
| cdent | there's been some discussion of announcing that projects _must_ migrate | 21:58 |
| fungi | jroll: we _can_ fix that with acls, though either way the tc needs to be involved in the discussion of who should abandon changes for the repository they control and how | 21:59 |
| nikhil | heads up: We're having a discussion for quotas impl to be separate service or a lib and folks should expect a ML email from someone from the WG soonish. | 21:59 |
| cdent | (in say N months) | 21:59 |
| elmiko | cdent: must migrate, as in away from wsme? | 21:59 |
| cdent | a thing like that seems like it would be vaguely cross-project | 21:59 |
| jroll | fungi: yeah, just pointing out why thingee hasn't done it I guess :) | 21:59 |
| cdent | elmiko: yes, but it is just an idea, not a decision | 21:59 |
| jroll | cdent: must? yikes | 21:59 |
| elmiko | cdent: ack, just trying to understand better | 21:59 |
| cdent | a strawman | 21:59 |
| jroll | I don't remember seeing must in that thread, rather should | 21:59 |
| thingee | one minute | 21:59 |
| jroll | (I agree, fwiw, I just don't want to force people to do it) | 21:59 |
| fungi | if the tc wants to grant thingee the ability to abandon/restore changes on that repo, it's easy to solve in gerrit with a line in an acl | 22:00 |
| fungi | i'm happy to write the change to implement it | 22:00 |
| bknudson | I vote to give thingee the ability to abandon changes | 22:00 |
| rockyg | Well, if no one is maintaining it, there will be bitrot. So migration is a question of when, not if | 22:00 |
| elmiko | must migrate does seem strong, but providing some nice guides on how to migrate would be awesome! (i know, more work) | 22:00 |
| cdent | elmiko: well exactly | 22:00 |
| thingee | ok that's time | 22:00 |
| thingee | thanks everyone for attending! | 22:00 |
| nikhil | thanks | 22:01 |
| elmiko | thanks thingee | 22:01 |
| thingee | #endmeeting | 22:01 |
| cdent | that was a biggun | 22:01 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 22:01 | |
| openstack | Meeting ended Tue Mar 15 22:01:05 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 22:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/crossproject/2016/crossproject.2016-03-15-21.01.html | 22:01 |
| samueldmq | thanks | 22:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/crossproject/2016/crossproject.2016-03-15-21.01.txt | 22:01 |
| jroll | rockyg: well, those projects would need to be responsible for keeping it up (e.g. lucas is only helping because ironic uses it) | 22:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/crossproject/2016/crossproject.2016-03-15-21.01.log.html | 22:01 |
| *** harlowja has joined #openstack-meeting-cp | 22:01 | |
| rockyg | jroll, yup. | 22:01 |
| elmiko | cdent: imo, good case for improved api-wg example code ;) | 22:01 |
| cdent | :) | 22:01 |
| rockyg | ++ | 22:01 |
| *** raildo-afk is now known as raildo | 22:02 | |
| rockyg | So, really, spend the time to document how to migrate rather than maintaining the code. | 22:02 |
| elmiko | i should have something fun to show off at summit | 22:02 |
| *** gordc has left #openstack-meeting-cp | 22:03 | |
| *** shamail has quit IRC | 22:04 | |
| *** fhermeni has left #openstack-meeting-cp | 22:04 | |
| *** raildo is now known as raildo-afk | 22:06 | |
| *** sdake has quit IRC | 22:09 | |
| *** rockyg has quit IRC | 22:10 | |
| *** dims_ has joined #openstack-meeting-cp | 22:11 | |
| *** david-lyle has quit IRC | 22:13 | |
| *** dims has quit IRC | 22:14 | |
| *** cdent has quit IRC | 22:15 | |
| *** dims has joined #openstack-meeting-cp | 22:16 | |
| *** dims_ has quit IRC | 22:17 | |
| *** beekhof has joined #openstack-meeting-cp | 22:23 | |
| *** ninag has quit IRC | 22:47 | |
| *** dims has quit IRC | 23:06 | |
| *** carolbarrett has quit IRC | 23:25 | |
| *** tyr_ has quit IRC | 23:26 | |
| *** dtroyer has left #openstack-meeting-cp | 23:36 | |
| *** sdake has joined #openstack-meeting-cp | 23:45 | |
| *** harlowja has quit IRC | 23:47 | |
| *** guessi has joined #openstack-meeting-cp | 23:51 | |
| *** guessi has left #openstack-meeting-cp | 23:55 | |
| *** sdake_ has joined #openstack-meeting-cp | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!