Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-17
15:25:46 melwitt gmann: oh I see
15:26:12 sean-k-mooney gmann: it can be done as a follow up but you cant specify a different local_conf section per version
15:26:18 sean-k-mooney you can do it for localrc
15:26:27 gmann sean-k-mooney: i could not get chance to find gzip log place for legacy jobs. busy for tempest plugins py2-drop drama bug.
15:26:38 sean-k-mooney but localrc does not allow you to set the post-config updates
15:28:01 gmann sean-k-mooney: yeah that(different local_conf section) is true, i failed to do that while IPv6 enable for legacy jobs.
15:28:44 gmann but i am not sure why devstsack fix is wrong, waiting for frickler re-reply
15:34:08 sean-k-mooney gmann: we will need that to be able to test placement reshapes on upgrade in grenade
15:34:39 sean-k-mooney because we sill need to change form using vcpu_pin_set to cpu_share_set and cpu_dedicated_set
15:34:51 sean-k-mooney although we dont test that today so its not required to move
15:35:53 sean-k-mooney im sure there are other examples too but having the ablity to specifc new/old/shared local_conf sections in the zuul.yaml will be useful
15:38:25 tosky melwitt: "mostly" - for some reasons, after we switched to Python 3, several python 2 packages are installed anyway, including python-openstackclient
15:39:16 tosky melwitt: so whenever "openstack foo" is called, the py2 version is used; and when the sahara plugin (or heat plugin) tries creating resources with "openstack dosomething", its own osc plugin (py3 only) is not found
15:39:23 gmann sean-k-mooney: or we can do that via direct config change via roles. something to explore may be.
15:39:26 tosky I'm failing to understand where the issue is
15:40:06 tosky gmann, sean-k-mooney or the from-<foo> update plugin maybe
15:40:09 melwitt I see
15:40:37 sean-k-mooney gmann: we could but im not sure that would be better. if it requrie new roles to be written i think it would be worse the adding supprot for local.conf in grenade
15:40:49 lyarwood random question, what's the best way of checking the stability of a given job over the last x number of months?
15:41:19 sean-k-mooney tosky: it might be the fact that on older brances we install everything twice. once under py3 then again under py2
15:41:26 gmann lyarwood: http://status.openstack.org/openstack-health/#/
15:41:37 sean-k-mooney tosky: we only stopped doing that in ussuri
15:41:39 gmann you can filter the jobs and time period
15:41:47 tosky sean-k-mooney: devstack, you mean? A pure devstack job does not install all those stuff
15:41:51 gmann but data is only for the gate pipeline
15:42:00 sean-k-mooney tosky: yes in devsack
15:42:11 lyarwood gmann: ack thanks
15:42:22 tosky sean-k-mooney: but comparing with a devstack job, I see much more components; so something happens in the grenade-specific roles
15:42:53 sean-k-mooney https://github.com/openstack/devstack/commit/63ab664baf99716e9a5d29eb82f974f8c3456816
15:42:58 sean-k-mooney tosky: ^
15:43:01 lyarwood gmann: so this wouldn't help if I wanted to look at NV jobs in the check queue right?
15:43:26 lyarwood gmann: trying to figure out a way of showing something is now stable and can be made voting
15:43:27 gmann oh . yeah n-v jobs data are not there
15:43:39 lyarwood kk np
15:43:48 lyarwood and thanks :)
15:44:47 tosky sean-k-mooney: but then I shouldn't see this in master
15:44:54 tosky sean-k-mooney: so there must be something else too
15:45:12 sean-k-mooney on master no but grenade installs with train frist then upgrdaes to master
15:45:20 sean-k-mooney so all the train deps will be installed with both
15:45:28 tosky oh, right
15:45:34 sean-k-mooney then we will upgrade to train without updateing the python 2 deps
15:45:51 tosky this means that when we install train/py3 we have a problem
15:46:14 tosky not a problem normally, as train is technically py2 for devstack
15:46:19 tosky but I'm not sure how to solve
15:46:24 sean-k-mooney yes well a traing/py3 intsall install both under py3 and py2
15:46:40 sean-k-mooney tosky: well no
15:46:50 sean-k-mooney train should would with python 3 aswell
15:46:57 efried gibi: if you have a second, could you please remind me the context around why we're parsing a RP name to identify an interface?
15:48:01 sean-k-mooney tosky: what is the specific issue you are having
15:48:53 sean-k-mooney one way to solve it would be do a pip freeze and unistall any openstack package that is installed
15:49:00 sean-k-mooney on python 2
15:52:32 tosky sean-k-mooney: see my comment above: both versions of osc are installed, but the osc plugins are py3 only, and then the py2 openstack fails to use them
15:55:34 sean-k-mooney ya so that is the same issue we have with console_scripts entry points
15:56:08 sean-k-mooney the python 2 version of osc console sript overites teh python 3 version on train
15:56:56 sean-k-mooney so grenade or devstack could be updated to explictly remvoe osc everytime it stacks
15:57:12 sean-k-mooney and install it again
15:57:15 sean-k-mooney that should fix it
15:58:31 tosky maybe devstack; at the end, if it's USE_PYTHON3, pip uninstall python-openstackclient (keeping the 3 version)
16:01:06 sean-k-mooney tosky: well it would want to do it near the start not the end
16:01:30 sean-k-mooney because you want to have it installed and ensure any place we use it in devstack to do things wew use the correct one
16:02:09 sean-k-mooney also you want it to deffinetly happen before the local.sh gets executed as its common to use the client to do things in the local.sh
16:03:55 tosky sean-k-mooney: so basically tune the piece of code you mentioned above to not install the py2 version of osc?
16:04:44 sean-k-mooney am i guess you could do that too. i was thinking of adding a new function that gets invoked after the install phase but before the post-config phase
16:05:55 tosky gmann: any thoughts about this ^ ?
16:06:21 gmann sorry, did note read that. too many bugs for py2 :(
16:06:28 gmann did not
16:10:14 gmann i will followup on that later on review
16:17:56 KeithMnemonic1 hello all. one last plea to get this merged https://review.opendev.org/683008 . We have confirmation from the customer that this resolves the issue they were seeing with their Lenovo storage.
16:18:33 KeithMnemonic1 this was that issue we had with the cinder stuff jungleboyj: if you recall and the DS6200.
16:19:00 stephenfin artom, efried: Did you folks get any closer to figuring out that nova-live-migration gate issue yesterday?
16:19:51 sean-k-mooney lyarwood: could you review KeithMnemonic1 backport
16:19:52 jungleboyj KeithMnemonic1: Ah, glad that you guys were able to make a change there.
16:20:31 KeithMnemonic1 it was the issue gorka said, losing track of the luns
16:22:12 jungleboyj Bakcport makes sense to me.
16:31:23 Sundar Hi sean-k-mooney: How's the deployment coming along?
16:32:04 openstackgerrit sean mooney proposed openstack/nova stable/rocky: Remove 'test_cold_migrate_with_physnet_fails' test https://review.opendev.org/703115
16:32:04 openstackgerrit sean mooney proposed openstack/nova stable/rocky: Block rebuild when NUMA topology changed https://review.opendev.org/703116
16:32:05 openstackgerrit sean mooney proposed openstack/nova stable/rocky: Disable NUMATopologyFilter on rebuild https://review.opendev.org/703117
16:32:05 openstackgerrit sean mooney proposed openstack/nova stable/rocky: FUP for in-place numa rebuild https://review.opendev.org/703118
16:32:32 sean-k-mooney Sundar: i have been trying to do some backport today before the weekend so ill likely get back to it again tomorow
16:32:37 sean-k-mooney well monday
16:33:24 Sundar sean-k-mooney: NP. Have a good weekend.
16:34:39 artom stephenfin, https://review.opendev.org/#/c/702960/
16:37:13 stephenfin artom: ta
16:42:59 belmoreira Hi, I'm trying to boot an aarch64 image on x86_64 compute node and initially I though would be easy... but I'm still struggling. I was assuming that I just needed to define the arch in the image and nova will use that to trigger qemu-system-arm, but apparently not. Googling about it I can't find any answer... only similar questions. Do you have any pointer?
16:43:41 sean-k-mooney you can only do that if you set the virt type to qemu
16:43:52 sean-k-mooney and then i belive you have to set a nova config option
16:44:57 sean-k-mooney i belive you have to configre the machine types
16:44:59 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_machine_type
16:45:43 belmoreira sean-k-mooney yes, I'm doing the machine type
16:47:00 sean-k-mooney ok then i think provide virt_type=qemu is deiend and you have the arch set in the image i think that shoudl work
16:47:30 sean-k-mooney you might need to set a cpu model but if you do that would force the host to only be able to run aarch64
16:47:53 sean-k-mooney we do not have a way to set a cpu model per arch
16:49:12 belmoreira what I tried: virt_type=qemu and hw_machine_type=aarch64=machinetype1
16:49:31 belmoreira also the image is set with the correct arch
16:49:35 sean-k-mooney what is the error you get
16:49:53 sean-k-mooney you might need to set [libvirt]/cpu_models
16:50:22 belmoreira libvirt.libvirtError: XML error: No PCI buses available
16:51:02 sean-k-mooney well machinetype1 is not a real machein type
16:51:19 sean-k-mooney it was an example for the config you need to use a real one

Earlier   Later