| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 15:59:05 | mriedem | hmm | |
| 16:02:10 | mordred | efried, mriedem: just reading scrollback - yes, I think you should stop using glanceclient. | |
| 16:02:34 | mordred | efried, mriedem is there a thing I can help debug? | |
| 16:03:25 | mriedem | https://bugs.launchpad.net/nova/+bug/1747511 | |
| 16:03:26 | openstack | Launchpad bug 1747511 in OpenStack Compute (nova) "server create fails with "Can not find requested image" when CONF.glance.api_servers is not set and [service_user] is set" [High,Confirmed] | |
| 16:03:35 | mriedem | https://review.openstack.org/#/c/541008/ | |
| 16:03:56 | mriedem | ^ shows that when nova uses ksa to find the image endpoint (rather than CONF.glance.api_servers), and [service_user] tokens, | |
| 16:04:07 | mriedem | we get an image endpoint url like image/v2/v2/ | |
| 16:04:37 | mriedem | http://logs.openstack.org/08/541008/2/check/legacy-tempest-dsvm-neutron-nova-next-full/f24c9d2/logs/screen-n-api.txt.gz#_Feb_05_21_46_51_455934 | |
| 16:05:10 | mriedem | http://logs.openstack.org/08/541008/2/check/legacy-tempest-dsvm-neutron-nova-next-full/f24c9d2/logs/screen-g-api.txt.gz#_Feb_05_21_46_51_651885 | |
| 16:05:25 | mriedem | GET /v2/v2/images/d5659eaf-1c56-4b35-970b-229a91b84bbd | |
| 16:05:30 | mordred | yes. you cannot find a proper endpoint and then pass it to glanceclient | |
| 16:05:49 | mriedem | efried said it was https://bugs.launchpad.net/python-glanceclient/+bug/1707995 | |
| 16:05:50 | openstack | Launchpad bug 1707995 in Glance Client "Can't use versioned endpoints" [Undecided,New] | |
| 16:06:09 | bauzas | mriedem: good point for https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L552 | |
| 16:06:13 | bauzas | about hrw | |
| 16:06:23 | bauzas | I just wonder if that should be in the same change, but meh | |
| 16:06:30 | mordred | mriedem, efried https://github.com/openstack/os-client-config/blob/master/os_client_config/cloud_config.py#L415-L430 | |
| 16:06:47 | mordred | that's what one has to do to make a glanceclient connection from an endpoint | |
| 16:07:22 | mriedem | bauzas: i bring it up because we are now implicitly requiring a minimum version of libvirt if using aarch64 https://review.openstack.org/#/c/538003/10/nova/virt/libvirt/config.py@1641 | |
| 16:07:26 | mriedem | due to that change ^ | |
| 16:07:28 | mriedem | which is why i kept -1ing it | |
| 16:07:32 | mriedem | but it was approved anyway | |
| 16:07:53 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Provide basic data for AArch64 support matrix/functionality https://review.openstack.org/541728 | |
| 16:08:01 | mriedem | mordred: ok let me hack that in quick | |
| 16:08:17 | bauzas | mriedem: oh okay, I wasn't knowing that | |
| 16:08:46 | hrw | mriedem: like I wrote in reply: index=0 is set on calling that class | |
| 16:08:48 | bauzas | mriedem: I discussing this GMT morning with hrw about live-migration not possible for ARM64 due to some libvirt config issue (not having the cpu model) | |
| 16:09:12 | mordred | mriedem: you can skip lines 423 and 424 - those are for different logic | |
| 16:09:19 | mriedem | hrw: oh here https://review.openstack.org/#/c/538003/15/nova/virt/libvirt/driver.py@4952 | |
| 16:09:24 | mriedem | hrw: ok i hadn't seen that update | |
| 16:09:51 | openstackgerrit | melissaml proposed openstack/nova-specs master: Modify grammatical errors https://review.openstack.org/541765 | |
| 16:09:58 | hrw | mriedem: no problem | |
| 16:13:34 | bauzas | hrw: comment in https://review.openstack.org/#/c/541728/2 | |
| 16:13:44 | bauzas | I could be wrong tho | |
| 16:13:58 | bauzas | we use "upgrade" section for telling operators what to change before upgrading | |
| 16:14:05 | hrw | ok | |
| 16:14:07 | bauzas | from the previous Nova version | |
| 16:15:01 | openstackgerrit | Dan Smith proposed openstack/nova master: Bump compute RPC API to version 5.0 https://review.openstack.org/541005 | |
| 16:15:02 | openstackgerrit | Dan Smith proposed openstack/nova master: Compute RPC client bump to 5.0 https://review.openstack.org/541035 | |
| 16:15:12 | bauzas | hrw: and you could link your feature matrix page to the relnote like I said by `feature matrix`_ | |
| 16:15:23 | hrw | bauzas: at Linaro we use 3.4.0-with-backports with newton, was 3.6.0+ with pike+ | |
| 16:15:53 | bauzas | hrw: same in Red Hat, sometimes libvirt features are backported to some RHEL version | |
| 16:16:12 | hrw | bauzas: I know ;) | |
| 16:16:14 | bauzas | hrw: but when telling which libvirt version people should use upstream, we use the project version | |
| 16:16:21 | bauzas | not the RH version | |
| 16:16:24 | hrw | bauzas: have rhel7 developer jacket in a closet ;D | |
| 16:16:30 | hrw | upstream first! | |
| 16:16:36 | bauzas | ;) | |
| 16:16:55 | bauzas | my hat is taking some dust | |
| 16:17:02 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Provide basic data for AArch64 support matrix/functionality https://review.openstack.org/541728 | |
| 16:17:07 | bauzas | I only used it by 4 years ago | |
| 16:17:29 | hrw | year ago I used it at local opensource conf | |
| 16:17:31 | cdent | was I supposed to return my hat when I left? It never fit, and now collects dust in a wardrobe (probably trying to make its way to narnia) | |
| 16:17:35 | mriedem | hrw: bauzas: given the time constraints for queens rc1, i'm good with a release note / feature support matrix docs update for queens, and update the check on driver startup in rocky | |
| 16:17:58 | bauzas | mriedem: hrw just provided a new rev | |
| 16:18:15 | bauzas | mriedem: just reviewing it and if okay, +2ing it | |
| 16:18:51 | mriedem | bauzas: i've also got your queens prelude reno up https://review.openstack.org/#/c/541495/ | |
| 16:18:59 | bauzas | mriedem: <3 | |
| 16:19:05 | mriedem | and a fix for the pike prelude https://review.openstack.org/#/c/541498/ | |
| 16:19:16 | bauzas | mriedem: saw the Foundation point about the reno notes ? | |
| 16:19:27 | mriedem | umm | |
| 16:19:34 | bauzas | how to not call the PTL about new features ? | |
| 16:19:36 | mriedem | release highlights in the releases repo? | |
| 16:19:38 | bauzas | yup | |
| 16:19:42 | mriedem | yes i know about that | |
| 16:19:44 | bauzas | cool | |
| 16:20:22 | bauzas | hrw: lemme fix some thing in your relnote | |
| 16:20:35 | hrw | feel free. you know that stuff better | |
| 16:20:37 | bauzas | hrw: you need to pass a link | |
| 16:26:24 | efried | mriedem: waitwait, how did https://review.openstack.org/#/c/541008/2 pass the nova-next job?? | |
| 16:27:37 | mriedem | efried: b/c i commented out the service user token code | |
| 16:27:43 | mriedem | to verify that was the combo that was breaking it | |
| 16:28:21 | efried | mriedem: Oh, I must have been looking at the wrong patch set. | |
| 16:29:30 | hrw | bauzas: ok, will dig | |
| 16:31:20 | efried | mriedem: Looks to me like that strip_version deal is gonna be the key. Need to remind myself what our aversion was to fixing the actual glanceclient bug... | |
| 16:35:49 | bauzas | hrw: I'm amending your note | |
| 16:35:58 | hrw | thx bauzas | |
| 16:36:12 | bauzas | hrw: I just entered a meeting, but I can work concurrently :) | |
| 16:36:28 | hrw | bauzas: I am in a meeting too | |
| 16:39:03 | stephenfin | mriedem: Have we a nova-neutron sync planned for the PTG? Could I add https://review.openstack.org/#/c/541290/ to that list? | |
| 16:39:40 | sean-k-mooney | stephenfin: what day is that on? the monday or tuesday or later in the week | |
| 16:44:07 | mriedem | stephenfin: nothing specifically scheduled yet, we have nova/cinder penciled in for thurs morning, | |
| 16:44:18 | mriedem | thursday has historically been our xp day | |
| 16:44:41 | mriedem | mon/tues is going to be vm/bm (keystone) stuff too, plus whatever else people go to (FFU, API WG, etc) | |
| 16:44:47 | mriedem | friday is misc / everything else | |
| 16:45:03 | mriedem | wed is likely priority topics for nova in rocky, which generally ends up being all about placement | |
| 16:45:28 | mriedem | so i assume nova/neutron love fest would be sometime thursday afternoon | |
| 16:46:48 | bauzas | mriedem: do we have hot topics for nova/neutron except the pre-allocation of ports in the conductor that nobody signed off yet to continue ? | |
| 16:47:06 | bauzas | mriedem: because stephenfin had the NUMA affinity thing in mind | |
| 16:47:18 | bauzas | and I think it's quite important for a lot of people | |
| 16:47:30 | stephenfin | bauzas: Jinx :) Scroll up | |
| 16:47:46 | bauzas | damn | |
| 16:47:56 | bauzas | we're harassing mriedem | |
| 16:47:59 | bauzas | come on | |
| 16:48:49 | mriedem | once we're past RC1 i plan on organizing the ptg etherpad a bit | |
| 16:49:06 | mriedem | until then, just put your topic ideas in there and i'll deal with them later | |
| 16:49:10 | cdent | mriedem: I've been playing around locally with the ideas you've done in your 1000 instance create thing: https://review.openstack.org/#/c/507918/ Can be a bit slow, but seems to behave. Now I'd like to change the parameters a bit and I'm not sure if I can: | |
| 16:49:14 | stephenfin | mriedem: Sweet. Thanks for the info. It's noted in the doc | |
| 16:49:56 | cdent | What I want to do is create a large number of nova-cpu processes (with the fake driver), but something needs to constrain for the fact that the resource providers needs to have different names (which usually comes from the hostname). Is there an already established way to do that? | |