| *** ivc_ has quit IRC | 00:07 | |
| *** ivc_ has joined #openstack-kuryr | 00:28 | |
| *** ivc_ has quit IRC | 00:29 | |
| *** ivc_ has joined #openstack-kuryr | 00:31 | |
| *** ivc_ has quit IRC | 00:33 | |
| *** ivc_ has joined #openstack-kuryr | 00:41 | |
| *** ivc_ has quit IRC | 00:41 | |
| *** banix has quit IRC | 00:52 | |
| *** yamamoto has joined #openstack-kuryr | 00:52 | |
| openstackgerrit | Liping Mao proposed openstack/kuryr-libnetwork: Fix tox -e cover in kuryr-libnetwork https://review.openstack.org/379556 | 00:57 |
|---|---|---|
| *** lezbar has quit IRC | 00:58 | |
| *** lezbar has joined #openstack-kuryr | 00:59 | |
| *** tonanhngo has quit IRC | 01:02 | |
| *** tonanhngo has joined #openstack-kuryr | 01:15 | |
| *** tonanhngo has quit IRC | 01:19 | |
| *** akanksha_ has quit IRC | 01:27 | |
| *** yedongcan1 has joined #openstack-kuryr | 01:43 | |
| *** salv-orlando has joined #openstack-kuryr | 01:44 | |
| *** salv-orl_ has quit IRC | 01:46 | |
| *** lezbar has quit IRC | 01:55 | |
| *** lezbar has joined #openstack-kuryr | 01:55 | |
| *** lezbar has quit IRC | 02:11 | |
| *** lezbar has joined #openstack-kuryr | 02:11 | |
| *** banix has joined #openstack-kuryr | 02:19 | |
| *** banix has quit IRC | 02:20 | |
| *** lezbar has quit IRC | 02:28 | |
| *** lezbar has joined #openstack-kuryr | 02:28 | |
| *** yuanying has quit IRC | 02:47 | |
| *** yuanying has joined #openstack-kuryr | 02:55 | |
| openstackgerrit | Merged openstack/kuryr: Remove kuryr-libnetwork constants from kuryr-lib https://review.openstack.org/375386 | 03:01 |
| *** huikang has quit IRC | 03:04 | |
| *** huikang_ has joined #openstack-kuryr | 03:06 | |
| *** huikang_ has quit IRC | 03:24 | |
| *** yuanying has quit IRC | 03:38 | |
| *** yuanying has joined #openstack-kuryr | 03:49 | |
| *** lezbar has quit IRC | 04:20 | |
| *** lezbar has joined #openstack-kuryr | 04:20 | |
| *** portdirect_ has joined #openstack-kuryr | 04:21 | |
| *** portdirect has quit IRC | 04:21 | |
| *** portdirect_ is now known as portdirect | 04:22 | |
| *** lezbar has quit IRC | 04:37 | |
| *** lezbar has joined #openstack-kuryr | 04:37 | |
| *** yedongcan1 has quit IRC | 04:42 | |
| *** sdake_ has joined #openstack-kuryr | 04:42 | |
| *** sdake has quit IRC | 04:46 | |
| *** sdake_ has quit IRC | 05:19 | |
| *** lezbar has quit IRC | 05:52 | |
| *** lezbar has joined #openstack-kuryr | 05:52 | |
| *** salv-orlando has quit IRC | 05:56 | |
| *** sdake has joined #openstack-kuryr | 05:59 | |
| *** janki has joined #openstack-kuryr | 06:01 | |
| openstackgerrit | vikas choudhary proposed openstack/kuryr-libnetwork: Code restructuring: neutron client as rest driver from Kuryr lib https://review.openstack.org/342614 | 06:02 |
| openstackgerrit | vikas choudhary proposed openstack/kuryr: Add neutron client generic rest driver https://review.openstack.org/342624 | 06:03 |
| vikasc | apuimedo, i request you to please review https://review.openstack.org/342624 . I have made changes as per your suggestion. Please let me know what else can i do to get it merged. | 06:04 |
| *** limao has joined #openstack-kuryr | 06:06 | |
| *** ivc_ has joined #openstack-kuryr | 06:16 | |
| *** salv-orlando has joined #openstack-kuryr | 06:20 | |
| *** sdake has quit IRC | 06:35 | |
| *** sdake has joined #openstack-kuryr | 06:35 | |
| *** yedongcan has joined #openstack-kuryr | 06:36 | |
| *** limao has quit IRC | 06:43 | |
| *** limao has joined #openstack-kuryr | 06:47 | |
| *** limao has quit IRC | 06:50 | |
| *** limao has joined #openstack-kuryr | 06:53 | |
| *** limao has quit IRC | 06:57 | |
| apuimedo | vikasc: thanks. I'll start checking it now | 07:09 |
| vikasc | thanks apuimedo | 07:09 |
| apuimedo | vikasc: checked | 07:12 |
| apuimedo | isn't it missing the kuryr/lib/neutron/rest.py ? | 07:13 |
| vikasc | apuimedo, yeah.. i missed to checkin :) | 07:14 |
| apuimedo | no problem | 07:14 |
| vikasc | apuimedo, thanks .. i will update now | 07:14 |
| apuimedo | vikasc: I was thinking of the name of the drivers | 07:14 |
| apuimedo | what about direct and rpc | 07:14 |
| apuimedo | instead of rest and rpc | 07:14 |
| apuimedo | because rest also sounds RPCish | 07:15 |
| apuimedo | while in our case it just means that you are using the code directly in the same process via kuryr.lib | 07:15 |
| vikasc | apuimedo, i thought of putting that in neutron_opts but it looked to me that its a kuryr configuration.. anyways will do as you suggested | 07:15 |
| apuimedo | vikasc: you've got a point | 07:16 |
| apuimedo | but since we also have stuff like the pool names, which are really kuryr settings for neutron | 07:16 |
| apuimedo | I thought it also applies | 07:16 |
| vikasc | apuimedo, i am thinking about a better name than direct | 07:17 |
| apuimedo | vikasc: good! | 07:17 |
| apuimedo | local? | 07:17 |
| vikasc | apuimedo, exactly this i was thinking | 07:18 |
| apuimedo | let's do this then :-) | 07:18 |
| apuimedo | thanks | 07:18 |
| vikasc | thanks | 07:18 |
| *** lezbar has quit IRC | 07:26 | |
| *** lezbar has joined #openstack-kuryr | 07:27 | |
| *** pmannidi is now known as pmannidi|Gone | 07:28 | |
| *** pmannidi|Gone has quit IRC | 07:28 | |
| *** limao has joined #openstack-kuryr | 07:28 | |
| openstackgerrit | vikas choudhary proposed openstack/kuryr: Add neutron client generic rest driver https://review.openstack.org/342624 | 07:30 |
| vikasc | apuimedo, please take a look..addressed your comments. https://review.openstack.org/342624 | 07:32 |
| * apuimedo going in | 07:32 | |
| vikasc | thanks | 07:32 |
| apuimedo | https://review.openstack.org/#/c/342624/20/kuryr/lib/neutron_driver/neutron_local.py | 07:33 |
| apuimedo | vikasc: a bit too much neutron on the name, don't you think? :P | 07:33 |
| vikasc | apuimedo, u mean local.py is enough? | 07:33 |
| *** sdake_ has joined #openstack-kuryr | 07:34 | |
| vikasc | apuimedo, rather neutron_local.py | 07:34 |
| apuimedo | kuryr/lib/neutron_driver/local.py or kuryr/lib/neutron/driver/local.py should be enough | 07:34 |
| vikasc | cool | 07:34 |
| apuimedo | limao: your coverage patch to infra got merged :-) Thanks | 07:34 |
| vikasc | apuimedo, should i wait for some more quick comments or should update it | 07:35 |
| apuimedo | let me check | 07:35 |
| vikasc | apuimedo, ok | 07:35 |
| *** sdake has quit IRC | 07:37 | |
| *** coolias has joined #openstack-kuryr | 07:37 | |
| apuimedo | vikasc: is the utils.get_neutron_client already in openstack/kuryr? | 07:37 |
| * vikasc checking | 07:38 | |
| apuimedo | it seems to be there | 07:39 |
| vikasc | apuimedo, yes | 07:39 |
| apuimedo | :-) | 07:39 |
| vikasc | :) | 07:39 |
| apuimedo | ok, so make that path change | 07:39 |
| vikasc | apuimedo, neutron_local to local ? | 07:40 |
| apuimedo | yeah | 07:40 |
| vikasc | cool | 07:40 |
| apuimedo | I don't mean to change it now, we are going for this patch. Thinking about the API the driver exposes, I was thinking if we could not make it higher level with less calls | 07:41 |
| apuimedo | like, create_network, delete_network, create_port, delete_port | 07:41 |
| apuimedo | and hide all the neutron calls inside those methods in the driver | 07:42 |
| apuimedo | vikasc: ivc_: what do you think? (it would be a later refactor, of course | 07:42 |
| apuimedo | basically the driver interface would be the minimal high level API that we need from kuryr-libnetwork and kuryr-kubernetes | 07:43 |
| *** salv-orl_ has joined #openstack-kuryr | 07:44 | |
| *** lezbar has quit IRC | 07:46 | |
| *** lezbar has joined #openstack-kuryr | 07:46 | |
| *** salv-orlando has quit IRC | 07:46 | |
| openstackgerrit | vikas choudhary proposed openstack/kuryr: Add neutron client generic rest driver https://review.openstack.org/342624 | 07:47 |
| vikasc | apuimedo, sorry i could not get your point | 07:47 |
| vikasc | apuimedo, are you suggesting that we should not have apis like network_create, port_create which driver currently exposes? | 07:48 |
| apuimedo | my point is that instead of having a driver interface that is so fine grained with put_tag, etc, we would group those by kuryr functionality | 07:48 |
| *** coolias has quit IRC | 07:49 | |
| ivc_ | apuimedo what patch are we discussing? https://review.openstack.org/#/c/342624/20/kuryr/lib/neutron_driver/neutron_local.py ? | 07:49 |
| apuimedo | and have a network_create, that created the network with neutron and also took care of the tagging, for example | 07:49 |
| apuimedo | ivc_: that's the one | 07:49 |
| apuimedo | I mean, we pretty much only do a few operations that we break down into smaller, finer grained neutron actions | 07:50 |
| apuimedo | we create and delete networks | 07:50 |
| apuimedo | we create and delete pots | 07:50 |
| ivc_ | i dont quite understand why are we proxying neutron client? | 07:50 |
| vikasc | apuimedo, then we would have to do refactoring in libnetwork driver | 07:50 |
| apuimedo | *ports | 07:50 |
| vikasc | apuimedo, in controllers.py | 07:51 |
| apuimedo | vikasc: yes, I know, I'm talking about a refactoring. kuryr-libnetwork and kuryr-kubernetes would be simplified | 07:51 |
| apuimedo | ivc_: this is just a driver interface | 07:51 |
| vikasc | apuimedo, agree, there we can bundle fine grain api calls into a logical api | 07:51 |
| vikasc | apuimedo, got yr point | 07:51 |
| apuimedo | so that if somebody want to run instead of directly to neutron from the local kuryr-kubernetes or kuryr-libnetwork | 07:52 |
| apuimedo | you can configure to use a rpc/ovn/whatnot driver | 07:52 |
| apuimedo | just like we have an ipvlan/macvlan/veth driver for the binding | 07:52 |
| apuimedo | ivc_: ^^ | 07:53 |
| vikasc | apuimedo, makes sense | 07:53 |
| *** lezbar has quit IRC | 07:54 | |
| ivc_ | you mean ovn like standalone ovn? does it not have a bit different api's than neutron? | 07:54 |
| apuimedo | ivc_: sure it does, the driver would have to adapt it | 07:54 |
| *** lezbar has joined #openstack-kuryr | 07:55 | |
| apuimedo | we'd not be using straight lower level neutron commands like there are now in the patch | 07:55 |
| vikasc | ivc_, ovn apis should be totally different i think | 07:55 |
| ivc_ | than it would make sense when we have more than one driver. but now its a proxy | 07:55 |
| ivc_ | and when we get a second driver api would likely change | 07:55 |
| ivc_ | i'd suggest to only introduce that kind of driver api when we have multiple driver implementations | 07:56 |
| vikasc | apuimedo, but i am not able to see us very soon there | 07:57 |
| apuimedo | vikasc: ivc_: we need two drivers now, a local one and an rpc one | 07:57 |
| apuimedo | the question is whether we just have the rpc one be a proxy | 07:58 |
| ivc_ | what rpc? | 07:58 |
| ivc_ | for kuryr-libnetwork? | 07:58 |
| apuimedo | ivc_: this is for deployments where you can't have direct access to neutron from the instance | 07:58 |
| apuimedo | or can't have the neutron credentials there, or whatever | 07:59 |
| ivc_ | what would be an rpc server in that case? | 07:59 |
| apuimedo | ivc_: well, it would probably be some grpc/rest between kuryr components | 07:59 |
| vikasc | ivc_, kuryr-lib will have an rpc_server as well | 07:59 |
| apuimedo | with certs | 07:59 |
| ivc_ | dont we have certs-based auth in keystone? | 08:00 |
| ivc_ | if you cant access neutron from instance you still need to access rpc server | 08:00 |
| ivc_ | and i'm not sure if i understand how rpc server is different from neutron | 08:00 |
| vikasc | ivc_, kuryr driver running on docker host will become rpc_client and passing neutron service requests to a rpc_server running on master node | 08:01 |
| apuimedo | here's the point, if we have an rpc api with the low level neutron commands, the rpc server is no different than neutron | 08:02 |
| ivc_ | ^ | 08:02 |
| apuimedo | if it only has higher level commands, then it is different | 08:02 |
| vikasc | ivc_, rpc_server will invoke rest apis and query neutron server and passes back results to rpc client | 08:02 |
| apuimedo | since the potential for wreaking havoc is reduced | 08:02 |
| vikasc | apuimedo, ivc_ can you please review https://review.openstack.org/342624 | 08:03 |
| vikasc | apuimedo, its been more than 1 and half month that i have been keeping these patches active :) | 08:04 |
| *** lezbar has quit IRC | 08:05 | |
| ivc_ | i'm strongly biased against proxying neutron client either locally or through rpc unless it has higher-level api then neutron client | 08:06 |
| *** lezbar has joined #openstack-kuryr | 08:06 | |
| ivc_ | now it is a proxy that provides access to a subset of neutron client | 08:06 |
| ivc_ | and lacks lbaas :) | 08:06 |
| apuimedo | ivc_: agreed. So you are on board with making a higher level api, then | 08:07 |
| ivc_ | yes but not at this moment | 08:07 |
| ivc_ | to define good high level api we need to have multiple back-ends in mind | 08:08 |
| ivc_ | like neutron and ovn | 08:08 |
| ivc_ | otherwise we'll make an api for neutron and then will have to redesign it to adapt to ovn | 08:08 |
| ivc_ | apuimedo btw, regarding port OVO. i think we can use os-vif OVO | 08:09 |
| apuimedo | ivc_: well, I planned to take a look at salv-orl_ and gshetty's kubernetes implementation to try to see what the higher level API could look like | 08:09 |
| apuimedo | ivc_: I'll check os-vif OVO :-) | 08:10 |
| ivc_ | https://github.com/openstack/os-vif/tree/master/os_vif/objects | 08:10 |
| ivc_ | we'll start with just ovo and update your binding patch with ovo instead of neutron_port/neutron_subnet | 08:11 |
| ivc_ | and later we can start using os-vif itself | 08:11 |
| apuimedo | ivc_: those look good to me | 08:12 |
| vikasc | apuimedo, ivc_ should we discuss again on rpc_server requirement | 08:12 |
| apuimedo | vikasc: absolutely | 08:12 |
| ivc_ | and back to the api. my suggestion is to avoid defining api before we have actual multiple driver implementation | 08:12 |
| ivc_ | i.e. api should be a result of merging/refactoring 2 driver implementations | 08:13 |
| ivc_ | but thats just imho :) | 08:13 |
| vikasc | ivc_, we initially decided that we need an rpc_server to talk to neutron server and so I started working on rpc_client and then suggestions came in to introduce driver abstraction | 08:14 |
| *** coolias has joined #openstack-kuryr | 08:15 | |
| ivc_ | vikasc i understand that. but my point is that i don't see how rpc_server adds value if it just a proxy to neutron | 08:15 |
| vikasc | apuimedo, Can better answer this :) | 08:16 |
| apuimedo | it does not unless it has a higher level API so it limits what the instance kuryr agents can ask of neutron | 08:16 |
| ivc_ | do we really need to limit agents? why can't we have higher-level api as part of agent? | 08:17 |
| ivc_ | it also adds to latency | 08:18 |
| ivc_ | (i just want to understand) :) | 08:18 |
| apuimedo | ivc_: the agents should be able to work with direct communication to neutron and with an RPC backend | 08:18 |
| apuimedo | it's up to the deployer to do the trade off between latency and security | 08:18 |
| vikasc | security was the main concern for introducing rpc_server | 08:19 |
| vikasc | to leave docker hosts with minimum information | 08:19 |
| ivc_ | again, what rpc backend adds over the direct communication? | 08:19 |
| apuimedo | let's say you have the kuryr-kubernetes watching daemon and the Neutron talking CNI drivers on Nova instances | 08:19 |
| apuimedo | it is perfectly legitimate to say, I make neutron controller routable from the overlay | 08:20 |
| *** lmdaly has joined #openstack-kuryr | 08:20 | |
| apuimedo | and they go directly to it | 08:20 |
| apuimedo | another user can say, I want to have a small rpc server in a namespace with a higher level API that the kuryr-kubernetes components talk to | 08:20 |
| ivc_ | cant we just run nginx and point it to neutron? | 08:21 |
| apuimedo | ivc_: that would not offer any benefit, proxying for the sake of proxying | 08:22 |
| apuimedo | we're trying to come up with a way to serve the deployment case of not having to store credentials in the instances either | 08:23 |
| ivc_ | ok then we agree on "proxying for the sake of proxying" | 08:23 |
| apuimedo | ivc_: there was never disagreement on that | 08:23 |
| apuimedo | :-) | 08:23 |
| *** sdake_ has quit IRC | 08:23 | |
| ivc_ | so the real reason is to deal with credentials? | 08:24 |
| apuimedo | it's the biggest part of it | 08:24 |
| vikasc | ivc_, i too think yes | 08:24 |
| apuimedo | credentials and unrestricted access | 08:24 |
| ivc_ | because i don't like the idea of having 2 different apis for agents (1 for direct neutron and the other for 'higher level api') | 08:25 |
| apuimedo | agents would know only the simplified api | 08:25 |
| vikasc | ivc_, api would be same.. when we do higher level.. it will be for neutron as well. | 08:25 |
| apuimedo | the direct driver would do the one breaking it down into neutron commands | 08:25 |
| ivc_ | yet we'll have to support multiple drivers (1 for rpc_server and 1 for direct) + rpc_server | 08:26 |
| apuimedo | there will probably be: | 08:26 |
| vikasc | yes..agents will see common api | 08:26 |
| apuimedo | * direct: this one is as it is now | 08:27 |
| apuimedo | * rpc: same API but internally it does grpc or rest or something to fullfill its duty | 08:27 |
| ivc_ | it adds complexity | 08:27 |
| apuimedo | ivc_: no question about that | 08:28 |
| apuimedo | it does add complexity in the rpc server and in the rpc client | 08:28 |
| apuimedo | the direct one should not have added complexity | 08:28 |
| ivc_ | can we instead make rpc_server compatible with neutron-client? | 08:28 |
| apuimedo | ivc_: what do you mean with compatible? | 08:29 |
| ivc_ | and proxy to neutron with added auth? | 08:29 |
| ivc_ | i mean agents will use native neutron-client | 08:29 |
| apuimedo | you mean we take the same calls as neutron | 08:29 |
| ivc_ | without auth | 08:29 |
| apuimedo | but point to the proxy | 08:29 |
| apuimedo | I believe that is what vikasc was doing | 08:29 |
| ivc_ | vikasc is wrapping neutron-client for agents i think | 08:30 |
| ivc_ | i want agents to not care about drivers | 08:30 |
| apuimedo | ah, I get the difference in what you mean | 08:30 |
| ivc_ | and just use neutron-client | 08:30 |
| apuimedo | what you mean is that, in kuryr-libnetwork or kuryr-kubernetes in the [neutron] section | 08:30 |
| ivc_ | but with neutron-url pointing at our rpc_server proxy | 08:30 |
| apuimedo | we just point to another endpoint | 08:31 |
| ivc_ | yup | 08:31 |
| ivc_ | that way we'll keep agents simple | 08:31 |
| ivc_ | wont have to worry about adding stuff like lbaas/whatever support to the driver | 08:31 |
| apuimedo | ivc_: we'll end up with ifs and elses for if it is nested with ipvlan/macvlan and such | 08:32 |
| ivc_ | why? | 08:32 |
| apuimedo | if it is nested with ipvlan, for example, it will have to update neutron ports with allowed address pairs | 08:32 |
| apuimedo | if it is with vlan trunking it will need to call trunk and subport apis | 08:33 |
| apuimedo | my plan was to have | 08:33 |
| ivc_ | yes ofc | 08:34 |
| apuimedo | drivers for functionality | 08:34 |
| apuimedo | ivc_: I think that the transport could be hidden as you propose, though | 08:34 |
| apuimedo | IIRC now we get the neutron endpoint from keystone, we don't configure it anymore for Neutron access, we'd have to add that | 08:35 |
| apuimedo | or register a kuryr endpoint in keystone | 08:35 |
| apuimedo | nope, not that | 08:35 |
| apuimedo | no keystone access, so that if [neutron] only has the url, we go directly to it | 08:36 |
| ivc_ | i'm not against drivers for ipvlan/macvlan for neutron-client. quite contrary that was my plan | 08:36 |
| ivc_ | but i'm against moving that higher-level api into rpc_server | 08:36 |
| ivc_ | as rpc_server should be optional and agents should be able to talk to neutron directly | 08:36 |
| ivc_ | and i'm against having 2 drivers for say ipvlan - 1 for direct neutron and 1 for rpcserver | 08:36 |
| apuimedo | direct access was never out of the question | 08:36 |
| apuimedo | but I see the merits of not having to make the rpc layer | 08:37 |
| apuimedo | (the client part) | 08:37 |
| apuimedo | and instead have only the server part with whitelisted commands (it still sounds like quite a bit of work) | 08:38 |
| ivc_ | and i think there's some stuff built-in in neutron for whitelisting | 08:38 |
| ivc_ | i mean we can run neutron api server itself with some specific policy.json | 08:42 |
| vikasc | apuimedo, ivc_ IIUC you guys are suggesting that user will configure neutron endpoint url on nodes to actual neutron server or rpc_server depending on if direct access is intended or through rpc? | 08:42 |
| ivc_ | neutron server is the same rpc server | 08:42 |
| apuimedo | vikasc: yes | 08:42 |
| apuimedo | vikasc: ivc_: I'll take a stab at doing the trunk/ipvlan/macvlan driver draft patch part | 08:43 |
| apuimedo | for the rpc/neutron part | 08:43 |
| apuimedo | it will be configuration of url as vikasc summarized ^^ | 08:43 |
| apuimedo | but I will not tackle that now | 08:43 |
| apuimedo | vikasc: what do you think about doing it like that so we can drop having an rpc server? | 08:44 |
| apuimedo | pity that ton and hongbin are not around | 08:44 |
| vikasc | apuimedo, i think complete rest/rpc work should be dropped | 08:45 |
| ivc_ | apuimedo what do you think if we use neutron itself as what you suggested as 'rpc_server' but that instance would be dedicated to kuryr and have some specific policy.json? | 08:45 |
| apuimedo | ivc_: I was thinking a moment ago about using a neutron server instance per tenant | 08:46 |
| vikasc | ivc_, apuimedo are we trying to cover security part through policy.json now which we were trying to do by not storing credentials on nodes? | 08:46 |
| apuimedo | but I've never tried to run neutron in that way | 08:46 |
| apuimedo | either policy or forcing neutron of only accepting requests from specific tenants (I suppose that can be done with policy too) | 08:47 |
| ivc_ | > cover security part | 08:47 |
| ivc_ | rather 'insecurity' :) | 08:48 |
| vikasc | :) | 08:48 |
| ivc_ | tbh i doubt that 'not storing credentials' is a good idea at all | 08:49 |
| vikasc | apuimedo, i think we dont need this rest/rpc mess then :D | 08:49 |
| apuimedo | ivc_: it's not 'not storing credentials' it's more like just having certs for workers like k8s does | 08:50 |
| apuimedo | vikasc: agreed | 08:50 |
| apuimedo | sorry | 08:50 |
| vikasc | apuimedo, aahh.. lost of time waste :'( | 08:50 |
| vikasc | *lots | 08:50 |
| ivc_ | apuimedo but keystone allows cert-based auth doesn't it? | 08:50 |
| apuimedo | vikasc: I don't think so | 08:50 |
| ivc_ | vikasc i'm sorry :'( | 08:51 |
| apuimedo | ivc_: I believe it does | 08:51 |
| apuimedo | vikasc: it would be a time waste if it did not lead us to a better solution in the end | 08:51 |
| apuimedo | things we try and don't work are good too | 08:51 |
| vikasc | apuimedo, agree | 08:51 |
| apuimedo | ivc_: there is some concept now of limited keystone tokens as well | 08:52 |
| apuimedo | but I haven't checked if they made it to newton | 08:52 |
| apuimedo | I'll try to find some keystone person to ask | 08:52 |
| apuimedo | back when we talked in Austin it wasn't ready | 08:53 |
| ivc_ | apuimedo btw would you take a look at https://review.openstack.org/#/c/376043/1 ? | 08:54 |
| apuimedo | ivc_: I will, give me 20 minutes and I'm on it | 08:54 |
| ivc_ | the usage example is in https://review.openstack.org/#/c/376046/1/kuryr_kubernetes/controller/service.py | 08:55 |
| ivc_ | i still need to add tests thus its WIP (and also relies on other WIPs that also lack tests) but the general concept would be the same | 08:56 |
| *** salv-orl_ has quit IRC | 09:05 | |
| *** limao has quit IRC | 09:19 | |
| *** limao has joined #openstack-kuryr | 09:21 | |
| *** salv-orlando has joined #openstack-kuryr | 09:31 | |
| *** yedongcan1 has joined #openstack-kuryr | 09:45 | |
| *** yedongcan has quit IRC | 09:47 | |
| *** limao has quit IRC | 10:11 | |
| *** yamamoto has quit IRC | 10:19 | |
| *** coolias has quit IRC | 10:23 | |
| *** coolias has joined #openstack-kuryr | 10:24 | |
| *** yedongcan1 has quit IRC | 10:25 | |
| *** salv-orl_ has joined #openstack-kuryr | 10:41 | |
| *** salv-orlando has quit IRC | 10:41 | |
| *** coolias has quit IRC | 10:55 | |
| *** janki has quit IRC | 11:23 | |
| *** lezbar has quit IRC | 11:33 | |
| *** lezbar has joined #openstack-kuryr | 11:34 | |
| *** yamamoto has joined #openstack-kuryr | 11:34 | |
| *** yamamoto_ has joined #openstack-kuryr | 11:36 | |
| *** yamamoto has quit IRC | 11:40 | |
| *** lezbar has quit IRC | 11:51 | |
| *** lezbar has joined #openstack-kuryr | 11:52 | |
| *** lmdaly has quit IRC | 11:53 | |
| *** yamamoto_ has quit IRC | 12:26 | |
| *** lezbar has quit IRC | 12:29 | |
| *** lezbar has joined #openstack-kuryr | 12:30 | |
| *** lmdaly has joined #openstack-kuryr | 12:32 | |
| *** yamamoto has joined #openstack-kuryr | 12:56 | |
| *** yamamoto has quit IRC | 13:01 | |
| *** yamamoto has joined #openstack-kuryr | 13:03 | |
| *** yamamoto has quit IRC | 13:03 | |
| *** sdake has joined #openstack-kuryr | 13:04 | |
| *** lezbar has quit IRC | 13:09 | |
| *** lezbar has joined #openstack-kuryr | 13:09 | |
| *** yamamoto has joined #openstack-kuryr | 13:10 | |
| *** yamamoto has quit IRC | 13:15 | |
| *** yamamoto has joined #openstack-kuryr | 13:22 | |
| *** yamamoto has quit IRC | 13:24 | |
| *** portdirect has quit IRC | 13:38 | |
| *** huikang has joined #openstack-kuryr | 13:42 | |
| *** salv-orlando has joined #openstack-kuryr | 13:43 | |
| *** salv-orl_ has quit IRC | 13:46 | |
| *** ivc_ has quit IRC | 13:48 | |
| *** ivc_ has joined #openstack-kuryr | 13:56 | |
| *** limao has joined #openstack-kuryr | 13:59 | |
| *** limao_ has joined #openstack-kuryr | 14:01 | |
| *** limao has quit IRC | 14:04 | |
| *** limao has joined #openstack-kuryr | 14:11 | |
| *** limao__ has joined #openstack-kuryr | 14:12 | |
| *** huikang has quit IRC | 14:12 | |
| *** huikang has joined #openstack-kuryr | 14:13 | |
| *** limao_ has quit IRC | 14:14 | |
| *** huikang has quit IRC | 14:16 | |
| *** limao has quit IRC | 14:16 | |
| *** huikang has joined #openstack-kuryr | 14:16 | |
| *** limao has joined #openstack-kuryr | 14:22 | |
| *** limao__ has quit IRC | 14:23 | |
| *** yamamoto has joined #openstack-kuryr | 14:29 | |
| *** limao has quit IRC | 14:34 | |
| *** tonanhngo has joined #openstack-kuryr | 14:34 | |
| *** limao has joined #openstack-kuryr | 14:34 | |
| *** tonanhngo has quit IRC | 14:34 | |
| *** oanson has joined #openstack-kuryr | 14:35 | |
| *** limao_ has joined #openstack-kuryr | 14:41 | |
| *** yamamoto has quit IRC | 14:41 | |
| *** tonanhngo has joined #openstack-kuryr | 14:44 | |
| *** limao has quit IRC | 14:45 | |
| *** salv-orlando has quit IRC | 14:47 | |
| *** hongbin has joined #openstack-kuryr | 14:52 | |
| *** limao_ has quit IRC | 14:55 | |
| *** limao has joined #openstack-kuryr | 14:56 | |
| *** yamamoto has joined #openstack-kuryr | 14:57 | |
| *** huikang has quit IRC | 14:57 | |
| *** yamamoto has quit IRC | 14:58 | |
| *** huikang has joined #openstack-kuryr | 14:58 | |
| *** huikang has quit IRC | 15:02 | |
| *** limao_ has joined #openstack-kuryr | 15:05 | |
| *** limao has quit IRC | 15:06 | |
| *** yamamoto has joined #openstack-kuryr | 15:15 | |
| *** limao has joined #openstack-kuryr | 15:15 | |
| *** limao_ has quit IRC | 15:18 | |
| *** huikang has joined #openstack-kuryr | 15:24 | |
| *** huikang has quit IRC | 15:45 | |
| *** huikang has joined #openstack-kuryr | 15:46 | |
| *** huikang has quit IRC | 15:50 | |
| *** limao_ has joined #openstack-kuryr | 15:54 | |
| *** limao has quit IRC | 15:56 | |
| *** lezbar has quit IRC | 16:03 | |
| *** lezbar has joined #openstack-kuryr | 16:03 | |
| *** limao_ has quit IRC | 16:05 | |
| *** limao has joined #openstack-kuryr | 16:05 | |
| *** limao has quit IRC | 16:09 | |
| *** yamamoto has quit IRC | 16:12 | |
| *** huikang has joined #openstack-kuryr | 16:15 | |
| *** lezbar has quit IRC | 16:19 | |
| *** lezbar has joined #openstack-kuryr | 16:19 | |
| *** huikang has quit IRC | 16:30 | |
| *** lmdaly has quit IRC | 16:30 | |
| *** huikang has joined #openstack-kuryr | 16:31 | |
| *** huikang has quit IRC | 16:35 | |
| *** huikang has joined #openstack-kuryr | 16:40 | |
| *** tonanhngo_ has joined #openstack-kuryr | 17:00 | |
| *** tonanhngo has quit IRC | 17:00 | |
| *** huikang has quit IRC | 17:02 | |
| *** huikang has joined #openstack-kuryr | 17:02 | |
| *** huikang has quit IRC | 17:07 | |
| *** yamamoto has joined #openstack-kuryr | 17:13 | |
| *** salv-orlando has joined #openstack-kuryr | 17:19 | |
| *** yamamoto has quit IRC | 17:19 | |
| *** salv-orlando has quit IRC | 17:21 | |
| *** salv-orlando has joined #openstack-kuryr | 17:22 | |
| *** oanson has quit IRC | 17:47 | |
| *** huikang has joined #openstack-kuryr | 18:14 | |
| *** huikang has quit IRC | 18:46 | |
| *** huikang has joined #openstack-kuryr | 18:46 | |
| *** ivc_ has quit IRC | 18:47 | |
| *** akanksha_ has joined #openstack-kuryr | 18:47 | |
| *** salv-orlando has quit IRC | 18:50 | |
| *** huikang has quit IRC | 18:51 | |
| *** huikang has joined #openstack-kuryr | 19:02 | |
| *** lezbar has quit IRC | 19:11 | |
| *** lezbar has joined #openstack-kuryr | 19:11 | |
| *** openstackgerrit has quit IRC | 19:18 | |
| *** openstackgerrit has joined #openstack-kuryr | 19:18 | |
| *** lezbar has quit IRC | 19:49 | |
| *** lezbar has joined #openstack-kuryr | 19:49 | |
| *** huikang has quit IRC | 19:52 | |
| *** huikang has joined #openstack-kuryr | 19:52 | |
| *** huikang has quit IRC | 19:57 | |
| *** salv-orlando has joined #openstack-kuryr | 20:09 | |
| *** salv-orlando has quit IRC | 20:14 | |
| *** salv-orlando has joined #openstack-kuryr | 20:19 | |
| *** tonanhngo has joined #openstack-kuryr | 20:20 | |
| *** tonanhngo_ has quit IRC | 20:22 | |
| *** huikang has joined #openstack-kuryr | 20:47 | |
| *** huikang has quit IRC | 21:02 | |
| *** huikang has joined #openstack-kuryr | 21:03 | |
| *** huikang has quit IRC | 21:07 | |
| *** tonanhngo has quit IRC | 21:19 | |
| *** sdake has quit IRC | 21:19 | |
| *** sdake has joined #openstack-kuryr | 21:25 | |
| *** sdake has quit IRC | 21:45 | |
| *** sdake has joined #openstack-kuryr | 21:46 | |
| *** sdake has quit IRC | 21:59 | |
| *** huikang has joined #openstack-kuryr | 22:02 | |
| *** huikang has quit IRC | 22:06 | |
| *** huikang has joined #openstack-kuryr | 22:09 | |
| *** tonanhngo has joined #openstack-kuryr | 22:17 | |
| *** huikang has quit IRC | 22:21 | |
| *** huikang has joined #openstack-kuryr | 22:22 | |
| *** huikang has quit IRC | 22:26 | |
| *** salv-orlando has quit IRC | 22:58 | |
| *** lezbar has quit IRC | 23:03 | |
| *** lezbar has joined #openstack-kuryr | 23:03 | |
| *** hongbin has quit IRC | 23:10 | |
| *** fkautz_ is now known as fkautz | 23:13 | |
| *** fkautz has joined #openstack-kuryr | 23:13 | |
| *** salv-orlando has joined #openstack-kuryr | 23:16 | |
| *** sdake has joined #openstack-kuryr | 23:30 | |
| *** huikang has joined #openstack-kuryr | 23:31 | |
| *** salv-orlando has quit IRC | 23:48 | |
| *** yamamoto has joined #openstack-kuryr | 23:48 | |
| *** huikang has quit IRC | 23:50 | |
| *** huikang has joined #openstack-kuryr | 23:51 | |
| *** huikang_ has joined #openstack-kuryr | 23:54 | |
| *** huikang has quit IRC | 23:55 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!