| *** digitalsimboja has joined #openstack-kuryr | 05:16 | |
| *** opendevreview has quit IRC | 05:26 | |
| *** ltomasbo has joined #openstack-kuryr | 06:15 | |
| *** digitalsimboja has quit IRC | 07:38 | |
| *** digitalsimboja has joined #openstack-kuryr | 08:37 | |
| *** digitalsimboja has quit IRC | 08:47 | |
| *** digitalsimboja has joined #openstack-kuryr | 09:12 | |
| *** digitalsimboja has joined #openstack-kuryr | 09:13 | |
| *** opendevreview has joined #openstack-kuryr | 09:41 | |
| opendevreview | Sunday Mgbogu proposed openstack/kuryr-kubernetes master: Update the Handlers and the Resources https://review.opendev.org/c/openstack/kuryr-kubernetes/+/795322 | 09:41 |
|---|---|---|
| digitalsimboja | Define how the solution would look like. This could include submitting a devref Patch Set to kuryr-kubernetes (though we don't need to wait on that to start the coding) | 09:48 |
| digitalsimboja | Hello! | 09:48 |
| digitalsimboja | @ltomasbo, @maysams: Please I need clarification for the above | 09:48 |
| digitalsimboja | What task is exactly required? A diagram or explanatory notes or algorithm? | 09:49 |
| digitalsimboja | Thanks | 09:49 |
| ltomasbo | digitalsimboja, is more about how are you planning to implemente the feature... Is it going to be a new handler, part of existing handler, part of a driver... how is it going to compare the OpenStack vs the k8s resources, what is going to do when there is a difference between them, etc | 09:51 |
| maysams | digitalsimboja: A devref is a documentation that you propose stating how the feature would be implemented | 09:51 |
| maysams | something like https://docs.openstack.org/kuryr-kubernetes/latest/devref/health_manager.html | 09:51 |
| digitalsimboja | Wow! Perfect | 09:52 |
| ltomasbo | yep, an another example is this one for the services: https://github.com/openstack/kuryr-kubernetes/blob/master/doc/source/devref/service_support.rst | 09:52 |
| digitalsimboja | Thanks @maysams | 09:52 |
| digitalsimboja | Got it! | 10:00 |
| digitalsimboja | I believe I have to do this for each OpenStack resource to be reconciled rather than putting the entire reconcilation architecture in one documenent | 10:01 |
| digitalsimboja | For instance, I could create loadbalancers_reconciliation_design.rst | 10:01 |
| digitalsimboja | correct? | 10:02 |
| digitalsimboja | Then port_reconciliation_design.rst | 10:02 |
| digitalsimboja | and so on... | 10:02 |
| ltomasbo | digitalsimboja, better if you target first one case (loadbalancer/svc one), and just define how it will look like for that one | 10:09 |
| digitalsimboja | sure! | 10:09 |
| ltomasbo | later we can check for the others (networks, ports, security groups) | 10:09 |
| ltomasbo | maysams, thoughts on that ^? | 10:10 |
| maysams | ltomasbo, digitalsimboja: I agree | 10:10 |
| digitalsimboja | I guess the best bet is to give it a separate handler of its own, for easy isolation and debugging? My thoughts... | 10:11 |
| ltomasbo | digitalsimboja, maybe... perhaps start defining the set of steps that needs to be done/triggered... and from there we can figure out where it would better fit (new handler, existing one, ...) | 10:16 |
| digitalsimboja | Fantastic! | 10:16 |
| *** digitalsimboja has quit IRC | 10:47 | |
| *** digitalsimboja has joined #openstack-kuryr | 10:57 | |
| opendevreview | Sunday Mgbogu proposed openstack/kuryr-kubernetes master: Update the Handlers and the Resources https://review.opendev.org/c/openstack/kuryr-kubernetes/+/795322 | 12:40 |
| *** digitalsimboja has quit IRC | 13:56 | |
| *** digitalsimboja has joined #openstack-kuryr | 15:27 | |
| *** digitalsimboja has quit IRC | 15:46 | |
| *** ltomasbo has quit IRC | 16:01 | |
| *** raildo has joined #openstack-kuryr | 17:18 | |
| *** digitalsimboja has joined #openstack-kuryr | 18:24 | |
| *** digitalsimboja has quit IRC | 18:52 | |
| *** digitalsimboja has joined #openstack-kuryr | 19:10 | |
| *** digitalsimboja has quit IRC | 19:38 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!