| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-26 | |||
| 10:59:22 | Jack_V | I'm upgrading from mitaka to newton | |
| 10:59:42 | Jack_V | and got this error during creation an instance from a volume | |
| 10:59:49 | Jack_V | InvalidInput: Invalid input received: Invalid image identifier or unable to access requested image. (HTTP 400) | |
| 11:08:53 | openstackgerrit | melanie witt proposed openstack/nova: Count resources to check quota for cells https://review.openstack.org/416521 | |
| 11:10:18 | mdbooth | mfeoktistov: Did you read the ML traffic on the privsep thing? | |
| 11:10:43 | mdbooth | Sounds like the concensus is that you should just go ahead and use rootwrap. Oh, and do it quickly ;) | |
| 11:16:21 | mfeoktistov | mdbooth: Yes, thank you. I'll send patch in a minute | |
| 11:25:47 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova: libvirt: ephemeral disk support for virtuozzo containers https://review.openstack.org/312488 | |
| 11:34:56 | johnthetubaguy | andreykurilin: don't we support --os-auth-token and --os-token? | |
| 11:36:21 | andreykurilin | johnthetubaguy: I found note about --os-auth-token in the code, but there is no place if registration for that cli argument. PS: we use keystoneclient1 method for registrating identity cli arguments and it registrate just --os-token arg | |
| 11:36:34 | andreykurilin | *no place of | |
| 11:36:57 | johnthetubaguy | I guess we broke that at some point, oops | |
| 11:37:14 | johnthetubaguy | or we deprecated it, and only partially removed it | |
| 11:41:01 | johnthetubaguy | andreykurilin: are we missing OS_TOKEN environment variable reading, or does keystoneauth already do that for us? | |
| 11:45:04 | andreykurilin | johnthetubaguy: ok, I found commits for you:) | |
| 11:46:44 | andreykurilin | johnthetubaguy: os-token argument was introduced with deprecation of os-auth-token: https://github.com/openstack/python-novaclient/commit/1f11840dd84f3570330d1fcd53d1e8eea5ff7922 . Actually that commit broke env variable and the whole token auth method via cli. https://github.com/openstack/python-novaclient/commit/08c4b746b2b894a5cb178c762850a1730e1c636e made a proper deprecation for os-auth-token with warning message. And it was finnaly removed h | |
| 11:47:17 | andreykurilin | johnthetubaguy: So it looks like we can avoid usage of --os-auth-token, since we have a release note that it was deprecated and removed | |
| 11:47:41 | johnthetubaguy | yeah, that looks good, I vaguely remember deprecating those alias things, thank you! | |
| 11:48:12 | andreykurilin | but it sounds like you are right about env variable. keystoneauth doesn't do it for us | |
| 11:48:52 | andreykurilin | johnthetubaguy: should I update my patch (and lose bauzas vote) or send another one?:) | |
| 11:49:05 | johnthetubaguy | andreykurilin: feels like a follow on patch | |
| 11:49:16 | andreykurilin | ok. give me a minute | |
| 11:49:47 | johnthetubaguy | andreykurilin: bit worried about kevin's comment as well, feels like we should always access os_user_domain_id in a consistent way | |
| 11:49:58 | johnthetubaguy | but happy for that to be a follow on | |
| 11:50:56 | openstackgerrit | Stephen Finucane proposed openstack/nova: Cache boot time roles for vendordata. https://review.openstack.org/417780 | |
| 11:50:56 | openstackgerrit | Stephen Finucane proposed openstack/nova: Use a service account to make vendordata requests. https://review.openstack.org/415597 | |
| 11:50:57 | openstackgerrit | Stephen Finucane proposed openstack/nova: Optionally make dynamic vendordata failures fatal. https://review.openstack.org/416391 | |
| 11:51:07 | johnthetubaguy | sfinucan: I see you | |
| 11:51:13 | sfinucan | johnthetubaguy: Cached the tokens and added renos for all patches | |
| 11:51:15 | sfinucan | jinx :) | |
| 11:51:19 | andreykurilin | johnthetubaguy: if you look at previous patch-sets(for example this one - https://review.openstack.org/#/c/424256/8/novaclient/shell.py ), I tried several ways to make that lines a bit clear, but for some reasons I did not succed in making keystone v3 work | |
| 11:51:46 | johnthetubaguy | andreykurilin: lets do a separate patch that adds a test for that maybe? | |
| 11:52:17 | andreykurilin | ok, I'll try to do it again in folowwing patch | |
| 12:00:18 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient: [cli] Use environment variable for token https://review.openstack.org/425647 | |
| 12:01:38 | johnthetubaguy | andreykurilin: I added some questions, got confused about the SecretHelper stuff | |
| 12:13:15 | andreykurilin | johnthetubaguy: answered:) | |
| 12:23:13 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient: [cli] Use environment variable for token https://review.openstack.org/425647 | |
| 12:43:26 | claudiub | hi folks. any idea why nova list currently shows / returns an empty list (including with --all), even if I have spawned instances? | |
| 12:55:48 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/424828 | |
| 12:56:51 | sfinucan | alex_xu: Regarding https://review.openstack.org/#/c/394480 - does that require any changes on the RPC version? | |
| 12:57:33 | sfinucan | That's object gets sent over the wire, as far as I understand, and changes to what we send there necessitate RPC bumps | |
| 12:57:37 | sfinucan | ...or so I thought | |
| 13:09:18 | mdbooth | Extreme code smell is when reviewing a 6 line change requires a code audit of 2 other modules complete with notes: https://review.openstack.org/#/c/389593/2/nova/virt/libvirt/driver.py | |
| 13:14:32 | sfinucan | snikitin: https://review.openstack.org/#/c/399613 | |
| 13:17:00 | cdent | mdbooth: On some days I feel like that describes...everything | |
| 13:17:52 | mdbooth | cdent: Feeling all existential. I'm literally sitting here contemplating 'what does destroy_disks really *mean*' | |
| 13:18:17 | cdent | bauzas, mriedem, dansmith: is there somewhere for me to leap in? | |
| 13:18:39 | cdent | mdbooth: I think that all depends on your position on social construction of meaning | |
| 13:18:44 | mdbooth | lol | |
| 13:19:14 | bauzas | cdent: honestly, I still need to correctly understand the problem | |
| 13:19:36 | cdent | bauzas: Is there only one at this point? | |
| 13:20:13 | bauzas | cdent: yup, I fixed the functional issue | |
| 13:20:22 | bauzas | cdent: now, we still have the grenade problem | |
| 13:20:35 | bauzas | that's the blocking issue | |
| 13:20:41 | cdent | did mriedem option #4 not work (I haven't had a chance to check yet)? | |
| 13:20:59 | bauzas | which option, sorry? | |
| 13:21:40 | bauzas | oh, you mean the email ? | |
| 13:22:30 | cdent | yeah | |
| 13:23:53 | bauzas | well, #4 is not working yet | |
| 13:24:32 | bauzas | but I agree with mriedem about trying to have #4 and then if not working, doing #3 | |
| 13:24:42 | bauzas | but we need to have a consensus before | |
| 13:25:24 | cdent | I think 4 is the best choice | |
| 13:25:30 | cdent | (assuming we can make it work) | |
| 13:26:48 | bauzas | well, tbh, I hate the forced_host field | |
| 13:26:51 | bauzas | cdent: ^ | |
| 13:26:58 | bauzas | because it's silly | |
| 13:27:20 | bauzas | rather I prefer to use the requested_destination like we did for live-migrating and evacuate, ie. calling all the filters | |
| 13:27:28 | bauzas | but... | |
| 13:27:32 | johnthetubaguy | bauzas: so that option #3, I have a slightly different version that could help? | |
| 13:27:43 | cdent | Yeah, I understand there's quite a lot of history on force_host | |
| 13:27:49 | cdent | (social history) | |
| 13:27:55 | bauzas | if we don't find a solution for #4 today, then the scheduler calling the placement couldn't be merged by Ocata | |
| 13:28:25 | johnthetubaguy | bauzas: if we check for the min_compute service version, and fallback to [] if everything has been upgraded, and the full list of old computenodes if everything hasn't yet been upgraded? | |
| 13:28:29 | bauzas | johnthetubaguy: the fact is that we verify the forced field *after* getting the list of nodes | |
| 13:28:43 | bauzas | which is weirdo | |
| 13:28:57 | bauzas | because if you want to force to a destination, you don't care about others | |
| 13:29:01 | johnthetubaguy | oh, so the problem is different to what I am thinking it is, I thought it was just placement not being present | |
| 13:29:13 | bauzas | johnthetubaguy: nope, we fixed that by my grenade job | |
| 13:29:25 | johnthetubaguy | OK, so this is a different error now? | |
| 13:29:28 | johnthetubaguy | I missed that | |
| 13:29:33 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient: [cli] Use environment variable for token https://review.openstack.org/425647 | |
| 13:29:40 | bauzas | johnthetubaguy: yup, see mriedem's email from this early morning | |
| 13:29:54 | bauzas | johnthetubaguy: we have a tempest test that's blocking us for a very specific behaviour | |
| 13:30:12 | bauzas | I'll actually respond to mriedem | |
| 13:30:26 | johnthetubaguy | yeah, I was reading that and it seemed to say different | |
| 13:30:29 | bauzas | because I think the current forced_hosts thing is already weirdo | |
| 13:30:52 | cdent | could/should we reorder when force_host happens? | |
| 13:31:09 | johnthetubaguy | so its a test thats confirm we can build on "both" nodes I guess? | |
| 13:31:11 | bauzas | cdent: or just accepting [] for forced_hosts that's it :) | |
| 13:31:14 | johnthetubaguy | is thats whats failing here? | |
| 13:31:32 | bauzas | johnthetubaguy: it's failing because it forces to a destination using the --az hack that I *HATE* | |
| 13:32:07 | bauzas | johnthetubaguy: given the subnode is not yet providing its resources to placement, the placement call returns [] which fails later when looking at forced_hosts | |
| 13:32:25 | sfinucan | johnthetubaguy, raj_singh: could you enlighten me as to the purpose of these three lines https://github.com/openstack/nova/blob/master/nova/conf/neutron.py#L116-L118 | |
| 13:32:30 | johnthetubaguy | right, so thats a bigger issue though, we would want to the subnode to be providing its resources already, I assume? | |
| 13:32:39 | bauzas | johnthetubaguy: that's what we ask | |
| 13:32:58 | sfinucan | I'm guessing they refer to the various version of the neutron API and we only need one, but that's a guess | |
| 13:33:00 | sfinucan | https://github.com/openstack/watcher/blob/695ddf8ae7a2dccff4c62a28821888b7d49e2338/watcher/conf/_opts.py#L58 | |
| 13:33:06 | bauzas | johnthetubaguy: in theory, you have to configure your computes to talk to the placement service even if they're Newton | |
| 13:33:26 | bauzas | or you'd not get them when calling the placement | |
| 13:33:37 | johnthetubaguy | sfinucan: its what is done for neutron, it describes all the setting you can have for the password keystoneauth settings (i.e register_auth_conf_options), AFAIK | |