| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-12 | |||
| 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: DRY up SchedulerReportClient init https://review.openstack.org/623247 | |
| 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: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 | openstack | Launchpad bug 1799298 in OpenStack Compute (nova) rocky "Metadata API cross joining instance_metadata and instance_system_metadata" [Medium,Triaged] | |
| 17:38:31 | mriedem | dansmith: remember looking at this? https://bugs.launchpad.net/nova/+bug/1799298 | |
| 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 | |
| 17:48:07 | spatel | new port? | |
| 17:49:09 | sean-k-mooney | if you are using a phyical provider router you need to asing 72.xxx.xxx.1 to it so it can act as a gatway but if you are using neutron routers then you just need to add a port on the neutron router to connet to n 72 subnet | |
| 17:50:45 | spatel | oh! yes i am running HSRP so yes.. i have to setup HSRP on my gateway switches :) | |
| 17:50:52 | sean-k-mooney | spatel: you can use the openstack router add subnet <route> 72.xxx.xxx.2 | |
| 17:52:10 | sean-k-mooney | ah ok then ya you are using phyical routers instead of neutron routers for you public network so you can skip the openstack router add subnet command | |
| 17:59:21 | spatel | yes!! | |
| 18:00:04 | spatel | sean-k-mooney: quick question, now i am planning to build new Openstack cloud with NATing style floating ip, not VLAN base | |
| 18:00:31 | spatel | how do i scale that network? we have super high PPS rate in network... does virtual router can handle that traffic? | |
| 18:00:47 | spatel | I have option for DVR | |
| 18:01:59 | sean-k-mooney | spatel: lets take the converstation to #openstack-neutron | |
| 18:06:50 | spatel | sean-k-mooney: thanks :) | |
| 18:07:50 | mriedem | dansmith: can you think of anything besides flavor that we would have data migrated from system_metadata in the meta-api? i was thinking keypairs but that was different i think - it was a separate table and the data was migrated to extras | |
| 18:08:16 | dansmith | yeah, not keypairs | |
| 18:08:34 | dansmith | nothing off the top of my head, but I haven't thought about it much | |
| 18:18:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Be smarter about DB joins in the metadata API https://review.openstack.org/624778 | |
| 18:18:32 | mriedem | easy peasy ^ | |
| 18:47:15 | openstackgerrit | Chris Dent proposed openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941 | |
| 18:50:24 | openstackgerrit | Chris Dent proposed openstack/nova master: Delete the placement code https://review.openstack.org/618215 | |
| 21:08:30 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Handle tags in _bury_in_cell0 https://review.openstack.org/624813 | |
| 21:43:47 | brandor5 | hello everyone: can anyone tell me where I can find the newton nova api reference? | |
| 21:48:07 | jonher | brandor5: this? https://developer.openstack.org/api-ref/compute/ | |
| 21:48:31 | brandor5 | jonher: that's latest, I need the one for newton | |
| 21:49:07 | brandor5 | I'm trying to use the api to confirmResize after a migrate and I'm getting an error | |
| 21:49:16 | brandor5 | Cannot 'confirmResize' instance e1782f5c-7559-4cac-a628-6d4a75a015f4 while it is in vm_state stopped | |
| 21:50:04 | brandor5 | If i run `nova resize-confirm <instance_id>` it works and I'm running the same curl that it runs... | |
| 21:51:05 | mriedem | brandor5: the api-ref on master should be the same for newton - where there are functional differences they should be called out with notes or microversions | |
| 21:51:13 | mriedem | i.e. the api should be backward compatible | |
| 21:51:27 | brandor5 | mriedem: oh cool, thanks... any idea on the error I'm seeing? | |
| 21:51:38 | brandor5 | especially that it works when I use the command line client | |
| 21:52:18 | mriedem | can't confirm a resize on a stopped vm in newton https://github.com/openstack/nova/blob/newton-eol/nova/compute/api.py#L2924 | |
| 21:52:38 | mriedem | nor master https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3489 | |
| 21:53:19 | brandor5 | hmm that's weird because `nova resize-confirm <instance id>` definitely works | |
| 21:53:32 | mriedem | works works? or just doesn't say it failed? | |
| 21:53:38 | brandor5 | works works | |
| 21:53:40 | mriedem | which version of novaclient? | |
| 21:53:56 | brandor5 | 10.1.0 | |
| 21:54:29 | brandor5 | and when I run nova in debug I've verified that I'm running the same 'curl' that novaclient is running | |
| 21:55:05 | mriedem | no magic there https://github.com/openstack/python-novaclient/blob/10.1.0/novaclient/v2/servers.py#L1533 | |
| 21:55:44 | mriedem | can you show the server status before doing each (cli and curl) to verify? | |
| 21:56:10 | brandor5 | yeah, I'm doing that... I have a watch running `openstack server show <instance_id>` | |
| 21:56:29 | brandor5 | if I try to hit the api directly I get a 409 | |
| 21:56:36 | mriedem | so you have some script or something that's just auto-confirming a resize as soon as the instance status is VERIFY_RESIZE? | |
| 21:56:37 | brandor5 | if I use novaclient it works | |
| 21:56:44 | brandor5 | correct | |
| 21:56:56 | mriedem | there is a config option for auto-confirming migrations | |