Earlier  
Posted Nick Remark
#openstack-nova - 2019-11-08
11:48:52 openstackgerrit Akira KAMIO proposed openstack/nova master: VMware: disk_io_limits settings are not reflected when resize https://review.opendev.org/680296
12:04:00 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Remove native LUKS compat code https://review.opendev.org/669121
12:04:49 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Take an instance.uuid lock when rebooting https://review.opendev.org/673463
12:54:36 sean-k-mooney kashyap: can you rebase https://review.opendev.org/#/c/616603/9 on https://review.opendev.org/#/c/693210/1
12:55:09 kashyap sean-k-mooney: Yeah, was rebasing locally on master; will do in a bit. Doing paperwork now :-(
12:55:46 sean-k-mooney no worreis that patch just clean up the fact the rng code is called weridly via the qemu guest agent function
12:55:56 sean-k-mooney even though they are completely unrelated
12:56:21 kashyap (Nod)
13:38:48 openstackgerrit Archit Modi proposed openstack/nova stable/queens: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693239
13:39:25 openstackgerrit Archit Modi proposed openstack/nova stable/pike: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693236
13:40:43 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Use long_rpc_timeout in reserve_block_device_name https://review.opendev.org/693537
13:40:43 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Remove stale BDMs on reserve_block_device_name failure https://review.opendev.org/682594
14:22:13 artom sean-k-mooney, I have a Zuul quandry
14:22:39 sean-k-mooney oh how so
14:22:40 artom In https://review.opendev.org/#/c/691062/41/.zuul.yaml, I'm setting groups-vars for the peers group, which includes the compute
14:22:54 artom So for instance, WHITEBOX_SSH_USER_DIR
14:23:39 sean-k-mooney why the peers group
14:23:45 artom Which do not get picked up on the compute host: https://zuul.opendev.org/t/openstack/build/eeae2903b14c456793766e79efd6916d/log/compute/logs/devstacklog.txt.gz#9048
14:24:44 sean-k-mooney the whitebox plugin shoudl only need to be installed on teh contoler
14:25:14 artom We need it at least part of the setup to run on the compute host as well, for the SSH keys
14:25:46 artom 'cuz by default tempest runs as the 'tempest' user and it can't SSH anywhere
14:26:24 sean-k-mooney ok but you could do the ssh key setup as an ansible task
14:27:02 sean-k-mooney anyway so just trying to understand what proably you are hitting
14:27:16 sean-k-mooney you are not seeing the values take effect
14:27:19 artom I guess I could eh?
14:27:25 artom No, they're not being set
14:27:36 sean-k-mooney normaly we use subnode for devstack stuf
14:27:51 sean-k-mooney peers is only used to set up a vxlan tunnel between teh nodes
14:28:09 artom Should it matter? As long as the 'compute' node is in the group, which it is...
14:28:23 artom I'm using your own node definitions from your multi nfv job :)
14:28:33 sean-k-mooney it depends on how the ansible roles is written
14:28:50 sean-k-mooney yes and i alsye used subnode not peer
14:29:02 sean-k-mooney *always
14:30:15 sean-k-mooney by the way we only want the nodeset to be defiend in onepalce
14:30:15 artom One argument against using Ansible is that paramiko is finicky as fsck for its keys
14:30:29 sean-k-mooney im not sure about that
14:30:48 sean-k-mooney i have never had issues using keys creates with ssh-keygen
14:31:00 artom Well, maybe newer versions
14:31:04 artom But we're using 2.6.0 in the gate
14:31:20 sean-k-mooney older version fo ansibel are fine too
14:31:47 artom I'm kinda scared of going back
14:32:10 artom See, the exception that it gives has no bearing on reality, and I just discovered that recently
14:32:33 artom Failure to auth makes it throw a "not a valid OpenSSH key" exception
14:32:42 artom So maybe you're right, and I was lead astray by that
14:32:57 artom The real problem being authrozied_keys wasn't in place properly or something
14:33:15 sean-k-mooney ya likely
14:33:31 sean-k-mooney by the way are you are that you can see the renderd inventory in the job output
14:33:33 sean-k-mooney https://zuul.opendev.org/t/openstack/build/eeae2903b14c456793766e79efd6916d/log/zuul-info/inventory.yaml
14:34:19 sean-k-mooney artom: i think the problem is the subnodes devstack_localrc
14:34:33 sean-k-mooney is being used instead of peers
14:34:53 sean-k-mooney which is why i used subnode in my jobs
14:35:28 sean-k-mooney if you use subnode it will merge the section form the parent and the ones in your job
14:35:57 sean-k-mooney with your definition taking precidence
14:37:37 artom sean-k-mooney, oh, thanks!
14:37:50 artom Ugh, I know in my heart that ansible is the right way to do it
14:38:07 artom But I really don't want to revisit that
14:38:43 mriedem sean-k-mooney: you might have thoughts on helping the person in the mailing list trying to live migrate a vm between different ml2 backends on rocky which should be using the port binding stuff
14:38:47 sean-k-mooney just move the bits and you can leave devstack do it
14:38:53 mriedem i realize we don't have any troubleshooting docs for that
14:39:19 sean-k-mooney mriedem: i had not seen that but ill take a look.
14:39:28 sean-k-mooney it does not really work that well
14:39:37 sean-k-mooney there are still some gaps i think
14:40:07 mriedem i'm pretty sure you identified several gaps at the denver ptg after rocky which are still open
14:40:07 sean-k-mooney it shoudl work betwwen thigns like ml2/odl and ml2/ovs
14:40:21 sean-k-mooney ya i think we adressed 1 or two
14:40:23 mriedem e.. https://review.opendev.org/#/c/594527/
14:41:04 sean-k-mooney ya that was how we found that
14:41:38 sean-k-mooney if your going between linux bridge and ovs there as also an issue where we were not passing hte bridge name
14:41:53 sean-k-mooney and a few other minor things
14:46:23 dansmith lyarwood: have we not moved to using the qemu-integrated iscsi driver yet? I was thinking we had
14:47:01 lyarwood dansmith: nope, I actually nuked the code for that a while ago as nothing was using it.
14:47:11 dansmith huh, okay
14:47:35 lyarwood dansmith: the original implentation was pretty bad, I've got a note to look at reintroducing it if there was a need somewhere.
14:48:06 lyarwood https://review.opendev.org/#/c/668750/
14:48:10 lyarwood ^ was the removal btw
14:48:10 dansmith I thought we were supposed to be moving towards it because it's vastly better and simpler than attaching those to the host
14:49:01 dansmith ah recent
14:49:28 lyarwood it has been a long 4 months downstream ^_^
14:49:44 lyarwood dansmith: what prompted your question btw?
14:50:03 dansmith lyarwood: this volume cache spec that I don't like
14:50:23 mriedem i got tim bell's attention https://review.opendev.org/#/c/566473/
14:50:25 lyarwood ah
14:54:25 sean-k-mooney mriedem: it would be nice to see teh pending state become a thing and the reaper service either become a nova deliverable in its own repo or be broght in tree
14:54:45 mriedem double wrong
14:54:56 mriedem first, you have to do what i said in there and land the rebuilding from cell0 piece
14:54:56 sean-k-mooney no?
14:55:03 mriedem ignore pending for now
14:55:16 mriedem second, there was agreement that the reaper thing would be external to nova so we didn't need to own it
14:55:20 mriedem that's what the notifications are for
14:55:26 sean-k-mooney oh i taught that was already landed
14:55:54 sean-k-mooney oh ok
14:56:00 mriedem 1. build fails, goes to cell0, send notification. 2. external service consumes notification, purges spot instances based on it's own policy that nova doesn't care about, 3. external service triggers rebuild from cell0 on non-spot instance
14:56:11 sean-k-mooney well it would nice to be able to do premtiable isntance with openstack
14:56:21 mriedem sure, i agree :)
14:56:28 sean-k-mooney i guess i dont mind if its in or out of nova ownership
14:56:31 mriedem otherwise i wouldn't have spent time reviewing it
14:57:26 mriedem but it's also complicated enough that unless a core takes it over, it can't just be a thing thrown over the wall that gets worked on 1 day a week
14:58:01 sean-k-mooney ya, internally it would proably still land on the compute team to manage at redhat
14:58:03 mriedem with all the SIG hoopla and people that want stuff, there is always a laughable amount of effort put into a more than half day per week developer to push things
14:58:39 mriedem i'm not blaming theo, he did what he could and i'm sure he had other priorities downstream, especially since they already had that running in production

Earlier   Later