| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-11 | |||
| 17:37:23 | mriedem | yeah you could end up polling for a long time | |
| 17:37:27 | mriedem | you'd have to build in a timeout | |
| 17:37:49 | cfriesen | currently it seems to keep polling until the token times out | |
| 17:37:51 | mriedem | you likely need a timeout either way https://github.com/openstack/tempest/blob/e5d343178334f9d7630e77289e3945e7ccd06cc1/tempest/api/volume/test_volumes_extend.py#L160 | |
| 17:38:05 | mriedem | some cloud providers have 24 hour token timeouts don't they? | |
| 17:38:07 | mriedem | or maybe that was years ago | |
| 17:38:15 | cfriesen | in this case it was an hour | |
| 17:38:39 | mriedem | if a volume detach isn't done in 5 minutes something is fubar | |
| 17:38:46 | cfriesen | but then it naively retries and hits the other failure that I think will be adresssed by the commit melwitt pointed out | |
| 17:38:47 | mriedem | even a minute really | |
| 17:41:48 | cfriesen | melwitt: the method you describe is what it seems to be doing currently, it's calling self.client().volumes.get_server_volume(server_id, attach_id) and looking for the "not found" exception. | |
| 17:42:17 | mriedem | cfriesen: if sahid's patch fixes your issue in pike, you can propose https://review.openstack.org/#/c/546655/ for stable/pike | |
| 17:42:19 | melwitt | I see | |
| 17:42:40 | cfriesen | mriedem: ack | |
| 17:42:47 | openstackgerrit | Merged openstack/nova-specs master: Allow abort live migrations in queued status https://review.openstack.org/536722 | |
| 17:57:05 | openstackgerrit | Merged openstack/nova master: Marker reset option for nova-manage map_instances https://review.openstack.org/539501 | |
| 17:57:17 | openstackgerrit | Merged openstack/nova master: Imported Translations from Zanata https://review.openstack.org/548772 | |
| 18:21:12 | openstackgerrit | Dan Smith proposed openstack/nova master: libvirt: refactor get_base_config to accept host arg https://review.openstack.org/560456 | |
| 18:30:00 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 18:30:23 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Snapshot https://review.openstack.org/543023 | |
| 18:30:53 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class https://review.openstack.org/549053 | |
| 18:43:51 | dustfalling | Does anyone knows if it possible for nova to pass individual local drives as block device to VM, for use cases like big data? | |
| 18:54:24 | dansmith | dustfalling: see channel topic, but using the LVM ephemeral driver is about as close as you can get | |
| 18:55:36 | dustfalling | thank you, dansmith | |
| 19:20:57 | openstack | Launchpad bug 1558880 in OpenStack Compute (nova) "instance can not resize ephemeral in mitaka" [Medium,In progress] - Assigned to Nazeema Begum (nazeema123) | |
| 19:20:57 | cfriesen | was there ever a concensus reached about how to deal with https://bugs.launchpad.net/nova/+bug/1558880 ? It seems to have been stalled for a long time now without any clear path forward. | |
| 19:25:08 | melwitt | cfriesen: doesn't look like it. mdbooth had some ideas in comment 15. I hadn't seen the bug before you mentioned it | |
| 19:28:57 | openstackgerrit | Merged openstack/nova stable/pike: libvirt: Allow to specify granular CPU feature flags https://review.openstack.org/559702 | |
| 19:40:03 | openstackgerrit | Arvind Nadendla proposed openstack/nova master: update scheduler to use image-traits https://review.openstack.org/560596 | |
| 19:55:26 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk https://review.openstack.org/549300 | |
| 19:56:18 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM: Cold Migrate & Resize https://review.openstack.org/553583 | |
| 19:58:36 | mriedem | dansmith: fyi, for https://review.openstack.org/#/c/560596/ we'll have to think about rebuild + new image with required traits... | |
| 19:58:51 | mriedem | as much as no one wants to think about that | |
| 20:02:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional test for deleting a compute service https://review.openstack.org/560626 | |
| 20:02:33 | mriedem | tssurya: ^ i'll rebase your change on top of it | |
| 20:13:38 | tssurya | mriedem: thanks a lot, oh nice I wasted so much of time in trying to see if the service fixture could return the service object also,, not sure why I didn't think of just querying it using get_services after the compute service is creeated | |
| 20:14:03 | mriedem | for the most part, we want functional tests to interact with the REST API | |
| 20:14:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional test for deleting a compute service https://review.openstack.org/560626 | |
| 20:14:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup RP and HM records while deleting a compute service. https://review.openstack.org/554920 | |
| 20:14:53 | tssurya | mriedem: yea makes sense, I am completely naive :( will practise writing these things more | |
| 20:15:21 | efried | mriedem: test_resize_with_reschedule_then_live_migrate is that bug you fixed earlier with the waiting for migration to complete? | |
| 20:15:53 | mriedem | efried: yes | |
| 20:16:04 | mriedem | http://status.openstack.org/elastic-recheck/#1762876 | |
| 20:16:05 | efried | mriedem: was gonna ask if it merged, but I see it's trying to get through the gate. | |
| 20:16:41 | efried | I rechecked it. | |
| 20:17:17 | mriedem | ok looks like test_parallel_evacuate_with_server_group is also racy | |
| 20:17:52 | efried | whee | |
| 20:19:39 | tssurya | mriedem: totally appreciate the detailed comments on why you are doing what you are doing specially the fixtures . | |
| 20:20:44 | mriedem | the setUp is mostly copy/paste from other similar functional tests | |
| 20:20:53 | mriedem | but thanks, i'll take all that credit | |
| 20:21:17 | tssurya | mriedem: I know, that's what I did took most of it from test_servers like Dan said | |
| 20:21:31 | tssurya | however I got tangled up | |
| 20:21:41 | arvindn05 | mriedem: incase of rebuild, can we make a allocation request to placement without resources and only traits(will require API behaviour change, new microversion?) and make sure the host list returned contains the host we are currently doing a rebuild of? | |
| 20:22:05 | mriedem | orangutangled? https://www.amazon.com/Orangutangled-Sudipta-Bardhan-Quallen/dp/1477847170 | |
| 20:22:29 | arvindn05 | mriedem: if that sounds like a good startergy...i can pursure the code changes required while that other patch is being merged.... | |
| 20:22:43 | tssurya | mriedem: :P | |
| 20:23:06 | mriedem | arvindn05: i think that is over-complicating things | |
| 20:23:26 | mriedem | to modify the allocation_candidates API to ignore resources | |
| 20:24:08 | arvindn05 | hmm....ok...any suggestions? | |
| 20:24:10 | mriedem | if anything, we'd want to change GET /allocation_candidates to pass in a specific root provider uuid | |
| 20:24:41 | mriedem | however....placement might say, "sorry no more room" | |
| 20:24:45 | arvindn05 | i though it could be useful for other cases where the user might want to take an inventory of RP's with specific traits etc | |
| 20:24:57 | mriedem | the user can do that via GET /resource_providers | |
| 20:25:24 | mriedem | hmm, i'm not sure how allocation_candidates is going to work here, since i guess it would have to make resources optional, | |
| 20:25:30 | mriedem | otherwise you can hit the bug that hongbin is fixing | |
| 20:25:34 | mriedem | if the compute is full | |
| 20:25:57 | arvindn05 | exactly... | |
| 20:26:07 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional test for deleting a compute service https://review.openstack.org/560626 | |
| 20:26:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup RP and HM records while deleting a compute service. https://review.openstack.org/554920 | |
| 20:26:33 | mriedem | arvindn05: well, this is why your spec needs to be amended like i asked for | |
| 20:27:45 | arvindn05 | oh...didnt realize you were asking for ammending the spec...my assumption was to use the code review phase for addressing since it was a bug fix | |
| 20:28:29 | mriedem | what is a bug fix? | |
| 20:28:38 | mriedem | hongbin's patch is a bug fix | |
| 20:28:41 | mriedem | you're adding a new feature | |
| 20:30:40 | arvindn05 | got it. Thanks for letting me know...i thought specs need to be ammended for larger changes....i can propose an amendment to the spec | |
| 20:31:26 | mriedem | arvindn05: if we have to make an API change to GET /allocation_candidates, then it's a larger change, and all API changes require a spec anyway | |
| 20:32:13 | mriedem | dansmith: melwitt: i would like to phone a friend on https://review.openstack.org/#/c/554920/6/nova/api/openstack/compute/services.py@226 | |
| 20:32:23 | dansmith | hah | |
| 20:32:38 | melwitt | heh, awesome reference | |
| 20:33:17 | mriedem | re: is it ok to cascade delete the resource provider while the service has instances on it | |
| 20:33:38 | arvindn05 | mriedem: API change is just my first proposal...i would really like to avoid it if i can with a much more localized fix...but you are right its better to be discussed on the spec in case we need to make that API change | |
| 20:33:47 | dansmith | mriedem: we currently allow them to do this anyway right? | |
| 20:33:57 | dansmith | mriedem: deleting the resource provider doesn't affect the quota | |
| 20:34:08 | dansmith | mriedem: it just avoids us leaking data in placement | |
| 20:34:32 | melwitt | well, thinking ahead where we want to ask placement for cores/ram allocation usage | |
| 20:34:38 | mriedem | dansmith: we currently allow admins to delete compute services that have instances running on them, yes | |
| 20:34:49 | melwitt | it seems like we shouldn't nuke allocations if instances are still alive, right? | |
| 20:34:51 | dansmith | so that creates the quota issue | |
| 20:34:53 | mriedem | but we don't currently delete the resource provider (and allocations) | |
| 20:35:08 | mriedem | and since the compute doesn't heal allocations, | |
| 20:35:29 | mriedem | even if you bring the compute back up, those instances are screwed and the resource provider for that node isn't going to report proper inventory | |
| 20:35:36 | mriedem | s/inventory/consumption/ | |
| 20:35:37 | melwitt | like, instances are still consuming resources from placement | |
| 20:35:49 | dansmith | instances don't consume from placement, | |
| 20:36:06 | dansmith | but yes, they'll be consuming from a provider that is no longer present | |
| 20:36:13 | mriedem | it seems to me that if the node has instances with allocations in placement, we shouldn't delete the resource provider in that case | |
| 20:36:19 | dansmith | mriedem: that's still true today right? if you delete it, you'll end up with a compute node that looks to be empty in placement | |
| 20:36:38 | mriedem | dansmith: i guess the node uuid would change wouldn't it | |
| 20:36:43 | melwitt | well, this cascade is talking about deleting the allocations too right? I thought we need to keep the allocations as long as the instance is alive, no? | |
| 20:36:44 | mriedem | so you'd have a new provider | |