| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-14 | |||
| 12:46:35 | cdent | internet germs are the worst | |
| 12:46:49 | gibi | efried_cya_jan: o/ | |
| 12:48:19 | openstackgerrit | Raghad Qutteneh proposed openstack/nova master: Allow force-delete to delete instance in task_state block_device_mapping https://review.openstack.org/527951 | |
| 12:53:13 | gibi | efried_cya_jan: if you are here I have a question. Do I understand correctly that the GET allocation_candidate API does not handle nested RPs yet? | |
| 12:53:57 | efried_cya_jan | gibi That's correct. That's a major piece we need before we can slot in the granular resource requests work. | |
| 12:54:16 | gibi | efried_cya_jan: OK, cool | |
| 12:54:23 | efried_cya_jan | gibi: jaypipes is on the hook for that. | |
| 12:55:13 | gibi | OK | |
| 13:48:55 | kashyap | gibi: Thanks for the (non-null) pointer :-) | |
| 13:52:27 | mriedem | oh crap today is thursday huh | |
| 13:52:32 | mriedem | gibi: can you run the meeting? | |
| 13:53:12 | gibi | mriedem: sure | |
| 13:54:04 | mriedem | thanks. i'll update the agenda quick. | |
| 13:54:09 | gibi | mriedem: thanks, that helps | |
| 13:54:17 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Enable limiting GET /allocation_candidates https://review.openstack.org/513526 | |
| 13:57:46 | mriedem | done https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 13:58:09 | gibi | cool | |
| 14:00:17 | gibi | nova meeting is about to start on @openstack-meeting | |
| 14:00:29 | cdent | mriedem: just wanted to say: thanks for trying to keep it real in the cycle length thread. | |
| 14:00:43 | mriedem | np | |
| 14:01:05 | cdent | I'm trying to gather my thoughts, but not having much success | |
| 14:02:16 | mriedem | i think i will have to move on today from that thread | |
| 14:02:42 | cdent | that would be a bummer, you are uniquely positioned to, uh, keep it real | |
| 14:04:12 | mriedem | i don't have the energy to fight that battle, and it sounds like the majority of people (ops, users?) seem to like the idea. i think it will turn out to be more than what they bargained for (some things they'll lose, some things they won't get out of it) | |
| 14:05:44 | mriedem | we'll do what we need to do for nova, if that means intermediate releases just to give us a deadline to work toward even if no one ever consumes it | |
| 14:06:56 | cdent | i definitely think that if it happens hard interediate deadlines will be _very_ important | |
| 14:07:40 | edleafe | so if you don't meet a deadline, would that mean waiting a year? Or what? | |
| 14:09:58 | edleafe | just wondering how "dead" such a deadline would be | |
| 14:10:33 | cdent | as you know, I think all deadlines are made up and thus fungible, but they are useful encouragement tools? | |
| 14:11:14 | edleafe | IMO, deadlines work as sticks, not carrots. | |
| 14:12:02 | cdent | maybe call them boundaries? | |
| 14:13:19 | mriedem | jaypipes: i put this up for that dbdeadlock issue https://review.openstack.org/#/c/527836/ - not sure that's best, but it's a thing | |
| 14:13:40 | mriedem | edleafe: i think we'd do intermediate releases so we could have more than 1 freeze in a year | |
| 14:14:19 | mriedem | so either 1 or 2 intermediate releases (6 month or 4 month between them), and do our normal spec review, spec freeze, code churn, feature freeze, stability minute, then open up for new specs again | |
| 14:14:31 | mriedem | i don't think we can freeze out specs for an entire year, | |
| 14:14:45 | mriedem | and i don't think we can leave spec reviews open for an entire year and focus on actually getting things done | |
| 14:14:52 | edleafe | mriedem: so would they be Rocky I, Rocky II, ... | |
| 14:15:11 | mriedem | rocky IV is where we fight the mirantis guys | |
| 14:15:18 | mriedem | us guys, | |
| 14:15:19 | mriedem | and yous guys | |
| 14:16:37 | mriedem | having said that, i don't know what we'd do for upgrade testing with intermediate releases | |
| 14:16:53 | mriedem | do you do queens->rocky.1, queens->rocky.2, or queens->rocky.1->rocky.2? | |
| 14:17:09 | mriedem | today it would be the former because of how the CI system works on branches | |
| 14:17:31 | mriedem | i assume we would use minor version bumps for intermediate releases | |
| 14:17:34 | edleafe | yuck | |
| 14:17:46 | cdent | blargh | |
| 14:17:49 | mriedem | so rocky 1 would be 17.1.0 | |
| 14:17:53 | mriedem | if rocky GA was 18.0.0 | |
| 14:17:56 | mriedem | but, | |
| 14:18:08 | mriedem | that gets tricky if we actually need to backport something to stable/pike which would normally be a minor update | |
| 14:18:12 | mriedem | like a schema migration | |
| 14:19:09 | mriedem | likely a question i'll need to ask about in "the thread" | |
| 14:20:18 | stephenfin | efried_cya_jan: See your comments now. I'll address them shortly | |
| 14:20:30 | stephenfin | Fwiw, I'll keep trying to do the minimum possible amount to keep everyone happy and get it in (ignored most of my own comments/preferences for this reason) | |
| 14:20:57 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Refactor encryptor attach and detach calls https://review.openstack.org/460243 | |
| 14:20:58 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Introduce disk encryption config classes https://review.openstack.org/464008 | |
| 14:20:58 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP libvirt: Use QEMU's native LUKS support https://review.openstack.org/523958 | |
| 14:24:22 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP libvirt: Use QEMU's native LUKS support https://review.openstack.org/523958 | |
| 14:26:08 | openstackgerrit | Merged openstack/nova master: [placement] add name to resource provider create error https://review.openstack.org/526710 | |
| 14:26:14 | openstackgerrit | Merged openstack/nova master: [placement] Add 'Location' parameters in API ref https://review.openstack.org/521541 | |
| 14:26:20 | openstackgerrit | Merged openstack/nova master: doc: link in some Sydney summit content https://review.openstack.org/526587 | |
| 14:27:09 | dansmith | bauzas: need you to look at https://review.openstack.org/#/c/527799/2 | |
| 14:30:01 | takashin | mriedem: The compute API microversion 2.57 was added in "Deprecate file injection" https://review.openstack.org/#/c/522027/ . | |
| 14:30:06 | takashin | mriedem: But I cannot find a patch for microversion 2.57 in python-novaclient. Would you submit the patch? | |
| 14:31:11 | takashin | mriedem: Are you around? | |
| 14:33:22 | jaypipes | mriedem: ok, looking at it now. | |
| 14:37:04 | mriedem | takashin: i plan on working on that novaclient patch today | |
| 14:37:16 | mriedem | takashin: didn't get the time yesterday - too much other stuff going on | |
| 14:38:26 | takashin | mriedem: okay. Thanks. | |
| 14:43:53 | jroll | mriedem: we should talk about releases/upgrades at PTG if this goes through, ironic has some experience with that | |
| 14:46:41 | cdent | jroll: are you back on the scene? | |
| 14:46:48 | cdent | as in: gonna be in dublin? | |
| 14:46:54 | mriedem | jroll: yeah i was going to ask in the thread to get the experience of other teams already doing it | |
| 14:47:27 | jroll | cdent: waiting for approval but hopefully yes | |
| 14:47:33 | jroll | mriedem: ++ | |
| 14:49:55 | mriedem | i didn't want to ask jroll that question | |
| 14:50:05 | mriedem | something something "don't ask a question you don't already know the answer to" | |
| 14:50:20 | jroll | you don't wanna know anyway | |
| 15:01:02 | stephenfin | mdbooth: So if I'm understanding this correctly, this fixes and issue we'd only see when using microversion < 2.25? https://review.openstack.org/#/c/524681/ | |
| 15:09:21 | cdent | zounds, an email thread has drawn dansmith, this is a banner day | |
| 15:09:52 | dansmith | cdent: I really really wanted to ignore this one even more than usual | |
| 15:10:14 | cdent | dansmith: I'm glad you didn't. | |
| 15:15:34 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (usage) https://review.openstack.org/520603 | |
| 15:16:01 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance https://review.openstack.org/516899 | |
| 15:16:02 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (trait) https://review.openstack.org/520605 | |
| 15:16:28 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (aggregate) https://review.openstack.org/520608 | |
| 15:16:49 | dansmith | apparently I'm just replying to edleafe's emails today | |
| 15:16:54 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Add functional tests for resource class API https://review.openstack.org/524506 | |
| 15:16:58 | mriedem | sdague: bauzas: can you take a look at these ocata backports? https://review.openstack.org/#/q/topic:bug/1732947+status:open+branch:stable/ocata - holding up newton backports for the same changes which is holding up newton eol | |
| 15:17:15 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (inventory) https://review.openstack.org/520613 | |
| 15:17:29 | bauzas | mriedem: roger, captain | |
| 15:17:34 | mriedem | bauzas: sdague: and this ocata one https://review.openstack.org/#/c/526426/ | |
| 15:17:35 | mriedem | same story | |
| 15:17:49 | mriedem | tonyb: i sent an email to the dev list about what i think needs to happen to get nova to newton-eol | |
| 15:19:16 | jianghuaw_ | hi bauzas, need your help to look at this patch: https://review.openstack.org/#/c/516899/ | |
| 15:19:36 | mriedem | tonyb: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125592.html | |
| 15:24:19 | lyarwood | mriedem: did we also want to fix https://review.openstack.org/#/c/526426/1 in newton? | |
| 15:25:30 | lyarwood | mriedem: ah nvm, you listed the stable/newton version in that query, ignore me | |
| 15:29:04 | cdent | shiny pretty edleafe | |
| 15:32:22 | mriedem | i did think about the impact to the deprecation policy this morning when i got up, glad dan mentioned that | |