*** 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!