Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-19
16:31:50 mriedem b/c of bug 1694844
16:32:15 sean-k-mooney right
16:32:41 sean-k-mooney i assume we dont have an api policy/config option to enforce that
16:32:46 canori01 mriedem: is the OS-EXT-AZ:availability_zone attribute on the instance different than what the scheduler looks at? When, instantiate from horizon and choose any availability zone, that gets set with that of the host. So if I were to actually choose an az at that time, then it would honor the az when moving/resizing?
16:33:32 sean-k-mooney i think that is just the az it is currently schdulerd to but i think the schduler looks at the requst spec for the az when picking hosts
16:33:46 melwitt mriedem: I agree with your assessment on that bug you linked. the trace shows "(self.host_state_map[host] for host in seen_nodes)" noting self.host_state_map which is before my fix landed, but also noting that's different than what the code was _before_ my fix landed as well. the previous code was "(self.host_state_map[host] for host in seen_nodes if host in self.host_state_map)" which would also avoid the KeyError, which reminds me,
16:34:09 melwitt of another fix that they also don't have, judging from that trace https://github.com/openstack/nova/commit/d72b33b986525a9b2c7aa08b609ae386de1d0e89
16:34:37 mriedem ah yeah
16:34:56 mriedem ok maybe they just reported their version incorrectly
16:35:18 mriedem sean-k-mooney: api policy/config option for what?
16:35:25 mriedem [cinder]/cross_az_attach is read in the api
16:35:53 mriedem canori01: "When, instantiate from horizon and choose any availability zone, that gets set with that of the host. So if I were to actually choose an az at that time, then it would honor the az when moving/resizing?" correct
16:36:04 mriedem canori01: "is the OS-EXT-AZ:availability_zone attribute on the instance different than what the scheduler looks at? " also correct
16:36:32 mriedem canori01: the instance.availability_zone field in the db is set to whatever az its compute host is in
16:36:46 mriedem and instance.availability_zone gets changed as the instance moves around
16:37:01 mriedem the scheduler looks at RequestSpec.availability_zone, which is the thing the user requested when they created the server
16:37:14 mriedem so request_spec.az is immutable, but instance.az is not
16:37:51 mriedem how we decide which az to use if the instance.host is in multiple azs....idk
16:38:00 mriedem ^ is a jaypipes feature
16:38:17 mriedem oh wait the compute host can be in multiple aggregates but only 1 az right?
16:38:19 mriedem i always forget the rules
16:39:25 mriedem yeah https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#host-aggregates-and-availability-zones "Availability zones are different from host aggregates in that they are explicitly exposed to the user, and hosts can only be in a single availability zone. Administrators can configure a default availability zone where instances will be scheduled when the user fails to specify one."
16:39:54 mriedem canori01: so, you could setup a default ceph pool with a default az for users that don't specify a specific az and flavor that isn't tied to a given az
16:40:22 mriedem gets kind of hard to manage after awhile probably
16:40:28 openstackgerrit Merged openstack/nova master: Address nits on I08991796aaced2abc824f608108c0c786181eb65 https://review.openstack.org/614322
16:40:49 canori01 mriedem: Perfect, thansk!
16:40:57 canori01 sean-k-mooney: thank you as well
16:43:59 mriedem stephenfin: +2
16:44:08 stephenfin \o/
16:44:38 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Handle binding_failed vif plug errors on compute restart https://review.openstack.org/626361
16:45:34 jaypipes mriedem: ask bauzas.
16:45:46 mriedem i think bauzas is on permanent PTO
16:50:42 mriedem seriously though if anyone knows if bauzas is out the rest of the year, or what, it would be nice to know since i thought he was done with downstream fires for awhile
16:50:59 bauzas mriedem: I literrally have 2 days left :(
16:51:05 mriedem oh so you have been around
16:51:08 bauzas mriedem: but I'll commit myself on upstream reviews
16:51:25 bauzas and upstream revision of the placement spec I have
16:51:27 mriedem well i can give you a bunch of specs to just blindly approve then
16:51:55 bauzas mriedem: that's reasonable, I'm just discussing with internal folks about begging time for upstream before I leave
16:52:11 bauzas I'll just throw my downstream firehose for the next 2 days
16:52:15 mriedem bauzas: in berlin you told me you were good to go for upstream again?
16:52:23 bauzas mriedem: I was *thinking* to
16:52:59 bauzas mriedem: but then someone left us, and more customers are using our OSP12/OSP13 codebase that runs placement :)
16:53:12 bauzas which makes me dragged
16:53:53 mriedem alright well here is a list: https://review.openstack.org/#/c/393930/ https://review.openstack.org/#/c/612531/ https://review.openstack.org/#/c/616037/ https://review.openstack.org/#/c/609779/ https://review.openstack.org/#/c/603352/
16:54:08 mriedem melwitt: weren't you also working on a list of specs that looked like they could use some attention before the freeze?
16:54:23 mriedem in general, i need reviews on the cross cell resize spec from people not named dan since he's been the only one
16:54:23 melwitt mriedem: yes, sent it out like a minute ago
16:54:35 mriedem and it's a hairy gd monster and if others aren't going to review it it's DOA for stein
16:55:12 melwitt yeah, I know :( I'm reviewing it today
16:55:12 mriedem bauzas: thoughts on my email yesterday about per-instance live migration timeouts would also be nice
16:55:36 bauzas mriedem: ack
16:55:38 mriedem cfriesen: you might chime in on http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001112.html as well
16:56:04 melwitt mriedem: feel free to add notes and specs that are on your radar that I missed https://etherpad.openstack.org/p/nova-stein-blueprint-spec-freeze
16:56:12 mriedem will do
17:03:40 bauzas melwitt: thanks for the etherpad
17:11:06 cfriesen mriedem: will take a look
17:20:06 mriedem tl;dr are the compromises worthwhile to move forward
17:26:10 stephenfin Bhujay: What is going on with your IRC connection?
17:27:25 openstackgerrit Merged openstack/nova master: Address nits on I1f1fa1d0f79bec5a4101e03bc2d43ba581dd35a0 https://review.openstack.org/614323
17:27:32 openstackgerrit Merged openstack/nova master: Fix a broken-link in nova doc https://review.openstack.org/626113
17:32:50 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Handle binding_failed vif plug errors on compute restart https://review.openstack.org/626369
17:32:52 mriedem hooray for ocata em ^
17:34:39 stephenfin melwitt: Seeing as you looked at the earlier change, fancy taking a look at https://review.openstack.org/#/c/626228 ?
17:35:18 melwitt stephenfin: sure, always up for being pinged for reviews
17:35:30 stephenfin mriedem: Thanks for reviewing that nit patch (y)
17:36:16 mriedem the docs one? i didn't really, just saw gibi was +2 and it was a rebase
17:36:24 mriedem but yw :)
17:39:31 openstackgerrit Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959
17:57:02 openstackgerrit Chris Dent proposed openstack/nova master: Redirect user/placement to placement docs https://review.openstack.org/626333
18:02:02 openstackgerrit Krzysztof Opasiak proposed openstack/nova master: Fix server IPs with non-unique network names https://review.openstack.org/625371
18:02:15 cfriesen stephenfin: any chance you could take a look at the cpu models spec proposed by Jack ^ ? Basically instead of setting one model in nova.conf the operator could specify a list, and the virt driver would use the first one that provides the requested cpu features.
18:02:58 openstackgerrit Krzysztof Opasiak proposed openstack/nova master: Fix server IPs with non-unique network names https://review.openstack.org/625371
18:16:00 melwitt mriedem: I wanted to bring this review to your attention, bug about returning build requests when a marker is specified (I know you love paginating stuff). I'm +2 on it https://review.openstack.org/624870
18:22:56 openstackgerrit Merged openstack/nova master: Remove legacy RequestSpec compat code from live migrate task https://review.openstack.org/625705
18:39:52 openstackgerrit Tim Rozet proposed openstack/nova master: Fixes race condition with privsep utime https://review.openstack.org/625741
18:57:55 mriedem i saw it before, asked andrey to flesh out the commit message, haven't been back
19:16:41 melwitt ah, ok
19:28:05 mnaser friendly bump on this - https://review.openstack.org/#/c/619352/
19:28:21 mnaser simple backport, the changes in the newer branches have merged too
19:29:10 mriedem frickler: fyi redo of the queens release https://review.openstack.org/626377
19:31:22 mriedem duplicate bug of https://review.openstack.org/#/c/567701/ just came through triage, the fix is straight-forward, the patch is mostly a functional test
19:58:40 openstackgerrit sean mooney proposed openstack/nova master: PCI: do not force remove allcoated devices https://review.openstack.org/626381
19:59:20 sean-k-mooney mriedem: i have no idea why my unit test is not working in ^
20:00:56 sean-k-mooney im going to grab dinner but if you have any insight let me know.
20:01:01 mriedem ack thanks
20:33:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Document using service user tokens for long running operations https://review.openstack.org/626388
20:35:00 openstackgerrit Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959
20:39:51 melwitt mriedem: re: the ML thread about that, I thought the oslo.messaging heart beat would take care of the long running live migration problem?
20:40:00 mriedem the problem isn't rpc
20:40:21 melwitt oh, the token auth expiring
20:40:24 mriedem nova tries to make a rest api request using the users token to cinder,
20:40:26 mriedem the token has timed out
20:40:31 melwitt I see, ok
20:41:06 melwitt yeah, have to have both then. I got the two confused together but they are two different issues
20:41:17 mriedem i want to say i heard anecdotes at one point that rax public cloud had 24 token timeouts because of stuff like this way back when
20:41:58 mriedem the service user token stuff was added by osic, which was rax+intel
20:43:55 melwitt yeah, sounds familiar. I feel like we had something similar at yahoo too
20:44:21 melwitt *something similar to service user auth
20:58:21 mriedem long_rpc_timeout probably also deserves some mention somewhere in troubleshooting admin docs, but not sure right now,

Earlier   Later