| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-26 | |||
| 19:23:19 | mriedem | devstack doesn't set glance.api_servers either | |
| 19:23:47 | imacdonn | oh yeah, I'm blind | |
| 19:23:53 | imacdonn | I wonder why I'm getting this, then... | |
| 19:24:23 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] "interfaces: %s" % interfaces) | |
| 19:24:23 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] File "/usr/lib/python2.7/site-packages/nova/utils.py", line 1373, in get_endpoint | |
| 19:24:23 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] endpoint = utils.get_endpoint(ksa_adap) | |
| 19:24:23 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 126, in get_api_servers | |
| 19:24:27 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] EndpointNotFound: Could not find requested endpoint for any of the following interfaces: ['internal', 'public'] | |
| 19:24:41 | mriedem | i probably know why | |
| 19:24:54 | mriedem | https://review.openstack.org/#/c/554703/ | |
| 19:25:32 | imacdonn | 4 days ago, eh? that seems plausible | |
| 19:26:57 | imacdonn | will have to see if I'm doing something "the old way" ... removed the api_servers option to try to be current :) | |
| 19:27:59 | imacdonn | I guess maybe it's the code, not me ... not using versioned notifications | |
| 19:31:44 | mriedem | this isn't about versioned notifications | |
| 19:31:56 | mriedem | it's about notifications sent during periodic tasks where we don't have a token | |
| 19:32:26 | imacdonn | You comment says "there isn't much the operator can do about it outside of (1) switching entirely to versioned notifications, which not many people are using yet if at all, or ...." | |
| 19:32:27 | openstackgerrit | Eric Fried proposed openstack/nova master: Slugification utilities for placement names https://review.openstack.org/556628 | |
| 19:32:32 | efried | cdent: For nosey parkers ^ | |
| 19:39:35 | openstackgerrit | melanie witt proposed openstack/nova master: Migrate tempest-dsvm-multinode-live-migration job in-tree https://review.openstack.org/555945 | |
| 19:42:29 | openstackgerrit | Eric Fried proposed openstack/nova master: doc: Upgrade placement first https://review.openstack.org/556631 | |
| 19:42:40 | efried | mriedem, jaypipes, dansmith, sean-k-mooney cdent edleafe ^ | |
| 19:57:06 | openstackgerrit | Eric Fried proposed openstack/nova master: Get rid of 406 paths in report client https://review.openstack.org/556633 | |
| 19:57:17 | efried | mriedem, jaypipes, dansmith, sean-k-mooney cdent edleafe and ^ | |
| 19:57:27 | efried | dev ML note coming soon | |
| 19:57:56 | cdent | efried is a stack not a queue | |
| 19:58:26 | efried | cdent: Too true, much to my dismay. | |
| 19:58:48 | cdent | takes all kinds | |
| 20:02:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "bind_ports_to_host" neutron API method https://review.openstack.org/523604 | |
| 20:02:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370 | |
| 20:02:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423 | |
| 20:02:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "activate_port_binding" neutron API method https://review.openstack.org/555947 | |
| 20:02:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method https://review.openstack.org/552170 | |
| 20:02:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron https://review.openstack.org/556334 | |
| 20:02:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Delete port bindings in setup_networks_on_host if teardown=True https://review.openstack.org/556333 | |
| 20:02:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Port binding based on events during live migration https://review.openstack.org/434870 | |
| 20:02:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: compute: use port binding extended API during live migration https://review.openstack.org/551371 | |
| 20:02:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate https://review.openstack.org/522537 | |
| 20:05:09 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement stable/queens: Migrate legacy-osc-placement-dsvm-functional job in-tree https://review.openstack.org/556635 | |
| 20:09:48 | mriedem | esberglu: why is tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_create_list_show_delete_interfaces_by_network_port[id-73fe8f02-590d-4bf1-b184-e9ca81065051,network] skipped in https://review.openstack.org/#/c/546813/ ? | |
| 20:15:32 | openstackgerrit | Merged openstack/nova master: Standardize '_get_XXX_constraint' functions https://review.openstack.org/385071 | |
| 20:23:40 | cfriesen | Suppose I have a stopped instance. I then restart nova-compute. It appears that _init_instance() will call self.driver.plug_vifs() unconditionally. Is this expected/necessary? Won't we call plug_vifs from the power_on() code anyways? | |
| 20:36:31 | openstackgerrit | Merged openstack/nova master: tox: Fix indentation https://review.openstack.org/556543 | |
| 20:38:15 | esberglu | mriedem: We're working on a solution to that. Right now to attach interfaces we need to wait for the RMC connection to become active for the instance | |
| 20:38:32 | esberglu | Which takes a really long time (like 10 minutes) | |
| 20:39:01 | esberglu | We're trying to get something going in our CI that will pre-spawn the instances so that they are ready by the time tempest gets to that test | |
| 20:41:59 | mriedem | esberglu: ok then you just have some small things to update in that patch and i'll be +2 on it | |
| 20:43:06 | esberglu | mriedem: ack. Thanks for the review | |
| 20:47:36 | efried | mriedem: D'oh, I totally shoulda thought to send that mail to the ops list. Thanks for forwarding. | |
| 20:59:19 | imacdonn | mriedem efried Another stupid question.... for things like neutron, placement, etc., is it reasonable to assume that if I don't need to override them, the keystone stuff from [keystone_authtoken] (auth_url, auth_type, etc.) should apply? It seems somewhat inconsistent .. e.g. it seems to work for cinder, but not for neutron | |
| 21:00:30 | efried | imacdonn: Some services operate under admin context, some user context, some both depending on the code path. | |
| 21:01:53 | efried | imacdonn: ...uuhhhh, and that's apparently all I've got to say on that. | |
| 21:02:07 | efried | imacdonn: I was composing more stuff to say and realized I really don't know how it works. | |
| 21:02:15 | efried | I would have to go do some digging. | |
| 21:02:19 | imacdonn | efried: heh, OK ... thinking through this ... does it mean that cinder is working because it's reusing the user's auth token ? | |
| 21:02:47 | efried | I think sdague probably has this in his head without sleuthing. | |
| 21:03:59 | sdague | imacdonn: it is working because it uses the user's token | |
| 21:04:18 | imacdonn | sdague: right ... that makes sense .. thanks | |
| 21:04:29 | sdague | the prefered model is the user auths to the first service or keystone, and then that token gets used for the users through the whole flow | |
| 21:04:58 | sdague | which ensures that if there is a bug in the code, the user permissions restrict how much damage they can do | |
| 21:05:53 | imacdonn | sdague: Understood. It makes sense now. | |
| 21:10:07 | openstackgerrit | Eric Fried proposed openstack/nova master: doc: Upgrade placement first https://review.openstack.org/556631 | |
| 21:22:12 | cfriesen | does anyone know why we call driver.plug_vifs() in _init_instance() for a stopped instance? | |
| 21:22:19 | cfriesen | looks like that code has been there forever | |
| 21:23:03 | cfriesen | I'm wondering if it's a lowest-common-denominator virt driver thing | |
| 21:23:08 | kashyap | cfriesen: melwitt: dansmith: Since I'm awake, thinking a bit more on https://review.openstack.org/#/c/534384/15/nova/virt/libvirt/driver.py: While I agree that failing at Nova start up is better it seems better to hard-fail _at_ instance start up, much like we do for 'mode' and 'model'? | |
| 21:23:33 | kashyap | If you see we're actually hard-failing for 'custom' and 'mode' just in the driver.py file | |
| 21:24:05 | cfriesen | kashyap: arguably we should hard-fail those at nova-compute startup too. | |
| 21:24:08 | kashyap | IMHO, it just is consistent (for better or worse) to raise exception.Invalid()fail for the closely related 'extra_flags' too. | |
| 21:24:13 | kashyap | cfriesen: Yes, exactly! | |
| 21:24:20 | kashyap | cfriesen: But that's a surgery for different day | |
| 21:24:32 | kashyap | I'm curious if anyone can poke holes in the above logic | |
| 21:24:37 | dansmith | cfriesen: mode is protected by choices | |
| 21:24:44 | dansmith | er, kashyap | |
| 21:24:56 | dansmith | kashyap: and model is defined in the libvirt cpu models xml, which can be custom-written | |
| 21:25:24 | kashyap | dansmith: Custom-writing models is a horrible thing to do | |
| 21:25:31 | dansmith | kashyap: that has nothing to do with it | |
| 21:25:37 | kashyap | (It'll just cause untold pain.) | |
| 21:25:51 | dansmith | kashyap: also, we've paved the way for you to be able to backport this with minimal change, so it'd be cool if we could just not argue over minutia | |
| 21:25:55 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924 | |
| 21:25:56 | dansmith | lots of people have opined at this point | |
| 21:25:59 | kashyap | dansmith: Sure, I'm not saying otherwise (on your earlier point). | |
| 21:26:11 | kashyap | dansmith: Oh, I actually _did_ make the LOG.warning thing | |
| 21:26:23 | kashyap | Locally | |
| 21:26:41 | kashyap | dansmith: But I'm just trying to discus in good spirit, as it seems to make logical sense given the existing structure | |
| 21:27:59 | dansmith | kashyap: one could argue that if we made you do it as a workaround flag this would be moot, | |
| 21:28:12 | dansmith | so arguing for it further might work against us here :) | |
| 21:28:31 | kashyap | dansmith: C'mon :-) | |
| 21:28:52 | kashyap | dansmith: I'm amenable to reason (contrary to what you seem to imply :P) | |
| 21:29:37 | kashyap | But we know that the 'workaround' is just needless work for the poor deployment folks. That's why you concurred w/ me on that | |
| 21:29:41 | kashyap | Anyway. | |
| 21:30:18 | melwitt | I thought we were restricting choices to 'pcid' through the config option choices anyway, no? why do we need this check? | |
| 21:30:31 | dansmith | melwitt: we can't via config | |
| 21:30:33 | kashyap | melwitt: We are restricting the choices, indeed. | |
| 21:30:34 | dansmith | for listopt | |
| 21:30:40 | kashyap | Ah, not via config, though. | |
| 21:30:42 | dansmith | that's the point of the thread | |
| 21:30:51 | melwitt | I replied to the ML with an example where we do. does that not work? | |
| 21:31:28 | kashyap | Sorry, haven't checked the thread yet. (It's late, and I'm slowly getting back to thinking in English, after 3-ish hours of straight Dutch.) | |
| 21:31:53 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM: Add proc_units_factor conf option https://review.openstack.org/554688 | |
| 21:31:56 | dansmith | melwitt: ah I see now, I guess kashyap was confused? | |