| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-04 | |||
| 13:03:46 | bauzas | I'm not really happy with that, hence my comment saying to maybe wait for custom RCs :) | |
| 13:03:53 | sfinucan | bauzas: well, technically QEMU - libvirt just wraps it | |
| 13:06:20 | bauzas | johnthetubaguy: sfinucan: just -1d it again | |
| 13:08:09 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: SPICE native client support https://review.openstack.org/442040 | |
| 13:09:59 | johnthetubaguy | bauzas: don't feel we are being great at giving suggestions how to fix the spec right now though | |
| 13:14:20 | bauzas | johnthetubaguy: I tried to explain my preferrence about providing custom resource classes against very specific image props | |
| 13:16:30 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: Added PCI NUMA policies https://review.openstack.org/390520 | |
| 13:28:58 | mriedem | is everyone excited for a fun spec review day?! | |
| 13:29:39 | peter-hamilton | mriedem: indeed! | |
| 13:29:39 | artom | Doc's appointment this morning, but will try to participate this afternoon | |
| 13:29:40 | mriedem | i see johnthetubaguy has been having fun | |
| 13:30:22 | johnthetubaguy | yeah, I abandoned a bunch of left alone specs | |
| 13:30:39 | johnthetubaguy | only three pages of joy now | |
| 13:30:44 | mriedem | awesome | |
| 13:39:16 | openstackgerrit | Maciej Szankin proposed openstack/nova-specs master: Add remove-nova-cert spec https://review.openstack.org/448882 | |
| 13:45:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'shell' commands https://review.openstack.org/432280 | |
| 13:45:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'agent' commands https://review.openstack.org/450795 | |
| 13:45:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'host' commands https://review.openstack.org/453175 | |
| 13:45:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'project', 'account' commands https://review.openstack.org/453174 | |
| 13:45:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate 'log' commands https://review.openstack.org/453176 | |
| 13:48:36 | bauzas | mriedem: I guess you don't know https://en.wikipedia.org/wiki/L%C3%A9onard_%28comics%29 ? | |
| 13:48:56 | mriedem | nope | |
| 13:49:38 | bauzas | mriedem: because the disciple always says "I serve science and it's my joy" | |
| 13:52:58 | dane-fichter | peter-hamilton: anything relevant so far? | |
| 13:53:18 | peter-hamilton | dane-fichter: not yet :) | |
| 13:53:36 | dane-fichter | peter-hamilton: cool. got caught in traffic | |
| 13:54:15 | mriedem | peter-hamilton: dane-fichter: you guys might want to review https://review.openstack.org/#/c/448882 | |
| 13:54:23 | mriedem | for dropping the nova-cert service | |
| 13:54:32 | peter-hamilton | mriedem: looking now | |
| 13:54:37 | dane-fichter | mriedem: we'll take a look, thanks | |
| 13:58:02 | tdurakov | hi, folks, there will be no live-migration meeting this week | |
| 13:58:10 | bhagyashris | johnthetubaguy: Hi, Could you please review patch https://review.openstack.org/#/c/409644/ ? if you have free time. | |
| 14:01:03 | sdague | johnthetubaguy: why did you think 400 instead of 404 - https://review.openstack.org/#/c/448882 ? | |
| 14:01:48 | johnthetubaguy | sdague: didn't consider 404 honestly | |
| 14:02:02 | johnthetubaguy | sdague: I was seeing this as the implementation removed, not the API changed | |
| 14:03:32 | sdague | well, we could always be tricksie and use 410 then | |
| 14:03:59 | sdague | but I though that 404 is what the whole system returns if you go fetch /foobar | |
| 14:06:43 | johnthetubaguy | sdague: oh, 410 = gone, I had not come across that. I guess it depends if we want to pretend if the old API never existed or not. 410 would help know you got the correct URL, as you always used to, its just the server that has change and no longer wants to server up that API | |
| 14:08:03 | sdague | johnthetubaguy: yeh, though my hesitation on 410 is that no tool is every designed to understand it :) | |
| 14:08:48 | johnthetubaguy | sdague: yeah, thats good and bad in equal measure I guess | |
| 14:09:06 | sdague | yep | |
| 14:09:17 | sdague | but, more importantly, I think it requires us to have a stub hanging around | |
| 14:09:23 | sdague | vs. just deleting the handler | |
| 14:09:32 | sdague | and, I'd rather just delete the handler | |
| 14:17:43 | cdent | sdague, johnthetubaguy I reckon deleting the handler has most win (because of getting to remove cleanly) | |
| 14:17:54 | mriedem | do i need a spec to propose deleting the os-pci api code even though it's never been enabled or exposed? | |
| 14:18:20 | cdent | however 410 would also be fine. Not that many tools actually "understand" response codes. They just react to them. | |
| 14:19:03 | cdent | mriedem I think you have to ask mriedem about that | |
| 14:19:08 | mriedem | damn | |
| 14:19:10 | cdent | and then collapse in on yourself | |
| 14:20:09 | cdent | mriedem speaking of needing specs: https://review.openstack.org/#/c/448791/ needs one, I guess? | |
| 14:20:57 | mriedem | probably yeah | |
| 14:21:08 | mriedem | i don't want us to get lax on api impacts for placement | |
| 14:21:13 | cdent | fair | |
| 14:22:02 | mriedem | clarkb: with the UCA change in devstack we get libvirt 2.5 right? do you know if we also are going to get an updated qemu? and if so, which version? | |
| 14:23:03 | sdague | mriedem: we will | |
| 14:23:35 | mriedem | just wondering if it's new enough to cover what's in https://review.openstack.org/#/c/437070/ | |
| 14:23:41 | mriedem | ^ requires qemu 2.6 | |
| 14:26:24 | sdague | mriedem: https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/ocata-staging/+index?batch=75&direction=backwards&start=150 | |
| 14:26:30 | sdague | guessing, I think that would be 2.8 | |
| 14:32:32 | mriedem | lyarwood: this introduced a bug https://review.openstack.org/#/c/393901/ | |
| 14:32:43 | mriedem | encryptor may not be defined when logged | |
| 14:35:22 | lyarwood | mriedem: bug #? The os-brick differs there for some reason.. | |
| 14:35:32 | mriedem | lyarwood: no bug yet, i can open one | |
| 14:36:17 | lyarwood | mriedem: thanks, I'll get it backported, btw I'm looking to drop all of this code in Pike via https://review.openstack.org/#/c/391597/ | |
| 14:37:17 | mriedem | heh that's not really a bug | |
| 14:38:12 | lyarwood | mriedem: ah just code review? I assumed it came from a customer, just reading the scollback it looks like you are reviewing the QEMU LUKS spec right? | |
| 14:38:37 | mriedem | yes | |
| 14:38:46 | lyarwood | kk, don't worry about the bug then | |
| 14:39:01 | mriedem | already written | |
| 14:39:07 | mriedem | i meant your os-brick encryptors change was not a bug | |
| 14:39:14 | mriedem | to make nova use os-brick encryptors code | |
| 14:39:15 | mriedem | is not a bug | |
| 14:39:25 | mriedem | the NameError is definitely a bug :) | |
| 14:39:28 | openstack | Launchpad bug 1679717 in OpenStack Compute (nova) "Potential for NameError when logging volume encryptor" [Undecided,New] | |
| 14:39:28 | mriedem | https://bugs.launchpad.net/nova/+bug/1679717 | |
| 14:39:41 | lyarwood | ah | |
| 14:47:12 | mriedem | lyarwood: your spec reminds me that the cinder API reference doesn't even mention the encryption provider stuff in the volume type api docs | |
| 14:47:15 | openstackgerrit | Jeremy Stanley proposed openstack/nova master: Switch from pip_missing_reqs to pip_check_reqs https://review.openstack.org/453208 | |
| 14:51:44 | namnh | dansmith: Hi mr Smith, are you free, could I ask you a question about rolling upgrade? | |
| 14:52:22 | dansmith | namnh: just ask and someone here will answer if we know | |
| 14:53:19 | lyarwood | mriedem: yeah isn't it just stashed in the type as in extra_specs? ./me doesn't have an env to check | |
| 14:53:39 | lyarwood | type in extra_specs* | |
| 14:53:49 | namnh | dansmith: According to this link [1], we have to stop and start all Nova's serices except compute at the same time. | |
| 14:53:55 | openstackgerrit | Pushkar Umaranikar proposed openstack/nova-specs master: Stop using Neutron admin token https://review.openstack.org/439890 | |
| 14:54:05 | namnh | [1] https://docs.openstack.org/developer/nova/upgrade.html#rolling-upgrade-process | |
| 14:54:24 | namnh | dansmith: But IMO, there is another way to upgrade is that I will upgrade the services except compute sequentially by pinning version each services like this file [2], at this time we have a new code with the value of "pin version" is old release, after that I will unpin version by restart all services at the same time. If we do this way, we only have downtime when unpining version. How do you think? | |
| 14:54:35 | namnh | [2] https://github.com/openstack/nova/blob/master/nova/conf/upgrade_levels.py | |
| 14:55:07 | dansmith | namnh: as we said yesterday, that only works for compute | |
| 14:55:33 | dansmith | namnh: the other services talk directly to the database, which doesn't honor the upgrade level (those are only for rpc) | |
| 14:55:47 | dansmith | namnh: compute is not allowed to talk directly to the database, which is why it can be old, but the others cannoy | |
| 14:55:49 | dansmith | *cannot | |
| 15:00:56 | namnh | dansmith: but if I upgrade one conductor (N ->O), I will pin version is that: conductor=newton. That mean although conductor at new release, but it will continue talk with other services due to pin version. | |
| 15:01:59 | namnh | dansmith: I understand this file [1] configuration to do this. [1] https://github.com/openstack/nova/blob/master/nova/conf/upgrade_levels.py | |
| 15:02:27 | namnh | dansmith: we can pin version for each service | |
| 15:04:50 | bauzas | dansmith: mriedem: so I thought about the claims spec and I pushed my thoughts in the spec https://review.openstack.org/#/c/437424/ | |
| 15:05:02 | bauzas | dansmith: mriedem: tl;dr I think there are 2 things | |
| 15:05:33 | bauzas | 1/ rescheduling is a cellsv2 problem, not really related to my spec, so we should discuss that separately | |
| 15:05:53 | bauzas | because rescheduling (even without scheduler claims) is not possible in a cellsv2 world | |
| 15:06:41 | bauzas | 2/ I think it would be a still good behaviour if computes delete allocations directly by calling placemnt API, given it would be quicker than waiting for the scheduler during the reschedule | |