| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-04 | |||
| 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 | mriedem | https://bugs.launchpad.net/nova/+bug/1679717 | |
| 14:39:28 | openstack | Launchpad bug 1679717 in OpenStack Compute (nova) "Potential for NameError when logging volume encryptor" [Undecided,New] | |
| 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 | |
| 15:08:03 | namnh | hieulq: ping | |
| 15:08:52 | frickler | from a deployment perspective, is there any sense in providing the placement API to customers? or would one rather create an internal endpoint only? | |
| 15:10:08 | frickler | I'm assuming the latter and then it might make sense to change the default of placement.os_interface from public to internal, too | |
| 15:10:29 | pumarani_ | sdague, checking your comment on https://review.openstack.org/#/c/439890/. I understand your concern of getting neutron changes in place first. | |
| 15:10:54 | pumarani_ | sdague, we have already added RFE in neutron https://review.openstack.org/#/c/439890/ | |
| 15:11:15 | pumarani_ | i mean https://bugs.launchpad.net/neutron/+bug/1674349 | |
| 15:11:15 | openstack | Launchpad bug 1674349 in neutron "[RFE] Introduce a new rule with service user role in Neutron policy" [Wishlist,Triaged] - Assigned to Akihiro Motoki (amotoki) | |
| 15:19:35 | sdague | pumarani_: ok, that's a wishlist bug, does that mean it's commited to be accepted? | |
| 15:19:41 | sdague | also, where is implementation code for it | |
| 15:19:46 | frickler | sdague: mriedem: this has a nicer (imho) list of all the versions in Ocata UCA: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ocata_versions.html | |
| 15:20:07 | sdague | frickler: ah, cool, I was looking for something like that | |
| 15:20:58 | mriedem | lyarwood: no it's in the volume encryption model in the cinder db | |
| 15:21:50 | sdague | pumarani_: I guess, it's really unclear to me what the neutron status is, and as such I'd really feel a lot better about this depending on merged neutron code. | |
| 15:22:08 | mdbooth | lyarwood: Are you wondering where the provider string comes from? | |
| 15:22:38 | mriedem | bauzas: if we can't reschedule, why do we care about how fast the allocations are deleted? | |
| 15:23:17 | mriedem | that raises the question of when the allocations are deleted, but i think that's just left unchanged, when we delete the instance we remove the allocations via RT in the comptue host | |
| 15:23:19 | mriedem | *compute | |
| 15:23:21 | bauzas | mriedem: it's a separate problem, hence me saying if reschedules are possible, then I'd prefer to delete the allocations sooner than later | |
| 15:23:23 | mdbooth | mriedem: Do you have a spec to delete bdm v1, btw? | |
| 15:23:29 | mriedem | mdbooth: i don't | |
| 15:23:36 | mriedem | bauzas: also, have we taken into account local deletes in the API? | |
| 15:23:47 | bauzas | mriedem: I'm just putting a big hypothesis in my spec that is, reschedules are possible | |
| 15:23:47 | mriedem | the compute api would have to delete the allocations there if the compute is dead | |
| 15:23:50 | mdbooth | mriedem: Why does it linger, btw? | |
| 15:24:07 | mriedem | mdbooth: no good reason probably | |
| 15:24:26 | mdbooth | It's a prime candidate for simplification. | |