Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-24
12:28:20 sdague sfinucan: you reading the email on the ipv6 issue infra hit
12:29:01 sfinucan sdague: I am not. Link?
12:29:25 sfinucan Is this 'Config drive claims ipv6_dhcp, neutron api says slaac'
12:33:18 sdague yeh
12:37:44 sfinucan Hmm, I've never even heard of slaac. It would appear I've not so much broken something as exposed existing broken behaviour. This is going to be fun to debug
12:39:01 leakypipes alex_xu: well, I've been trying to get those traits in to os-traits here: https://review.openstack.org/#/c/448283/
12:39:32 leakypipes alex_xu: but cdent and sean-k-mooney don't seem to care for the patch before it that splits out traits into different modules.
12:40:12 leakypipes alex_xu: I originally had the NIC traits added as a single patch but sean-k-mooney requested some refactoring before expanding the single const.py further.
12:40:46 cdent leakypipes: that's a bit strong, it's more like it's not what it says on the tin. what's in the tin is good enough if the label is changed. However the label does sound pretty nice.
12:40:52 sean-k-mooney leakypipes: im always causing trouble :)
12:40:59 alex_xu leakypipes: yea, i see, just thought we can begin to use those NIC traits in https://review.openstack.org/435954
12:41:38 leakypipes alex_xu: you mean replace "tso" with "HW_NIC_OFFLOAD_TSO" in the spec?
12:41:50 alex_xu leakypipes: yea
12:42:16 leakypipes alex_xu: well, that's fine of course :) but I won't hold up the spec for that. we can always enforce that in the code.
12:43:03 sean-k-mooney alex_xu: we could definetly do that and assuming the network traits land before pike release we chan change the impentation to use them once they are merged
12:43:50 alex_xu leakypipes: yea, I also did ask the doc work to replace tso to 'HW_NIC_OFFLOAD_TSO', just thought when we put those NIC traits in the code, those should be standard trait. otherwise, we will let user transfer to the standard trait in the future
12:44:28 sean-k-mooney leakypipes: i dont thnik we nesicalliy have all the feature flag we would need in your initall patch but we can extend in follow up patches
12:44:34 alex_xu s/did ask/didn't ask/
12:44:36 alex_xu oops
12:45:15 alex_xu sean-k-mooney: yea, in the internal implement that is totally ok.
12:47:16 leakypipes sean-k-mooney: sure, agreed.
12:48:17 alex_xu sean-k-mooney: +1
12:48:27 openstackgerrit Silvan Kaiser proposed openstack/nova master: Switch Nova Quobyte volume driver to mount via systemd-run https://review.openstack.org/432344
12:49:32 sean-k-mooney alex_xu: so do you want us to update the spec to reflect or just enforce it via the code review of the implentation of the feature?
12:50:26 alex_xu sean-k-mooney: i think we only update this line https://review.openstack.org/#/c/435954/11/specs/pike/approved/enable-sriov-nic-features.rst@222
12:59:03 ralonsoh alex_xu: hi
12:59:09 ralonsoh alex_xu: just for confirmation
12:59:36 ralonsoh alex_xu: when string values are read form libvirt, I need to normalize to os-traits values
12:59:47 ralonsoh alex_xu: these values will be stored in the DB
12:59:53 alex_xu ralonsoh: yea
13:00:03 ralonsoh alex_xu: and Neutron port will need to make the definition
13:00:20 ralonsoh alex_xu: https://review.openstack.org/#/c/435954/11/specs/pike/approved/enable-sriov-nic-features.rst@120
13:00:32 ralonsoh alex_xu: using this normalized values
13:00:41 ralonsoh alex_xu: is that correct?
13:01:28 alex_xu ralonsoh: what does mean about neutron port will need to make the definition
13:02:15 ralonsoh alex_xu: I meant in https://review.openstack.org/#/c/435954/11/specs/pike/approved/enable-sriov-nic-features.rst@121, instead of writing low case value
13:02:32 alex_xu ralonsoh: yea
13:02:39 ralonsoh alex_xu: we need to write the normalized strings (defined in os-traits)
13:02:41 ralonsoh perfect!
13:02:52 ralonsoh alex_xu: I'll update the spec today
13:02:53 alex_xu ralonsoh: that is what i mean
13:02:58 ralonsoh and thanks!
13:02:58 alex_xu ralonsoh: thanks
13:09:52 mriedem bauwser: you might want to take a look at this https://bugs.launchpad.net/nova/+bug/1675607
13:09:52 openstack Launchpad bug 1675607 in OpenStack Compute (nova) "test_list_migrations_in_flavor_resize_situation fails with NoValidHost - AvailabilityZoneFilter returned 0 hosts" [Undecided,Confirmed]
13:10:02 mriedem ES is backed up so i'm not sure if it's a recent regression or not
13:10:04 bauwser mriedem: yup, saw you adding me
13:10:19 bauwser it's in my pipe
13:10:39 mriedem well smoke'em if you got'em
13:11:22 bauwser :p
13:18:30 markus_z trivial fix: https://review.openstack.org/#/c/449543/1
13:19:33 openstackgerrit John Garbutt proposed openstack/nova-specs master: WIP: Add policy-remove-scope-checks spec https://review.openstack.org/433037
13:20:09 johnthetubaguy sdague: attempt to apply the first few of your comments, and I am heading for lunch now, but I am curious if that looks better or worse ^
13:21:19 sdague ok, I'll check post breakfast
13:23:21 mriedem johnthetubaguy: i think sdague summed up my issues nicely :)
13:49:11 dansmith mriedem: so that az bug
13:49:17 mriedem yes superdan
13:49:20 dansmith heh
13:49:35 superdan mriedem: after my change to persist the az properly in the instance,
13:49:54 superdan the scheduler will start keeping an instance in the same az it was booted in,
13:50:00 superdan even if they didn't ask for one
13:50:12 superdan that's because of the cruft still left to cleanup with reqspec
13:50:29 superdan reqspec has what they requested, but instance stores what it was booted in, and we're not restoring the reqspec at the right place yet
13:50:43 superdan now, I think in practice this is fine, and we even discussed it prior to merging
13:50:51 superdan however, I think what is happening is,
13:51:11 superdan tempest creates a test az and adds the one compute to it in another test,
13:51:36 superdan and if that instance happens to land there while the az is in place, and is then removed, the instance won't schedule anywhere because we have now told nova that the az it wants doesn't exist anymore
13:51:38 superdan we == tempest
13:51:54 superdan if the tests run such that we don't get lucky there, then we're fine
13:52:11 superdan bauwser: ^
13:52:22 mriedem let me see what the test does
13:52:25 bauwser sorry was distracted by some internal bug triaging :)
13:52:27 mriedem the az is random btw
13:52:38 superdan mriedem: right
13:52:51 superdan mriedem: the az comes from compute/admin/test_aggregates
13:53:09 mriedem http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/compute/admin/test_migrations.py#n42
13:53:38 superdan right, no az stuff there
13:54:58 mriedem superdan: oh so the instance lands on the single compute which, because of a concurrently running test, is now in an AZ, so the instance in the test that fails is now in that temp AZ which on cleanup of the other unrelated test is removed
13:55:00 bauwser mriedem: superdan: so if there is no AZ asked when booting, the default is not set
13:55:09 mriedem so when we move the instance, it's in an AZ that is now gone b/c of the tempest cleanup?
13:55:17 superdan mriedem: that's what I'm thinking yeah
13:55:23 bauwser mriedem: that could be a reason yes
13:55:52 mriedem look here http://logs.openstack.org/62/449362/1/check/gate-tempest-dsvm-py35-ubuntu-xenial/ec959b4/console.html#_2017-03-24_00_00_55_563868
13:55:58 mriedem there is an AZ test right at the same time
13:56:24 superdan we need this cleanup to be done in order to ask for what they actually wanted: https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L49-L55
13:56:37 bauwser I was planning to do so next week
13:57:00 bauwser -ish
13:57:42 bauwser I could try to tackle that now
13:58:15 superdan hmm,
13:58:26 superdan looks like we got request_spec at init and we just overwrite it from_compontents?
13:58:29 superdan is that right?
13:58:39 sdague mriedem or others, anyone want to merge in i18n deletes. I'm trying to keep no more than 2 open at a time just to not waste time on rebasing - https://review.openstack.org/#/c/448082/
13:59:23 mriedem superdan: i tried to summarize in the bug
13:59:26 superdan yeah, I think we should have that right there
13:59:32 superdan mriedem: okay I was going to, sorry
13:59:51 bauwser superdan: yup, I actually think we can directly use self.request_spec without needing to rehydrate
14:00:06 superdan I'll try
14:00:06 bauwser because it's useless to regeneate ity
14:00:11 bauwser lemme fire the drill
14:00:28 bauwser because some other move operations can have the same stuff

Earlier   Later