Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-22
20:00:11 sean-k-mooney or maybe it moved
20:00:16 sean-k-mooney it used to be http://intel-openstack-ci-logs.ovh
20:00:37 efried I think the 52. is aws
20:01:18 sean-k-mooney ya the pci ci used an aws log server. they moved to using our ovh one for a while i guess it moved back to aws at some point
20:01:20 efried yeah, that whole class A is amazon's. Not sure if that means aws, but probably
20:01:54 sean-k-mooney basicaly it just had to be a server that was not on the intel network
20:02:06 efried right, so the outside world could see it.
20:02:45 sean-k-mooney actully no os that you did not have to go through a 3 level security review to host an external facing service on the coperate network
20:03:10 efried yeah, that too
20:03:33 sean-k-mooney if its not on the copreate network it was way eaiser aslo the pci ci was originally in china which casued issues
20:04:07 efried okay, I'm going to dive over the firewall and throw some of this intel back at intel. Thanks for the help.
20:04:52 sean-k-mooney cool anyway my adivice would be to do something like im doing in the nfv ci test job
20:05:19 sean-k-mooney e.g. run standared tempest test but use a custom flavor or tweek teh vnic_type used in the tempest config
20:05:31 sean-k-mooney that will test 90% of the edgecases
20:05:50 sean-k-mooney at that point if the ci is stable it can be extended to test more neich things
20:07:13 mriedem dansmith: despite my typo in https://review.opendev.org/#/c/640197/ i'd like to get that in so we can move the grenade live migration job in-tree (this is under the queens backport) - because of devstack changes in queens + grenade i have to disable the ceph stuff in the grenade case, but it's either that or just drop the job altogether from queens which i'd like to avoid
20:07:48 mriedem the commit message attempts to explain the mess and reasoning for just punting and disabling the ceph case
20:09:26 dansmith okay
20:14:54 sean-k-mooney mriedem: speaking of ceph we have a downstream request to backport two of your patches to newton wich is eol upstrema. https://review.opendev.org/#/q/topic:bug/1635008+(status:open+OR+status:merged) i know its been quite a while but are you aware of any reaon of the top of your head why that woudl be a bad idea.
20:15:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional recreate test for regression bug 1825537 https://review.opendev.org/654066
20:15:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Drop source node allocations if finish_resize fails https://review.opendev.org/654067
20:15:30 openstack bug 1825537 in OpenStack Compute (nova) "finish_resize failures incorrectly revert allocations" [Medium,In progress] https://launchpad.net/bugs/1825537 - Assigned to Matt Riedemann (mriedem)
20:15:34 sean-k-mooney it looked resonable to me at first glance but just said i woudl ask
20:15:58 mriedem sean-k-mooney: yes
20:16:20 mriedem there was a regression introduced
20:16:39 sean-k-mooney oh im glad i asked :)
20:16:50 mriedem for $5 i'll tell you the secret
20:17:54 mriedem https://review.opendev.org/#/q/I6fc7108817fcd9df4a342c9dabbf14ab7911d06a
20:18:00 sean-k-mooney https://bugs.launchpad.net/charm-nova-compute/+bug/1671422?
20:18:01 openstack Launchpad bug 1671422 in OpenStack nova-compute charm "charms: nova/cinder/ceph rbd integration broken on Ocata" [Critical,Fix released] - Assigned to James Page (james-page)
20:18:08 mriedem that might be the other one
20:18:37 mriedem https://review.opendev.org/#/q/Ieba216275c07ab16414065ee47e66915e9e9477d
20:19:01 sean-k-mooney ok so it did not handel olde connection info. so if we are to backprot it we need to backport the fixes for the regression too
20:19:35 mriedem sure
20:19:48 mriedem or just tell the bank to upgrade
20:20:16 sean-k-mooney i mean if i could i would but...
20:20:44 sean-k-mooney that said depending on how invasive the other fixes are that might be answer
20:23:28 sean-k-mooney huh the last one was only fixed recently in the grand scheme fo things
20:41:44 efried sean-k-mooney: I can see whitelist/alias stuff in the nova.confZ
20:42:04 efried pci_passthrough_whitelist = [{"vendor_id":"8086","product_id":"1520"}]
20:42:05 efried pci_alias = {"name":"pci_network_card","vendor_id":"8086","product_id":"1520"}
20:42:23 efried Presumably that does no good without a flavor requesting something at that alias?
20:42:51 efried well, I mean, I guess it at least proves that the parts of the pci subsystem that parse those and generate the list of legal devices don't explode.
20:43:58 efried Do you have any idea where a guy could find the script that's running the show here?
20:47:00 sean-k-mooney correct
20:47:21 sean-k-mooney unless the flavor request the alaise it does not do anything
20:47:41 sean-k-mooney for the device to be useable for neutron the physnet would have to be set in the whitelist
20:48:21 sean-k-mooney they could be using a local.conf like i am. my guess would be it burried in a jenkins job somewhere
20:48:33 efried that's what I figured
20:48:47 efried I also really, really don't want to get too deeply involved here.
20:48:59 sean-k-mooney ha to late :P
20:49:04 efried I recognize it's a Learning Opportunity
20:49:25 sean-k-mooney well its being converted to zull v3 right
20:49:26 efried but if I go start debugging the CI, my life is over.
20:49:29 efried yes, afaik
20:49:51 sean-k-mooney so i woudl ignore how its currently running
20:50:02 sean-k-mooney and plan for how it will run
20:50:07 efried I sort of get the impression that there was someone competent doing all the work here, and then whoever that is left the company.
20:50:58 efried And those left behind are scrambling to figure out wtf is going on.
20:51:17 sean-k-mooney well yes but that happened liek 2 years ago :P
20:51:23 efried oh
20:51:34 sean-k-mooney actully the pci ci was always different
20:51:46 efried well, I know it would take *me* at least two years to figure out how this stuff works...
20:52:01 sean-k-mooney but the nfv ci was run by me an waldek but he left to joing redhat 2 years ago
20:52:48 sean-k-mooney the pci ci was run by a team of 1 person out of the PRC site but they had other respociblityes
20:53:05 efried different topic: "completing numa affinity polices for neutron sriov interfaces." <== on the PTG agenda. What's the status of this? Bullet says you were going to write a spec or something?
20:53:26 sean-k-mooney ya basically what i want to get out of that topic it the direct
20:53:36 sean-k-mooney i could just repopose the old spec
20:53:51 sean-k-mooney which say use a flavor/image property to specify the policy
20:54:02 sean-k-mooney or i could pass the policy via a neutron port
20:54:11 efried is there any in-person design work needed?
20:54:13 sean-k-mooney as this is numa affinty for neutron interfaces
20:54:43 sean-k-mooney well it will need a spec in either case the quest is nova or neutron
20:55:16 sean-k-mooney i also want to expand it to all neutron ports not just sriov to pick up the numa awrere vswitch work stephenfin did
20:55:27 efried Not understanding the subject, it sounds like you need to a) put things into a port def (neutron), and then b) process them into affinity thingies (nova)
20:56:07 sean-k-mooney yes but the question is where is the policy for the numa afinity expressed
20:56:17 sean-k-mooney per neutron port? or in the flavor/image
20:56:41 efried Even if it's on the port, would the neutron side require any actual code change, or is it just stuffing whatever into the already-garbage-in-garbage-out binding profile dict?
20:57:06 sean-k-mooney binding profile is admin only
20:57:24 sean-k-mooney so that is one of the questions use binding profile or add it as a new qos policy
20:57:45 efried Is this something to discuss in the nova/neutron xproj?
20:58:04 efried oh look
20:58:04 sean-k-mooney well that is why i addeed it there
20:58:08 efried it's already in there
20:58:11 sean-k-mooney is it also in the main nova one
20:58:15 efried so can I nix it from the main nova one?
20:58:15 sean-k-mooney if so kill the nova one
20:58:22 sean-k-mooney ya
20:58:24 efried cool
20:59:03 sean-k-mooney sorry that was added before the cross project etherpad i forgot to kill it when i move it over
21:00:01 efried yeah, that's cool, I'm just desperately trying to figure out how to schedule everything, and my first look is always going to be, "can we get rid of this??"
21:00:31 sean-k-mooney im debating if we should drop one of the other topic i have in the xproj doc
21:03:25 sean-k-mooney i have moved https://review.opendev.org/#/c/645173/ down in the xprojc etherpad by one as i think its something we shoudl discuss but im not sure ill have time to work on it. that said it might still be good to start the neutron work
21:13:33 efried jaypipes: Would you please put https://review.opendev.org/#/c/641994/ (AMD SEV reproposal) on your radar for review? There has been a nontrivial change of direction: namely making SEV contexts a quantifiable resource and therefore a resource class.
21:17:17 openstackgerrit Merged openstack/nova-specs master: Tools & docs for backlog & abandoned spec process https://review.opendev.org/648800
21:44:45 jaypipes efried: yessir.
21:44:51 efried thankyousir
21:45:49 jaypipes npsir
22:06:15 efried mriedem: https://review.opendev.org/#/c/645316/ is related to https://bugs.launchpad.net/nova/+bug/1817927 yah?
22:06:16 openstack Launchpad bug 1817927 in OpenStack Compute (nova) "device tagging support is not checked during move operations" [Undecided,New]

Earlier   Later