Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-11
17:27:19 mriedem ah yeah
17:27:29 mriedem but these are impl details right? does the spec need this level of detail?
17:27:41 mriedem i assume it will be me and you reviewing the code
17:28:10 dansmith mriedem: well, I dunno, it papered over a lot of this
17:28:41 mriedem ok, up to you if you want to ask for more detail
17:28:56 mriedem if you do, i'd say link this irc conversation in there so Kevin_Zheng has it
17:29:32 dansmith well, since it's not as big of a change as I was thinking (just clarifying we're re-using the same) I guess I can just go ahead and approve it and see if he'll come back around to add some stuff
17:30:49 openstack bugzilla.redhat.com bug 1505595 in openstack-nova "Nova assumes that a volume is fully detached from the compute if the volume is not defined in the instance's libvirt definition" [High,Modified] - Assigned to sferdjao
17:30:49 melwitt cfriesen: this is the redhat bz where we ran into the problem. I think it was during a similar thing, a heat stack delete failing at the detach step for "not found" https://bugzilla.redhat.com/show_bug.cgi?id=1505595
17:33:57 cfriesen melwitt: sounds even more promising. what do you think of the idea of heat detecting the failure-to-detach by polling the instance action events?
17:35:19 mriedem cfriesen: that's how i implemented the tempest test for extend volume - pool instance action events until the extend volume action is complete
17:35:26 mriedem *poll
17:36:22 melwitt hm, I was thinking it might be simpler to poll the presence of the attachments by GET to os-volume_attachments and don't proceed to the next step until they are gone
17:36:22 mriedem https://github.com/openstack/tempest/blob/e5d343178334f9d7630e77289e3945e7ccd06cc1/tempest/api/volume/test_volumes_extend.py#L90
17:36:57 melwitt but I guess that wouldn't tell you detail about the status
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

Earlier   Later