| *** janki has joined #openstack-kuryr | 03:52 | |
| *** snapiri has joined #openstack-kuryr | 05:19 | |
| *** ccamposr has joined #openstack-kuryr | 07:00 | |
| *** gcheresh_ has joined #openstack-kuryr | 07:27 | |
| *** maysams has joined #openstack-kuryr | 07:49 | |
| *** snapiri has quit IRC | 07:52 | |
| *** pcaruana has joined #openstack-kuryr | 08:25 | |
| *** janki has quit IRC | 09:00 | |
| *** janki has joined #openstack-kuryr | 09:00 | |
| *** celebdor has joined #openstack-kuryr | 09:15 | |
| *** jistr is now known as jistr|sick | 09:42 | |
| *** gkadam has joined #openstack-kuryr | 09:50 | |
| *** maysams has quit IRC | 09:59 | |
| *** aperevalov has joined #openstack-kuryr | 10:28 | |
| *** aperevalov has quit IRC | 10:29 | |
| *** maysams has joined #openstack-kuryr | 10:40 | |
| *** janki has quit IRC | 12:16 | |
| *** janki has joined #openstack-kuryr | 12:16 | |
| *** danil has joined #openstack-kuryr | 12:33 | |
| dulek | ltomasbo: We were discussing SR-IOV stuff with danil. | 12:44 |
|---|---|---|
| dulek | maysams: ^ | 12:45 |
| dulek | I'll just paste our talk… | 12:45 |
| dulek | <danil> as you remember, in last patches for sriov functionality neutron ports remains in down state. I have investigated this issue and I want to fix it. | 12:45 |
| dulek | <dulek> Sure, what's the question? | 12:45 |
| dulek | <danil> in case of nova instances , exactly nova runs through the instances, looks for pci devices that are attached for instances and then updates details for these ports neutron db | 12:45 |
| dulek | <danil> but nova doesn't handle PODs | 12:45 |
| dulek | <danil> so I think I should do next things: | 12:45 |
| dulek | <danil> kuryr-k8s contoller should watch for PODs state and make a update in neutron db for sriov-ports if POD is Running | 12:45 |
| dulek | <danil> also it will necessary do duplicate some details from nova config for kuryr-k8s controller too (I mean pci_whitelist etc.) | 12:45 |
| dulek | <dulek> How do you want Kuryr to update Neutron DB? | 12:45 |
| dulek | <dulek> It may not even have any access to MySQL IP. | 12:45 |
| dulek | <dulek> That would be a hard no from us, I think… | 12:45 |
| dulek | danil: So you'd like to have Neutron DB credentials in kuryr.conf and access it from Kuryr? | 12:46 |
| dulek | danil: Is Nova really doing that? | 12:46 |
| dulek | danil: I thought it was using RabbitMQ. | 12:46 |
| dulek | danil: I really don't want to depend from Nova's DB design. | 12:46 |
| danil | yes, RabbitMQ exactly. Not with Neutron DB credentials | 12:46 |
| dulek | To be honest I'd rather not depend from RabbitMQ RPC API either. | 12:47 |
| danil | hm, is there any way to update neutron ports ? We need to update binding:profile | 12:47 |
| dulek | danil: If Neutron REST API doesn't allow it, then probably no… | 12:49 |
| dulek | danil: I'm looking up code in Nova that does it. Are you able to point me to it? | 12:49 |
| danil | in /usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py | 12:51 |
| danil | def _update_port_binding_for_instance | 12:52 |
| dulek | danil: Hey, this is using REST API! | 12:53 |
| dulek | danil: In such case feel free to call Neutron however you like. :D | 12:53 |
| ltomasbo | dulek, danil: is this sriov for baremetal case, right? what about the nested one? | 12:53 |
| ltomasbo | danil, dulek: should it work in a completely different way, like attaching a new interface to the VM and then fully allocate it to a given container? | 12:54 |
| danil | I'm just about baremetal case | 12:54 |
| ltomasbo | danil, dulek: perhaps in that way nova already takes care of the port status... | 12:54 |
| danil | haven't tested nested one | 12:54 |
| dulek | ltomasbo: Yeah, it should probably work that way, but I don't think we ever figured that out. | 12:55 |
| danil | thanks a lot. I'll prepare a desision and push it for review | 12:56 |
| dulek | danil: Okay, so just for you to understand why I had those doubts - DB schema or even RabbitMQ's RCP aren't stable, public API's. | 12:57 |
| dulek | danil: REST API's on the other hand are considered solid, stable and any change in their behavior is considered a bug. | 12:57 |
| dulek | danil: That's why I'm concerned about using anything else than REST API to | 12:58 |
| dulek | contact any OpenStack service. | 12:58 |
| dulek | danil: Because we want to support older versions of OpenStack with a newer Kuryr - e.g. there's nothing that prevents using Stein Kuryr with Queens cloud. | 12:59 |
| dulek | And using some internal API would make it much harder to keep such compatibility. | 12:59 |
| danil | dulek: sure, I see. Thank sfor explanation | 13:00 |
| danil | dulek: I agree | 13:00 |
| dulek | :) | 13:00 |
| *** jistr|sick is now known as jistr|sick|mtg | 13:01 | |
| ltomasbo | dulek, danil: plus, if you run kuryr-kubernetes containerized on top of a nested env, you will not have access to the rabbitmq queues, right? | 13:08 |
| dulek | ltomasbo: Well, you could if they're exposed, depends on configuration. | 13:09 |
| dulek | ltomasbo: But on a well-designed cloud those would not be accessible to VM's. | 13:10 |
| ltomasbo | dulek, you could, but it is not what you are going to get most of the time I suppose | 13:10 |
| dulek | ltomasbo: Sure thing, consider a public cloud, for example. I'm 100% sure nobody is exposing RPC to VM's. ;) | 13:11 |
| *** rh-jelabarre has joined #openstack-kuryr | 13:17 | |
| openstackgerrit | Maysa de Macedo Souza proposed openstack/kuryr-kubernetes master: Fix LBaaS sg rules update on deployment scale https://review.openstack.org/637186 | 13:19 |
| dulek | ltomasbo: Had you succeeded with deploying Kuryr with networking-ovn? | 13:22 |
| ltomasbo | dulek, yes! | 13:45 |
| ltomasbo | dulek, do you want the local.conf? | 13:46 |
| dulek | ltomasbo: I already have it and I'm trying to install it. | 13:46 |
| dulek | ltomasbo: At the moment installations fail waiting for the K8s API LB. | 13:46 |
| dulek | ltomasbo: But I've noticed some weird errors in o-cw, related to Octavia templates formatting. | 13:47 |
| dulek | ltomasbo: So maybe it was that and I just need to update Octavia. | 13:47 |
| dulek | ltomasbo: So until I hit it again, no questions. ;) | 13:47 |
| ltomasbo | dulek, ok! | 13:50 |
| dulek | Neutron did not start' | 13:53 |
| dulek | Oh come on! | 13:53 |
| *** aperevalov has joined #openstack-kuryr | 13:54 | |
| *** aperevalov has quit IRC | 13:56 | |
| *** janki has quit IRC | 14:19 | |
| *** janki has joined #openstack-kuryr | 14:24 | |
| *** pcaruana has quit IRC | 14:31 | |
| maysams | #openstack-meeting-4 | 14:39 |
| openstackgerrit | Merged openstack/kuryr-kubernetes master: Add option to tag Neutron resources created by us https://review.openstack.org/636586 | 14:42 |
| *** jistr|sick|mtg is now known as jistr|sick | 15:02 | |
| danil | dulek, ltomasbo: how do you think, what is the best way to pass some host information (pci adress and pci_vendor for used virtual function) to master? | 15:09 |
| danil | we can use k8s_client to annotate k8s master | 15:09 |
| danil | I'd prefet to use pod annotations to pass this information. Is is possible? | 15:10 |
| dulek | danil: You want to pass them from kuryr-daemon? Yeah, annotations sound like an option. | 15:13 |
| danil | dulek, it doesn't matter. I just want to use a simplest way. I can collect information on minion's side and I just want to pass it to k8s master | 15:15 |
| danil | information related to used VFs | 15:15 |
| dulek | danil: I think minion only has access to K8s API, so annotations or CRD's. | 15:16 |
| *** danil_ has joined #openstack-kuryr | 15:21 | |
| danil_ | dulek, I left my laptop. Could you please repeat your answer? | 15:22 |
| danil_ | What is the best way do you think | 15:22 |
| *** pcaruana has joined #openstack-kuryr | 15:25 | |
| *** danil_ has quit IRC | 15:27 | |
| dulek | danil: Annotations or CRD, whatever works better for you. | 15:35 |
| dulek | ltomasbo: Okay, I'm hitting this again: TemplateSyntaxError: expected token 'end of statement block', got '.' | 15:40 |
| dulek | ltomasbo: Should I use some older version of Octavia or what? | 15:40 |
| ltomasbo | dulek, that is wehn deploying? | 15:41 |
| ltomasbo | dulek, I've never seen that one | 15:41 |
| dulek | ltomasbo: No, it's in o-cw. | 15:41 |
| ltomasbo | umm, ovn backend + ovn-octavia driver? | 15:41 |
| dulek | ltomasbo: maysams was pointing me to a specific patchset from https://review.openstack.org/#/c/608862/. Maybe I should just use the newest one? | 15:42 |
| *** janki has quit IRC | 15:42 | |
| ltomasbo | dulek, I installed this morning using a specific one | 15:42 |
| dulek | ltomasbo: And master Octavia? | 15:42 |
| maysams | dulek, maybe it's good to share your local.conf | 15:42 |
| ltomasbo | but of course with a few other components that were older... | 15:42 |
| ltomasbo | so, probably better to use the latest | 15:43 |
| ltomasbo | for everything | 15:43 |
| ltomasbo | or I can point you to the octavia commit I'm using (if that helps) | 15:43 |
| dulek | ltomasbo: And why are you using that patchset instead of newest one? | 15:44 |
| dulek | ltomasbo, maysams: http://pastebin.test.redhat.com/730757 | 15:45 |
| ltomasbo | dulek, because I know that one is working... after that some were broken | 15:46 |
| ltomasbo | and I haven't tried the latest one | 15:46 |
| ltomasbo | I know 16 and 30-something was working again | 15:46 |
| dulek | ltomasbo: Can you point to the Octavia version you use? | 15:50 |
| ltomasbo | dulek, sure, latest commit I have is: commit 816abab6a470b33a9441f7df8ec135b3e383ecbc | 15:50 |
| ltomasbo | commit 816abab6a470b33a9441f7df8ec135b3e383ecbc | 15:50 |
| ltomasbo | from Wed Dec 12 | 15:51 |
| ltomasbo | Merge "Add certificate configs to config reference" | 15:51 |
| dulek | ltomasbo: Oh man, I'm sure this may help. :D | 15:51 |
| ltomasbo | fingers crossed! | 15:51 |
| dulek | ltomasbo: Although it shouldn't matter really, because amphorae is used for k8s API LB. | 15:52 |
| dulek | But still, it must be something. | 15:52 |
| openstackgerrit | Maysa de Macedo Souza proposed openstack/kuryr-kubernetes master: Fix LBaaS sg rules update on deployment scale https://review.openstack.org/637186 | 15:57 |
| *** gcheresh_ has quit IRC | 16:00 | |
| ltomasbo | dulek, I didn't mean that was the commit to blame... just that it is working if you go all the way to that commit | 16:07 |
| ltomasbo | dulek, anything from that one and master could be the one to blame | 16:07 |
| dulek | ltomasbo: Oh yes, yes. | 16:08 |
| dulek | ltomasbo: I was just surprised you're using a December's commit. | 16:08 |
| ltomasbo | yep! I'm just updating kuryr on that server... | 16:08 |
| *** maysams has quit IRC | 16:30 | |
| dulek | ltomasbo: Progress! | 16:45 |
| dulek | ltomasbo: Nope, I've said that too soon. :( | 16:45 |
| ltomasbo | :) | 16:47 |
| dulek | That was outdated jinja overwritten by yum. | 17:22 |
| dulek | Okay, we have at least one bug with OVN… | 18:07 |
| dulek | ltomasbo: Oh my, but services are working flawlessly. | 18:13 |
| *** ccamposr has quit IRC | 18:21 | |
| *** ccamposr has joined #openstack-kuryr | 18:21 | |
| *** ccamposr has quit IRC | 18:22 | |
| *** mrostecki has quit IRC | 18:54 | |
| *** pcaruana has quit IRC | 18:56 | |
| *** openstackgerrit has quit IRC | 19:23 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!