| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-12 | |||
| 17:03:11 | mriedem | it now removes the lock as well on jay's request | |
| 17:06:08 | dansmith | mriedem: just noticed while reviewing the logs forthis: https://review.openstack.org/#/c/623284/4 | |
| 17:06:19 | dansmith | mriedem: which does now select the right rpc version once computes get started | |
| 17:06:23 | dansmith | which was not happening before | |
| 17:07:22 | sean-k-mooney | adrianc: so yes if i just do "sudo ifconfig enp1s17f5 0" i does not fix the issue either | |
| 17:07:39 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ensure that allocated PF matches the used PF https://review.openstack.org/623543 | |
| 17:08:01 | mriedem | dansmith: which job was that message from? | |
| 17:08:10 | mriedem | because on tempest-full nova-api starts up before there are any computes | |
| 17:08:12 | dansmith | mriedem: tempest-full | |
| 17:08:17 | sean-k-mooney | adrianc: sorry "sudo ifconfig enp1s17f5 down" | |
| 17:08:37 | dansmith | mriedem: right you see it fail once first, and then once computes are started, it finds the version | |
| 17:08:58 | dansmith | mriedem: before that "all cells" patch, you saw the failure on start and it never finds them after that | |
| 17:09:03 | mriedem | ah yeah http://logs.openstack.org/84/623284/4/check/tempest-full/23568c2/controller/logs/screen-n-api.txt.gz#_Dec_11_20_56_12_002867 | |
| 17:09:15 | mriedem | http://logs.openstack.org/84/623284/4/check/tempest-full/23568c2/controller/logs/screen-n-api.txt.gz#_Dec_11_21_00_06_274322 | |
| 17:09:25 | dansmith | yep | |
| 17:09:59 | mriedem | huh wonder if i made devstack switch upgrade_levels=auto in stein or rocky... | |
| 17:10:16 | dansmith | it's been a while I thought, so I'm surprised this didn't break us | |
| 17:10:23 | dansmith | but we also haven't had many rpc versions recently | |
| 17:10:25 | mriedem | https://review.openstack.org/#/c/550108/ | |
| 17:10:34 | mriedem | we went to auto upgrade levels in rocky | |
| 17:11:01 | dansmith | well, we'll definitely want to backport this | |
| 17:11:04 | mriedem | how far back do you think we need this to go? | |
| 17:11:07 | mriedem | pike? | |
| 17:11:28 | dansmith | pike was when you could actually have multiple cells right? so yeah, there | |
| 17:11:38 | mriedem | i guess no one is multicell in pike right now, that we know of | |
| 17:11:46 | mriedem | but yeah | |
| 17:11:59 | mriedem | cern would be the only one to have hit this | |
| 17:12:07 | dansmith | that we know of | |
| 17:12:10 | mriedem | right | |
| 17:12:27 | mriedem | could be chinese telecoms that have backported this to havana already | |
| 17:12:28 | dansmith | melwitt: ready to approve this? https://review.openstack.org/#/c/623284/4 | |
| 17:12:33 | sean-k-mooney | adrianc: actully this time the vf still had the vm mac for some reason if i changed it with "sudo ip link set enp1s0f1 vf 6 mac 1e:d5:87:7c:6f:b1" i can ping | |
| 17:13:06 | melwitt | dansmith: yeah, hang on | |
| 17:15:34 | dansmith | mriedem: why was that thing @synchronized in the first place? | |
| 17:15:49 | dansmith | changing that makes me more nervous than the mechanical lazy-loading | |
| 17:16:37 | mriedem | dansmith: (1) yes i said the same, i.e. i didn't really want to munge that into the lazy-load patch i had, and (2) looking at the change that added the lock, it was added as a precaution - i linked to that from the commit message | |
| 17:16:52 | dansmith | ah sorry | |
| 17:17:08 | dansmith | so you agree it's concerning but changed it anyway? | |
| 17:17:09 | mriedem | jay, chris and eric seemed to think it was fine to remove the lock | |
| 17:17:24 | mriedem | i didn't really want to change it within the same change that does the lazy-load, | |
| 17:17:27 | melwitt | I wondered the same. last efried had mentioned about it, I thought he had said the lock was needed. but didn't get into details | |
| 17:17:28 | mriedem | but jay -1ed me over it | |
| 17:17:45 | melwitt | but maybe I missed convo after that | |
| 17:17:50 | mriedem | i don't care if we remove the lock or not really | |
| 17:18:04 | mriedem | i didn't really want to do squash both things into the same patch, but again, the -1 | |
| 17:18:15 | mriedem | honestly i just wanted to move forward with it, | |
| 17:18:18 | mriedem | but now jay and eric are gone | |
| 17:18:49 | dansmith | I guess I'd just rather remove it but in a separate patch to avoid co-mingling the effects of these two changes, if we have to revert one, etc | |
| 17:18:57 | dansmith | but I'm probably over-thinking it | |
| 17:19:22 | mriedem | i thought the same | |
| 17:19:34 | dansmith | heh, your logs are flooded with the rpc thing, while looking for flooding with placement messages | |
| 17:19:43 | dansmith | getting all these committed would be, like, good | |
| 17:19:58 | mriedem | yes, i'm spinning several gate plates right now | |
| 17:20:03 | mriedem | thought about sending a summary to the ML | |
| 17:20:05 | melwitt | I'd want them separate for the potential revert reason too but since you've already been through the wringer on it, so we could just go ahead and do a partial revert if we have to for the lock thing *shrug* | |
| 17:20:27 | mriedem | i can also just remove the lock part of this if dansmith and melwitt agree to approve the lazy-load today | |
| 17:20:37 | mriedem | and throw the lock remove at the end | |
| 17:20:52 | mriedem | i will knife someone if i have to redo this again and then wait | |
| 17:20:53 | dansmith | I was about to +2, so I'd definitely +2 two patches instead yeah | |
| 17:20:58 | dansmith | but whatever | |
| 17:21:00 | melwitt | I'm fine with removing the lock since it seems like everyone who knows about it said to just do it. just we're aware there might be fallout and have to revert that piece | |
| 17:21:09 | mriedem | i shall redo it then | |
| 17:21:24 | sean-k-mooney | adrianc: http://paste.openstack.org/show/737154/ seting the vf mac via the pf fixes the issue | |
| 17:21:25 | dansmith | mriedem: I will stand by for immediate +2age | |
| 17:35:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Only construct SchedulerReportClient on first access from API https://review.openstack.org/623246 | |
| 17:35:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DRY up SchedulerReportClient init https://review.openstack.org/623247 | |
| 17:35:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove lock on SchedulerReportClient._create_client https://review.openstack.org/624770 | |
| 17:35:15 | mriedem | dansmith: melwitt: ^ | |
| 17:35:35 | dansmith | you know, thinking about this.. maybe they should be one patch. | |
| 17:35:42 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Fail to live migration if instance has a NUMA topology https://review.openstack.org/611088 | |
| 17:36:29 | mriedem | i hope you're just fucking with me | |
| 17:36:49 | dansmith | well, hear me out here | |
| 17:37:26 | dansmith | heh | |
| 17:38:31 | mriedem | dansmith: remember looking at this? https://bugs.launchpad.net/nova/+bug/1799298 | |
| 17:38:31 | openstack | Launchpad bug 1799298 in OpenStack Compute (nova) rocky "Metadata API cross joining instance_metadata and instance_system_metadata" [Medium,Triaged] | |
| 17:38:35 | mriedem | did anything come of that? | |
| 17:39:17 | dansmith | the thing that came out of it is I'm not sure it's worth the pain, but I did start on it | |
| 17:39:40 | mriedem | well, as a simple partial fix, we could just stop joining on system_metadata | |
| 17:39:52 | mriedem | since as far as i know that's only used if you've got a dynamic vendordata provider | |
| 17:40:06 | spatel | sean-k-mooney: Hey! | |
| 17:40:21 | dansmith | yeah | |
| 17:40:29 | mriedem | we likely don't need to join on security_groups either... | |
| 17:41:09 | spatel | I have question, i have VLAN 200 in openstack with /24 public IP | |
| 17:41:28 | sean-k-mooney | sure ok | |
| 17:41:36 | spatel | that /24 about to get full, is it possible i can add new /24 pool in same VLAN 200? | |
| 17:41:56 | sean-k-mooney | yes neutron allows you to add multiple subnets to the same network | |
| 17:42:19 | sean-k-mooney | you will need to add the second subnet to the router also | |
| 17:43:29 | spatel | I have VLAN base networking not tenant base.. | |
| 17:43:44 | spatel | This is the command i used to create my first subnet.. | |
| 17:43:48 | spatel | neutron subnet-create net_pub_vlan_200 71.xxx.xxx.0/24 --name sub_pub_vlan_200 --allocation-pool start=71.xxx.xxx.2,end=71.xxx.xxx.254 --dns-nameservers 8.8.8.8 --gateway=71.xxx.xxx.1 | |
| 17:44:17 | sean-k-mooney | spatel: we should peroably swap to the neutron channel but that is fine | |
| 17:45:03 | sean-k-mooney | vlan networks are still teant networks the terminology is a littel overloaded | |
| 17:45:10 | spatel | You are saying i add just add new public IP in same "net_pub_vlan_200" network? | |
| 17:45:55 | sean-k-mooney | yes you can | |
| 17:46:15 | spatel | Something like this? | |
| 17:46:36 | spatel | neutron subnet-create net_pub_vlan_200 72.xxx.xxx.0/24 --name new_subnet_vlan_200 --allocation-pool start=72.xxx.xxx.2,end=72.xxx.xxx.254 --dns-nameservers 8.8.8.8 --gateway=72.xxx.xxx.1 | |
| 17:46:55 | sean-k-mooney | yep | |
| 17:46:58 | spatel | net_pub_vlan_200 will be same right? | |
| 17:47:13 | spatel | perfect!! thanks for confirmation :) | |
| 17:47:46 | sean-k-mooney | the only other thing you need to do is add a new prot to the openstack or phyical router to connect to the new subnet | |