| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-03 | |||
| 18:31:49 | sean-k-mooney | jaypipes: do you think it would be appropriate to create a resouce provider per backend to track the allocated ports via the placement api or would it be better to track the seperatly in the neutron db or something like etcd in the neutron side | |
| 18:32:44 | jaypipes | sean-k-mooney: thinking.. | |
| 18:33:28 | jaypipes | sean-k-mooney: is the "backend" something that provides a particular resource class? and if so, what is that resource class? | |
| 18:34:27 | sean-k-mooney | jaypipes: the backend is a vswitch and it proveds a limited number of acclerated port and effectivly infinity software non acclerated ports | |
| 18:35:10 | jaypipes | sean-k-mooney: would there be multiple "backends" per compute node? | |
| 18:35:45 | sean-k-mooney | jaypipes: that would depend on how the rest of the intergration was done but gernarally no | |
| 18:35:59 | sean-k-mooney | you could support multiple but i dont see a reason too | |
| 18:36:12 | jaypipes | sean-k-mooney: then why not have the "accelerated port" resources belong to the compute node resource provider? | |
| 18:37:16 | sean-k-mooney | jaypipes: you could i just was wondering if the idea of neutron caliming a resouce via the placement api so it new what numerb to use when creating the vhost user socket path would be ok | |
| 18:37:50 | jaypipes | sean-k-mooney: no, I think it's best that the flow be this: | |
| 18:38:27 | jaypipes | a) MANO system calls neutron port create to create the port object | |
| 18:38:41 | jaypipes | b) MANO system calls nova boot --nic <port_uuid> ... | |
| 18:39:44 | jaypipes | c) Nova conductor constructs a request to scheduler/placement that asks for a provider which has 1 accelerated port available (possibly also with some NIC-related traits on the compute node resource provider record)( | |
| 18:40:28 | jaypipes | d) Nova conductor makes the "claim" for all the resources in the allocation | |
| 18:41:23 | jaypipes | e) nova-compute sees that the claim includes an allocation of an accelerated port and passes binding information to Neutron in the plug/bind operation. | |
| 18:41:27 | jaypipes | sean-k-mooney: ^^ | |
| 18:42:10 | sean-k-mooney | jaypipes: i get where your going with that. ya that makes sense more or less though it may mean i wont be able to reuse vnic types entirely the way i was hoping but it should still work | |
| 18:42:35 | jaypipes | sean-k-mooney: elaborate for me... how will you not be able to reuse vnic types? | |
| 18:43:37 | sean-k-mooney | jaypipes: well effectivly what resouce would be claimed may depend on the neutron backend so i was hoping to reuse the existing vnic types but that may or may not work | |
| 18:44:47 | jaypipes | sean-k-mooney: I guess I don't understand that... when is it decided which "backend" should be used? at neutron port create time, no? | |
| 18:45:25 | sean-k-mooney | jaypipes: the tenant is not directly aware of the ovs backend in use. | |
| 18:45:55 | sean-k-mooney | basically i would like to reuse vnic type direct for something that is like sriov but is slightly different | |
| 18:46:06 | sean-k-mooney | libvirt thinks its sriov | |
| 18:47:05 | jaypipes | sean-k-mooney: the request should be "get me an accelerated port with these characterstics", not "get my an accelerated port on this backend on this compute node", right? | |
| 18:47:09 | abhishek | melwitt: just a reminder, https://review.openstack.org/#/c/460305/ | |
| 18:48:23 | sean-k-mooney | jaypipes: yes the request would be boot me vm with this port of vnic type (normal,dirct or virtio-fowrader) | |
| 18:49:52 | sean-k-mooney | vnic type direct could be sriov passthrough of a vf or a hardware offloaded port such as the melonox hardware datapath for ovs. | |
| 18:49:55 | jaypipes | sean-k-mooney: k. for the direct vnic_type, I pretty much understand the various resource classes and traits involved. for normal, there's not really any traits/resource classes involved (since it's as you say "infinite resource capacity for software vnics"). It's the virtio-forwarder vnic types I'm just not familiar with... | |
| 18:50:52 | sean-k-mooney | virtio-forwarder is a new vnic introduced by netronome for there smartnics it is vhost user with hardware accleration | |
| 18:53:51 | melwitt | hah, I was just about to say "gee, gerrit has been really slow today" | |
| 18:54:38 | sean-k-mooney | jaypipes: anyway cool ill think about what you said because i didn want to also think about how to schdule base on the request also. thanks jay | |
| 18:55:09 | jaypipes | sean-k-mooney: not sure I was very helpful here :( | |
| 18:55:58 | sean-k-mooney | you were i was thinking of useing the workflow you were suggesting also but for the second backend that has this contratint but it should work for both. | |
| 18:56:11 | melwitt | abhishek: sorry, been busy working on a gate bug. about to comment now | |
| 18:56:27 | abhishek | melwitt: np | |
| 18:57:14 | armax | stevemar: ping | |
| 18:57:37 | stevemar | ameade: pong | |
| 18:57:58 | sean-k-mooney | the first backend was http://dpdk.org/browse/apps/spp/tree/ which NTT would like to enable next cycle. you can speciy the vhost-user socket path as it is hard coded to be /tmp/socket# where # is the id of the nfv forwarding instance. | |
| 19:00:38 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Remove check_detach https://review.openstack.org/446671 | |
| 19:01:06 | sean-k-mooney | since neutron has to calulate the vhost-user path as part of the port bind it needs to calulate/reserve an nfvincstace id for that interface as part of the port bind so that it can tell nova what path to use and os-vif what instance id to use to map to that socket | |
| 19:02:01 | openstackgerrit | Abhishek Sharma M proposed openstack/nova master: Catching OverQuota Exception https://review.openstack.org/460305 | |
| 19:02:09 | sean-k-mooney | jaypipes: anyway its time for dinner so ill catch you later. | |
| 19:09:07 | openstackgerrit | Rafael Folco proposed openstack/nova master: Delete all inventory has its own method DELETE https://review.openstack.org/460147 | |
| 20:02:49 | EmilienM | mriedem: is deploying nova-api in wsgi is now "stable" ? | |
| 20:05:59 | mriedem | EmilienM: the nova patches are all merged i think | |
| 20:06:13 | mriedem | yeah, | |
| 20:06:18 | mriedem | the devstack patch is passing but not merged yet https://review.openstack.org/#/c/457715/ | |
| 20:06:45 | mriedem | EmilienM: this was the docs patch from cdent https://review.openstack.org/#/c/461289/ | |
| 20:07:02 | dansmith | not running on devstack in the gate for a while means it's not "stable" yet IMHO | |
| 20:07:05 | mriedem | https://docs.openstack.org/developer/nova/wsgi.html | |
| 20:07:13 | dansmith | especially given the journal excitement from this morning | |
| 20:07:13 | mriedem | dansmith: i'd agree with that | |
| 20:07:17 | mriedem | and that | |
| 20:07:25 | mriedem | EmilienM: so kick the tires, but don't come screaming if there are issues :) | |
| 20:07:43 | dansmith | the service creation patch looks good, I hadn't seen that until today | |
| 20:07:48 | dansmith | but that's an important piece | |
| 20:11:30 | EmilienM | mriedem: ok good to know | |
| 20:11:45 | EmilienM | mriedem: i'll give a try where it's easily revertable (Puppet CI) and wait a bit in TripleO | |
| 20:12:47 | mriedem | jaypipes: i'm on slide 27 btw | |
| 20:12:48 | mriedem | nearly done | |
| 20:15:09 | jaypipes | mriedem: thx for reviewing. really helpful. | |
| 20:15:21 | jaypipes | mriedem: btw, added a graphic for the nested resource providers... | |
| 20:15:30 | jaypipes | mriedem: slide 30... | |
| 20:16:54 | mriedem | jaypipes: i'm hoping it's a picture of the sarlacc http://media.liveauctiongroup.net/i/20282/19782537_3.jpg?v=8D147F2BC4F6C50 | |
| 20:17:07 | dansmith | mriedem: it'd have to be a lego sarlacc | |
| 20:17:18 | jaypipes | right :) | |
| 20:17:26 | mriedem | oh right | |
| 20:17:27 | mriedem | oops | |
| 20:17:53 | dansmith | jay has like one slide per minute.. I hope none of the audience members have epilepsy | |
| 20:18:22 | jaypipes | dansmith: :) | |
| 20:19:21 | jaypipes | dansmith: especially since I added that strobe-light effect... | |
| 20:19:40 | mriedem | jay is a professional slidesmith | |
| 20:19:43 | dansmith | not sure the refresh rate on the projector will tolerate jay's slide-per-second rate | |
| 20:19:48 | mriedem | i'm sure it will be perfectly timed for effect | |
| 20:19:50 | jaypipes | lmao | |
| 20:20:09 | mriedem | julie will be working the fog machine | |
| 20:20:15 | dansmith | maybe he's trying to make his deck like a flipbook animation sort of thing? | |
| 20:20:29 | mriedem | "ladies and gentlemen, introducing, the beast from the southeast....JAY!" | |
| 20:20:42 | dansmith | a mic will descend from the ceiling and the lights will dim to a spotlight | |
| 20:20:46 | mriedem | right | |
| 20:21:06 | mriedem | i just like the idea of julie handling the effects | |
| 20:21:08 | dansmith | are you ready .... toooooo..... PLACE SOME RESOURCES SMARTLY???? | |
| 20:21:19 | melwitt | at first I was dreading these presentations. but now ... | |
| 20:21:27 | jaypipes | rofl | |
| 20:21:47 | jaypipes | DJ Jules on the effects board. | |
| 20:22:15 | dansmith | "Introducing Jay Pipes.. He hates inefficient schedulers and loves pug cuddles..." | |
| 20:23:16 | jaypipes | hehe | |
| 20:23:41 | jaypipes | dansmith: don't MAKE me add pug pics to my slides. you KNOW I will do that on a drop of a hat. | |
| 20:23:51 | dansmith | lego pugs? | |
| 20:23:56 | jaypipes | heh | |
| 20:25:48 | melwitt | the pug tucked into the blanket. that can be you sleeping soundly, using the new scheduler | |
| 20:26:33 | jaypipes | melwitt: this one? :) https://twitter.com/jaypipes/media | |
| 20:26:48 | sdague | mriedem / clarkb: I went through the list that mriedem posted in https://review.openstack.org/#/c/462231 - the only thing with an active hit touching syslog is coming in under the kernel tag (which will still be in that file) | |
| 20:26:49 | jaypipes | or rather, this... https://twitter.com/jaypipes/status/801233017993719808/photo/1 | |
| 20:28:03 | melwitt | jaypipes: that one is awesome too. I was thinking of the one where it's tucked into bed. I don't remember which pug it was | |
| 20:28:29 | openstackgerrit | Matthew Treinish proposed openstack/nova master: Fix typo in wsgi applications release note https://review.openstack.org/462283 | |
| 20:28:30 | mriedem | sdague: ok | |
| 20:28:34 | mriedem | dropped the -1 | |
| 20:28:41 | jaypipes | melwitt: ah. this one :) https://twitter.com/jaypipes/status/631102588319080448/photo/1 | |
| 20:28:46 | sdague | mriedem: it was a good thing to check | |