Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-20
16:14:41 bauzas cfriesen: cool
16:14:43 jroll bauzas: will look / pass along
16:14:43 mriedem conductor will always pass host/node to the compute rebuild_instance
16:14:55 bauzas jroll: mgoddard provided a comment
16:15:08 mriedem even if it's just None
16:15:11 bauzas jroll: but I'm unclear if/how that makes that bug fixable
16:15:17 dansmith mriedem: it's just super hard to reason about a lot of these calls where everything is optional, except not really
16:15:26 jroll bauzas: will look / pass along, I'm in the middle of something
16:15:39 bauzas jroll: FWIW, we also have http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/virt-device-tagged-attach-detach.html that helps setting network devices
16:15:41 dansmith mriedem: so later when you start depending on a parameter that has been required for three years, and some random unit test fails..
16:15:45 bauzas jroll: np, take your time
16:15:56 bauzas jroll: if you could just comment that bug, that'd be awesome
16:16:11 bauzas because I'm blind for triaging it :)
16:16:13 openstackgerrit Mohammed Naser proposed openstack/nova stable/queens: Store block device mappings in cell0 https://review.openstack.org/546201
16:16:13 openstackgerrit Mohammed Naser proposed openstack/nova stable/queens: Drop extra loop which modifies Cinder volume status https://review.openstack.org/546200
16:16:14 openstackgerrit Mohammed Naser proposed openstack/nova stable/queens: Clean up ports and volumes when deleting ERROR instance https://review.openstack.org/546203
16:16:14 openstackgerrit Mohammed Naser proposed openstack/nova stable/queens: Add functional tests to ensure BDM removal on delete https://review.openstack.org/546202
16:16:15 openstackgerrit Mohammed Naser proposed openstack/nova stable/queens: Add functional recreate test of deleting a BFV server pre-scheduling https://review.openstack.org/546204
16:22:59 openstackgerrit Mohammed Naser proposed openstack/nova stable/pike: Drop extra loop which modifies Cinder volume status https://review.openstack.org/546218
16:23:00 jroll bauzas: commented - bug is "this is not deterministic", mgoddard's comment shows the tools to make it deterministic :)
16:23:15 bauzas jroll: ta
16:23:23 bauzas yeah, I understood the problem
16:23:29 bauzas it's not deterministic
16:23:39 bauzas but that's also why we have http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/virt-device-tagged-attach-detach.html
16:24:52 jroll bauzas: I feel like I would need to read a lot of words to understand if that helps us :)
16:25:20 openstackgerrit Mohammed Naser proposed openstack/nova stable/pike: Store block device mappings in cell0 https://review.openstack.org/546219
16:25:31 cdent mriedem: if you want to restore https://review.openstack.org/#/c/418393/ I've got something to push there
16:25:40 bauzas jroll: anyway => Wontfix
16:25:54 mriedem cdent: done
16:26:02 cdent thanks
16:26:29 openstackgerrit Chris Dent proposed openstack/nova-specs master: Provide error codes for placement API https://review.openstack.org/418393
16:26:45 openstackgerrit Mohammed Naser proposed openstack/nova stable/pike: Add functional tests to ensure BDM removal on delete https://review.openstack.org/546220
16:30:10 openstackgerrit Mohammed Naser proposed openstack/nova stable/pike: Clean up ports and volumes when deleting ERROR instance https://review.openstack.org/546221
16:31:00 openstackgerrit Mohammed Naser proposed openstack/nova stable/pike: Add functional recreate test of deleting a BFV server pre-scheduling https://review.openstack.org/546222
16:31:12 mnaser well, that was fun, now onto the one which will be the most fun, ocata.
16:31:20 zigo When building nova in Sid with Python 3.6, I get this unit test error: http://paste.openstack.org/show/678793/
16:31:25 zigo Has this been reported already?
16:33:43 openstackgerrit Mohammed Naser proposed openstack/nova stable/ocata: Drop extra loop which modifies Cinder volume status https://review.openstack.org/546223
16:35:17 cdent zigo: yes, and fixed, one sec, I'll get you some links
16:35:36 cdent zigo: https://review.openstack.org/#/c/545798/ has links to bugs etc
16:36:18 artom bauzas, hey
16:36:38 bauzas artom: no worries, we closed the bug
16:36:59 artom bauzas, aha, I see
16:37:03 artom bauzas, byez
16:38:01 bauzas mriedem, melwitt, others : I won't be around tomorrow (PTO for skiing), so see you on Thursday for those that aren't yet flighting :)
16:38:12 bauzas flying* even
16:38:23 bauzas man, my English hurts
16:38:36 bauzas \o
16:38:44 openstackgerrit Mohammed Naser proposed openstack/nova stable/ocata: Store block device mappings in cell0 https://review.openstack.org/546226
16:39:11 bauzas mnaser: I'll review your stable changes once I'm back on Thursday
16:39:43 mnaser bauzas: no worries. i'll get them all in and make sure they pass CI.. i think some might need some test changes because some function signatures are different
16:40:08 mriedem dansmith: checking my understanding here https://review.openstack.org/#/c/543580/1/nova/compute/rpcapi.py@a1265 - we have some REST API handler code for compat exceptions raised from the compute rpcapi client; but we can't remove that handling in the api in queens because we could still have queens computes sending those errors?
16:40:34 dansmith mriedem: s/queens/rocky?
16:41:08 mriedem i'm lost
16:41:11 dansmith mriedem: anything queens could handle, but was being compat for pike should be remove-able in rocky
16:41:30 mriedem some of these are compat for things added in queens
16:41:42 mriedem like the multiattach exception in reserve_block_device_name
16:42:02 dansmith compat for pike.5 right?
16:42:05 dansmith meaning,
16:42:06 mriedem https://review.openstack.org/#/c/543580/1/nova/compute/rpcapi.py@a1044
16:42:08 dansmith queens could handle it
16:42:14 dansmith but something between pike and queens could not
16:42:44 dansmith right, so you can't handle 4.x clients at all anymore in rocky after this,
16:42:55 dansmith but all queens (release) nodes can, and that's as far back as this supports
16:43:17 dansmith if you tried to pin to 4.15 in that case, you'd get the failure we saw in the early grenade run anyway, well before you got to this point
16:43:39 mriedem so i can't upgrade my api to rocky until all of my computes have been upgraded to queens right?
16:43:55 dansmith right, but that's the case anyway, per the rules
16:44:01 mriedem well,
16:44:13 mriedem we've had compat code in the api for lots of different cases
16:44:17 mriedem which is why i was wondering about this
16:44:23 mriedem the api has code to handle mixed version computes
16:44:39 dansmith right, but once that gap is more than N-1 it's technically out of scope,
16:44:45 dansmith even if we leave it for longer
16:45:12 dansmith if we really need to be defensive in the api about something, we should probably be looking at service version,
16:45:24 dansmith but we can't just look for those forever, which is why we have rules about the gaps
16:46:09 mriedem i don't know if that rule is written down anywhere
16:46:11 openstackgerrit Mohammed Naser proposed openstack/nova stable/ocata: Add functional tests to ensure BDM removal on delete https://review.openstack.org/546227
16:46:12 openstackgerrit Mohammed Naser proposed openstack/nova stable/ocata: Clean up ports and volumes when deleting ERROR instance https://review.openstack.org/546228
16:46:16 mriedem which is a question that gets asked every 6 months or so
16:46:31 dansmith the rule that we only support N-1?
16:46:34 mriedem in other words,
16:46:56 mriedem i think one could upgrade the api to queens while they have pike computes and it's fine, but when they upgrade the api to rocky, their computes have to all be queens
16:46:59 mriedem so it's a bit different behavior
16:47:34 mriedem but then multinode grenade wouldn't work...so that doesn't make sense
16:47:35 sean-k-mooney QQ anyone know if the regex support in the pci whitelist allow negation? basical i want to say whitlist vf where vendor_id=x product_id=y and pci_adress is not z
16:47:47 cfriesen what's the criteria for when we expect to create a Migration record on a rebuild?
16:48:10 mriedem cfriesen: a rebuild isn't a migration so never
16:48:48 openstackgerrit Mohammed Naser proposed openstack/nova stable/ocata: Add functional recreate test of deleting a BFV server pre-scheduling https://review.openstack.org/546230
16:49:06 cfriesen mriedem: what about evacuate or rebuild-to-new-server?
16:49:07 mriedem dansmith: here is an example of one of these things that i'd like to remove from the api https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1138
16:49:18 mriedem cfriesen: the api creates the migration record for evacuate
16:49:23 mriedem cfriesen: you could just look at the code
16:49:57 mnaser i'm sure i messed up a conflict somewhere, i have to
16:50:10 cfriesen I am, but it wasn't obvious who was creating it...the ComputeManager code just does a "look it up if it exists and log if it doesn't"
16:50:20 dansmith mriedem: yeah, so if your api is on rocky past this commit, you (obviously) can't hit that, nor can you detect that it won't be supported unless you go by service version
16:50:24 cfriesen or rather, that's the ConductorManager code
16:50:48 dansmith mriedem: if you have configured your upgrade_levels to attempt to allow talking to older than queens nodes, you would have failed to start the api service entirely because rpc client setup will fail
16:55:06 openstackgerrit Mohammed Naser proposed openstack/nova stable/pike: Add functional tests to ensure BDM removal on delete https://review.openstack.org/546220
16:56:17 mriedem dansmith: so wondering if we should have an upgrade release note saying you can do rolling upgrades of your computes, but don't upgrade your api until all computes are at least rocky
16:56:48 dansmith mriedem: well, I don't think that we do because I feel like that is the rule, so calling it out makes this sound special when it's really not

Earlier   Later