Monday, 2017-01-16

*** neiljerram has quit IRC00:25
*** salv-orl_ has quit IRC00:27
*** limao has joined #openstack-kuryr00:58
openstackgerritMerged openstack/fuxi: Raise exception when find more than one matched Cinder volumes  https://review.openstack.org/38793701:24
*** salv-orlando has joined #openstack-kuryr01:28
*** tonanhngo has joined #openstack-kuryr01:28
*** tonanhngo has quit IRC01:30
*** salv-orlando has quit IRC01:35
*** hongbin has joined #openstack-kuryr02:17
*** salv-orlando has joined #openstack-kuryr02:31
*** salv-orlando has quit IRC02:36
*** tonanhngo has joined #openstack-kuryr03:04
*** tonanhngo has quit IRC03:05
*** severion has joined #openstack-kuryr03:10
*** salv-orlando has joined #openstack-kuryr03:32
*** salv-orlando has quit IRC03:36
*** tonanhngo has joined #openstack-kuryr03:44
*** tonanhngo has quit IRC03:45
*** vikasc has quit IRC03:45
*** janki has joined #openstack-kuryr03:51
*** vikasc has joined #openstack-kuryr03:57
*** vikas_ has joined #openstack-kuryr04:01
*** vikasc has quit IRC04:03
*** hongbin has quit IRC04:07
*** hongbin has joined #openstack-kuryr04:07
openstackgerritMatt McEuen proposed openstack/kuryr-libnetwork: Add --gateway to README network create examples  https://review.openstack.org/42049304:09
*** hongbin has quit IRC04:13
*** tonanhngo has joined #openstack-kuryr04:30
*** tonanhngo has quit IRC04:31
*** salv-orlando has joined #openstack-kuryr04:33
*** salv-orlando has quit IRC04:38
*** tonanhngo has joined #openstack-kuryr05:04
*** tonanhngo has quit IRC05:05
*** severion has quit IRC05:18
*** v1k0d3n has quit IRC05:18
*** salv-orlando has joined #openstack-kuryr05:34
*** v1k0d3n has joined #openstack-kuryr05:35
*** salv-orlando has quit IRC05:38
*** tonanhngo has joined #openstack-kuryr05:44
*** tonanhngo has quit IRC05:46
*** v1k0d3n has quit IRC05:48
*** v1k0d3n has joined #openstack-kuryr05:49
*** tonanhngo has joined #openstack-kuryr06:04
*** tonanhngo has quit IRC06:05
*** tonanhngo has joined #openstack-kuryr06:22
*** tonanhngo has quit IRC06:23
*** pmannidi has quit IRC06:29
*** pmannidi has joined #openstack-kuryr06:32
*** pmannidi is now known as pmannidi|mtg06:32
*** salv-orlando has joined #openstack-kuryr06:35
*** salv-orlando has quit IRC06:39
*** pmannidi|mtg is now known as pmannidi07:00
*** yamamoto has quit IRC07:04
*** pmannidi has quit IRC07:04
*** pmannidi has joined #openstack-kuryr07:18
*** vikas_ has quit IRC07:25
*** tonanhngo has joined #openstack-kuryr07:27
*** tonanhngo has quit IRC07:29
*** vikas_ has joined #openstack-kuryr07:29
*** pcaruana has joined #openstack-kuryr07:34
*** salv-orlando has joined #openstack-kuryr07:36
*** salv-orlando has quit IRC07:40
*** roeyc has joined #openstack-kuryr07:51
*** tonanhngo has joined #openstack-kuryr08:21
*** tonanhngo has quit IRC08:22
*** roeyc has quit IRC08:26
*** salv-orlando has joined #openstack-kuryr08:37
*** salv-orlando has quit IRC08:41
*** tonanhngo has joined #openstack-kuryr08:46
*** tonanhngo has quit IRC08:47
openstackgerritDongcan Ye proposed openstack/kuryr-libnetwork: Removes subnetpool_id tag for Neutron existing subnet  https://review.openstack.org/41973509:00
*** roeyc has joined #openstack-kuryr09:29
*** garyloug has joined #openstack-kuryr09:33
*** vikas_ has quit IRC09:35
*** salv-orlando has joined #openstack-kuryr09:37
*** yedongcan has joined #openstack-kuryr09:39
*** salv-orlando has quit IRC09:42
*** saneax-_-|AFK is now known as saneax09:43
*** vikas_ has joined #openstack-kuryr09:53
*** roeyc has quit IRC09:59
*** roeyc has joined #openstack-kuryr10:01
*** limao has quit IRC10:07
*** devvesa has joined #openstack-kuryr10:09
*** roeyc has quit IRC10:14
*** yedongcan has left #openstack-kuryr10:38
*** salv-orlando has joined #openstack-kuryr10:38
*** salv-orlando has quit IRC10:43
*** neiljerram has joined #openstack-kuryr10:51
janonymouslimao , ivc_ : Congrats! Well deserved cores :)11:00
apuimedoindeed!11:05
janonymous:)11:06
*** tonanhngo has joined #openstack-kuryr11:06
*** tonanhngo has quit IRC11:08
*** salv-orlando has joined #openstack-kuryr11:39
ivc_janonymous apuimedo thanks :)11:40
apuimedothanks to you for the hard work!11:40
*** salv-orlando has quit IRC11:43
vikas_ivc_, congrats :)11:45
*** roeyc has joined #openstack-kuryr11:49
*** saneax is now known as saneax-_-|AFK12:01
*** janki has quit IRC12:18
*** janki has joined #openstack-kuryr12:20
*** salv-orlando has joined #openstack-kuryr12:40
*** salv-orlando has quit IRC12:44
*** salv-orlando has joined #openstack-kuryr12:46
*** janki has quit IRC12:58
*** dougbtv has joined #openstack-kuryr13:00
*** janki has joined #openstack-kuryr13:06
*** garyloug has quit IRC13:34
*** janki has quit IRC13:38
*** salv-orlando has quit IRC13:46
*** limao has joined #openstack-kuryr13:49
*** yedongcan has joined #openstack-kuryr13:54
*** saneax-_-|AFK is now known as saneax13:59
*** limao has quit IRC14:00
*** garyloug has joined #openstack-kuryr14:00
*** limao has joined #openstack-kuryr14:02
*** tonanhngo has joined #openstack-kuryr14:08
*** tonanhngo has quit IRC14:10
*** mattmceuen has joined #openstack-kuryr14:11
*** janki has joined #openstack-kuryr14:16
openstackgerritMerged openstack/kuryr-kubernetes: docs: Fix image rendering  https://review.openstack.org/41998114:18
*** hongbin has joined #openstack-kuryr14:27
*** janki has quit IRC14:41
*** v1k0d3n has quit IRC14:43
*** salv-orlando has joined #openstack-kuryr14:47
openstackgerritMerged openstack/kuryr-libnetwork: Add --gateway to README network create examples  https://review.openstack.org/42049314:50
*** salv-orlando has quit IRC14:51
apuimedoivc_: My reading is that it behaves the same15:00
apuimedobeing that we do not expose the containers to the hosts15:01
ivc_apuimedo i think with k8s externalIP you can have multiple services sharing the same external IP15:01
ivc_apuimedo but if we use floating ip to expose lbaas that would be different15:02
*** yedongcan has left #openstack-kuryr15:03
ivc_apuimedo so imo in our case floating-ip actually maps to 'loadbalancer' type service and i'm not sure if we can support external IP15:05
apuimedothere's no question that floating-ip maps to loadbalancer type15:07
*** hongbin has quit IRC15:08
ivc_apuimedo its just a bit confusing that we have lbaas for both clusterIP and loadbalancer type services15:09
apuimedoI think it's quite useful while we don't have loadbalancer type support (which IIRC requires implementing a cloud provider in K8s)15:09
*** roeyc has quit IRC15:11
openstackgerritMerged openstack/fuxi: Make py35 devstack gate working  https://review.openstack.org/41968315:17
mchiapperosorry, back to the previous race topic, so, potentially batch of subsequent calls to neutron could be unsafe, right?15:22
mchiappero*any batch15:22
*** saneax is now known as saneax-_-|AFK15:22
ltomasboyes, calls in OpenStack are mostly async15:27
ltomasboso, as when you call trunk_add_subport it also internally calls update_port API, it happens that, as we also call update_port from kuryr-libnetwork15:29
ltomasbothe first part of trunk_add_subport gets executed first, then the kuryr-libnetwork update_port call, and finally the trunk_add_subport call to update_port15:29
ivc_ltomasbo that's not exactly true. if you made an api request and got a response, the data in that response is already commited15:30
ltomasboyes, if the call is sync, yes15:30
mchiapperono ok, I understood that specific problem, I'm wondering whether there are other part of the code potentially with that issue15:31
ltomasboand when you perform the update_port and you received the response, then it is commited15:31
mchiapperois there a way to batch calls?15:31
mchiapperoand of course execute them atomically15:31
ltomasbothe problem is that trunk_add_subports make a few tasks, and one of then is to call update_port15:32
mchiapperono ok, but what if I update the port and read back, do I have the guarantee the subsequent read will contain the updated info?15:32
mchiapperobesides that specific trunk_add_subports problem15:33
ltomasbowhen you update the port, the subsequent call will have the updated info15:33
mchiapperoI mean in general15:33
ltomasbothe problem is that there is another call in between your write and your read15:33
ltomasbochanging the info15:33
mchiappero?15:34
ltomasboI mean, if 2 entities trigger two update ports at the same time, you cannot know which one will be the first one and the second one being executed15:34
mchiapperobroadly speaking, what are the guarantees from neutron?15:34
ltomasboso, it could lead to the wrong information (if there was a specific order)15:35
mchiapperoltomasbo: that makes perfectly sense15:35
mchiapperobut what if I have an update and a read?15:35
ltomasbothen, the read should have the updated info (unless there is a cache method keeping the value for a certain time)15:36
mchiapperoalso, I'm thinking whether batching is supported15:36
ltomasbonot sure, but I think it goes against scalability design15:37
mchiapperoI don't see how15:38
mchiapperoanyway, still, I don't fully understand whether the return code from neutron means "enqueued" or "done"15:38
mchiapperobecause if it's the latter then the race shouldn't be there15:39
mchiappero(end if it's the former support for atomic changes/batches should be there)15:41
*** tonanhngo has joined #openstack-kuryr15:41
*** tonanhngo has quit IRC15:42
ltomasboseems it is done in the sense it is written in the database15:43
ltomasbobut that for single calls, the problem here is that the trunk_subport_add is also calling update_port, and that is not ensured (maybe it is even a bug...)15:44
ivc_ltomasbo do you mean that when you have 'update_port' (a) followed by 'trunk_subport_add' (b) and then 'show_port' (c) it is possible to get either 'kuryr:container' from (a) or 'trunk:subport' from (b) in (c) query?15:47
*** limao has quit IRC15:47
ivc_ltomasbo or is it always 'trunk:subport'?15:47
*** salv-orlando has joined #openstack-kuryr15:48
ltomasboin my case, the kuryr code does this:15:49
ltomasbo- trunk_subport_add15:49
ltomasbo- update_port15:49
*** hongbin has joined #openstack-kuryr15:49
ltomasboand it ends up with turnk:subport15:49
ltomasboif I do this:15:49
ltomasbo-trunk_subport_add15:49
ltomasbo- sleep 115:49
ltomasbo- update_port15:49
ltomasboit ends up with kuryr:container15:49
ivc_ltomasbo in the first case, is update_port called after successful return from 'trunk_subport_add' or are they both called async?15:51
ltomasbojust using the neutron_client, one after another in the kuryr-libnetwork code15:51
*** salv-orlando has quit IRC15:52
ltomasbohttps://github.com/openstack/kuryr-libnetwork/blob/master/kuryr_libnetwork/port_driver/drivers/vlan.py#L61:L6415:52
ivc_got it. it seems that we need to dig into neutron trunk impl to find the part that does that async update. i wonder why is it async in the first place15:57
apuimedoprobably a case of premature optimization15:57
*** apuimedo is now known as apuimedo|away15:57
ivc_apuimedo|away ltomasbo it's worse16:00
ivc_ltomasbo https://github.com/openstack/neutron/blob/master/neutron/services/trunk/rpc/server.py#L150-L16616:02
ivc_its triggered by agent16:02
mchiapperoI haven't checked the code, but that's exactly my question... besides being handled asynchronously or not, what's the contract? What can I expect to be done in Neutron once trunk_subport_add (or whatever call) returns?16:08
mchiapperoat least we know whether there is a bug by definition or other code is potentially broken in kuryr16:09
ltomasboI found this:        # NOTE(status_police) Set the trunk in BUILD state before processing16:10
ltomasbo        # subport bindings. The trunk will stay in BUILD state until an16:10
ltomasbo        # attempt has been made to bind all subports passed here and the16:10
ltomasbo        # agent acknowledges the operation was successful.16:10
mchiapperoin general, I would not expect such timing issues not to happen, or provide facilities to work with them, which is what I meant above. Then extending the API can be okay anyway, but still, I feel there is something broken in neutron16:10
mchiapperosorry, I s/I would not/I would/16:11
mchiapperouff.. also remove "I" :D16:11
ivc_ltomasbo we probably need a 'wait-loop' for trunk similar to what we have for port status=ACTIVE16:22
ltomasbothat is one of the solutions16:22
ltomasbobut it will delay container booting more16:22
ivc_ltomasbo but we need to delay for the same reason as for port's status=ACTIVE16:23
ivc_otherwise you could probably get a container that does not have network access16:23
ltomasbowhy no network access?16:24
ivc_because trunk is configured async16:24
ivc_so if you just add a subport and fire up a container you might end up with a running container while neutron/agent are still configuring subport16:25
ivc_ltomasbo btw how will it work if neutron agent is down?16:26
ivc_will it start a container now?16:26
mchiapperoI still don't understand why this is possible, every async calls provide a callback/notification system, or batch calls16:27
ltomasboivc_, I though you meant for the trunk_subport_add16:27
ltomasbos/though/thought16:27
ivc_ltomasbo yes i mean trunk_subport_add16:27
ltomasbothe wait for port status = ACTIVE is there anyway16:27
ltomasbothat is in a different kuryr-libnetwork/controller.py step, waiting for creating the container16:28
ltomasboso, that part is exactly the same as for normal ports16:28
ivc_ok but still 'trunk_subport_add' have pretty much the same async behaviour16:28
*** tonanhngo has joined #openstack-kuryr16:28
ivc_mchiappero its not completely async. it does some work and returns a state with BUILD status and you can poll it for updates16:30
ivc_mchiappero unfortunately the 'notification' mechanism is sort of lacking16:30
*** salv-orlando has joined #openstack-kuryr16:30
mchiapperoivc_: whatever... it's bad/incomplete design16:31
mchiapperowhich is worrisome16:31
ivc_e.g. we have a nova notifier that for port's status=ACTIVE, but it's just for nova16:31
mchiapperoso, let's poll then, since that's the expected approach :)16:32
ivc_mchiappero thats what we do now for port's status in both kuryr-libnetwork and kuryr-k8s16:32
mchiapperoivc_: one more reason to do the same (I didn't know, I never noticed)16:33
ivc_mchiappero tho at some point we could add another method using neutron 'notification driver' (meaning we'll connect to neutron's mq exchange)16:33
*** tonanhngo has quit IRC16:34
mchiapperoivc_: whatever works :)16:35
ivc_ltomasbo mchiappero imo the right way to do it as ltomasbo has shown with "sleep(1)" between trunk and port update, except instead of 'sleep' we should poll for trunk status > BUILD16:35
mchiapperoyeah ok16:36
ivc_ltomasbo but ofc if we can get neutron team to update trunk_subport_add to accept device_owner, nothing of that would be necessary16:36
mchiapperoyes, I'm not against that, as I said, that's okay anyway16:37
mchiapperobut still, every single piece of software on earth needs to provide a well defined contract and provide a notification to the caller of the completion, either naturally by returning on blocking calls or by means of notifications/callbacks for non-blocking calls16:38
mchiapperoit seems this is missing here16:38
mchiapperothat's my only complain :)16:39
ltomasbo:D16:42
ivc_mchiappero dreamer xD16:58
*** devvesa has quit IRC17:09
mchiapperonaaa17:09
mchiapperobut seriously, it's a pity kuryr has to poll for a deficiency present elsewhere17:10
mchiapperoanyway... :)17:10
mchiapperoLOL, we might start polling people from neutron to begin with :P17:11
openstackgerritOpenStack Proposal Bot proposed openstack/fuxi: Updated from global requirements  https://review.openstack.org/41992917:18
openstackgerritOpenStack Proposal Bot proposed openstack/kuryr: Updated from global requirements  https://review.openstack.org/41879217:20
*** tonanhngo has joined #openstack-kuryr17:37
*** neiljerram has quit IRC17:41
*** tonanhngo has quit IRC17:42
*** roeyc has joined #openstack-kuryr17:49
*** roeyc has quit IRC17:49
*** garyloug has quit IRC18:07
*** tonanhngo has joined #openstack-kuryr18:10
*** tonanhngo has quit IRC18:11
*** portdirect is now known as intlabs18:14
*** intlabs is now known as portdirect18:17
*** tonanhngo has joined #openstack-kuryr18:33
*** salv-orlando has quit IRC18:35
*** salv-orlando has joined #openstack-kuryr18:36
*** tonanhngo has quit IRC18:38
*** tonanhngo has joined #openstack-kuryr18:49
*** tonanhngo has quit IRC18:49
*** tonanhngo has joined #openstack-kuryr18:59
*** tonanhngo has quit IRC18:59
*** tonanhngo has joined #openstack-kuryr19:19
*** tonanhngo has quit IRC19:20
*** tonanhngo has joined #openstack-kuryr19:29
*** tonanhngo has quit IRC19:30
*** salv-orlando has quit IRC20:23
openstackgerritOpenStack Proposal Bot proposed openstack/kuryr: Updated from global requirements  https://review.openstack.org/41879220:31
openstackgerritOpenStack Proposal Bot proposed openstack/kuryr-libnetwork: Updated from global requirements  https://review.openstack.org/41993220:31
*** salv-orlando has joined #openstack-kuryr21:09
*** tonanhngo has joined #openstack-kuryr21:23
*** tonanhngo has quit IRC21:23
*** tonanhngo has joined #openstack-kuryr21:28
*** salv-orlando has quit IRC21:47
*** v1k0d3n has joined #openstack-kuryr21:50
*** salv-orlando has joined #openstack-kuryr22:12
*** yamamoto has joined #openstack-kuryr22:15
*** salv-orl_ has joined #openstack-kuryr22:24
*** salv-orlando has quit IRC22:26
*** v1k0d3n has quit IRC23:08
*** salv-orl_ has quit IRC23:50
*** mattmceuen has quit IRC23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!