Friday, 2017-08-04

*** tongl has quit IRC00:45
*** http_GK1wmSU has joined #openstack-neutron-ovn02:53
*** http_GK1wmSU has left #openstack-neutron-ovn02:56
*** anilvenkata has joined #openstack-neutron-ovn03:39
*** janki has joined #openstack-neutron-ovn05:12
openstackgerritvenkata anil proposed openstack/networking-ovn master: Fix gate by skipping neutron test
*** jchhatbar has joined #openstack-neutron-ovn05:34
*** Guest14 has joined #openstack-neutron-ovn05:36
*** janki has quit IRC05:36
*** Guest14 has quit IRC05:39
*** mmirecki has joined #openstack-neutron-ovn06:16
openstackgerritvenkata anil proposed openstack/networking-ovn master: Fix gate by skipping neutron test
*** pcaruana has joined #openstack-neutron-ovn07:38
*** yamamoto has quit IRC08:37
*** yamamoto has joined #openstack-neutron-ovn08:50
*** lucas-afk is now known as lucasagomes08:55
lucasagomesdalvarez, I will look into the functional tests failures. Or, are you into it ?08:56
dalvarezlucasagomes, anilvenkata is i think09:00
dalvarezbut i can help09:00
dalvarezim busy with some stuff but i can help :)09:00
anilvenkatalucasagomes, I am looking into them09:00
anilvenkatadalvarez, ^09:01
lucasagomesright on, anilvenkata if you need any help lemme know09:01
anilvenkatalucasagomes, sure09:01
dalvarezanilvenkata, i saw your last comment :(09:01
anilvenkatadalvarez, thanks :)09:01
*** Guest14 has joined #openstack-neutron-ovn09:28
*** anilvenkata is now known as anilvenkata|LUNC09:36
openstackgerritMiguel Angel Ajo proposed openstack/networking-ovn master: refarch: Update documentation and diagrams
Guest14numans  ^ I saw that we also need to update the details about DHCP :) this is talking about dhcp agent in many places :D09:53
*** Guest14 is now known as ajo09:53
numansajo, thanks for the patch - I agree10:00
*** anilvenkata|LUNC is now known as anilvenkata10:02
*** janki has joined #openstack-neutron-ovn10:11
*** mmirecki is now known as mmirecki_lunch10:12
*** jchhatbar has quit IRC10:12
*** openstackgerrit has quit IRC10:18
*** anilvenkata has quit IRC10:20
*** openstackgerrit has joined #openstack-neutron-ovn10:26
openstackgerritDaniel Alvarez proposed openstack/networking-ovn master: Make Metadata agent independent from other config files
*** jchhatbar has joined #openstack-neutron-ovn10:27
dalvarezajo, ^10:28
dalvarezajo ^10:28
*** janki has quit IRC10:29
*** yamamoto has quit IRC10:32
*** yamamoto has joined #openstack-neutron-ovn10:33
*** yamamoto has quit IRC10:38
openstackgerritDaniel Alvarez proposed openstack/networking-ovn master: Rename metadata proxy config dir
*** yamamoto has joined #openstack-neutron-ovn10:48
ajodalvarez yummy10:56
*** jchhatbar has quit IRC11:06
openstackgerritNuman Siddique proposed openstack/networking-ovn master: Fix gate issues
openstackgerritLucas Alvares Gomes proposed openstack/networking-ovn master: Idea proposal: Neutron/OVN database consistency problem
*** lucasagomes is now known as lucas-hungry11:31
*** yamamoto has quit IRC11:39
*** janki has joined #openstack-neutron-ovn11:44
*** mmirecki_lunch is now known as mmirecki11:44
openstackgerritMiguel Angel Ajo proposed openstack/networking-ovn master: Make the metadata support work on multinode
dalvarezajo, sry i was having lunchhhh11:53
numansdalvarez, with my hijacked patch approach - functional tests for py27 are passing12:14
dalvareznumans, PS7'12:14
numansdalvarez, but failing for py34 for some other reason - which i think can be fixed :) -
numansdalvarez, yes12:14
dalvareznumans, 2017-08-04 11:25:11.419792 | 2017-08-04 11:25:11.419 |     b"TypeError: can't pickle dict_keys objects"12:15
numansdalvarez, not a python expert -  you think it could be handled :)12:16
dalvareznumans, but PS7 sticks to OVS 2.712:16
numansdalvarez, yes for functional tests12:17
numansdalvarez, right now we are in a tricky situation - if we take anil's p6 patch, it breaks the ovs-release job12:17
dalvareznumans, yeah not sure what we want to do... i like Anil's patch but we had a look at that together so it doesn't count much12:18
numansdalvarez, the right approach is handle the db or release versioning properly in the code , but that's not straight forward12:18
dalvarezlet me take a look at the python thing12:18
numansdalvarez, so i think we can switch to ovs 2.7 for functional tests12:19
numansdalvarez, ++12:19
dalvareznumans, i dont see why py3 is failing now12:23
dalvarezthis patch doesn't have to do with the deepcopy12:24
numansdalvarez, yeah12:24
dalvarezit's some other patch recently merged in neutron?!12:24
numansdalvarez, but how that is related to neutron ?12:24
dalvarezi mean.. that should be failing in neutron as well.. dont know12:24
numansdalvarez, ok12:25
numansdalvarez, yeah you are right12:26
numansdalvarez, strange12:26
dalvareznumans, im trying to reproduce it locally by calling modify_fields_to_db12:26
numansdalvarez, cool12:26
numansi am out of adjectives now :)12:26
dalvareznumans, hahaha12:27
openstackLaunchpad bug 1666113 in networking-ovn "In python3.5 environment, synchronization router exception" [Undecided,Fix released] - Assigned to Guoshuai Li (liguoshuai1990)12:36
dalvareznumans, i think that fixed it for floating ips but for some reason it breaks now for us...12:37
dalvarezbut trying to understand what does our patch change...12:38
*** yamamoto has joined #openstack-neutron-ovn12:40
*** yamamoto has quit IRC12:45
numansdalvarez, ok12:45
dalvarezthis looks like it broke it12:48
dalvareznumans, can you run py3 tests locally?12:48
dalvarezso that we can remove the list() and try?12:48
numansdalvarez, worth a try12:48
dalvarezman we're depending so much on neutron tests :(12:48
dalvareznumans, if you have it I can try12:48
*** anilvenkata has joined #openstack-neutron-ovn12:49
numansdalvarez, yeah12:49
numansdalvarez, you want to try where ?12:49
dalvarezlucas-hungry, numans ajo:
dalvarezthis is what broke it :)12:50
*** lucas-hungry is now known as lucasagomes12:50
dalvareznumans, i mean if you have some environment ready to run the functional tests and try removing the 'list()' there12:50
numansdalvarez, ok. got it12:50
numansdalvarez, i guess need to install py3512:50
* dalvarez reporting the bug 12:50
dalvareznumans, yup12:50
lucasagomesdalvarez, oh, lemme take a look12:50
dalvareznumans, lucasagomes i think we want to try without the 'list' here:
lucasagomesdalvarez, :-( another failure then12:51
dalvarezlike the old code12:51
dalvarezyeah man12:51
dalvarezit's crazy lately12:51
dalvarezwell not sure if without the 'list' there12:52
dalvarezit changed completely12:52
numansdalvarez, testing with python 3.4 (couldn't get py35 for centos from epel)12:54
numansdalvarez, are you suggesting to remove list from ?12:54
numansdalvarez, i.e to rever the bug 1666113 fix ?12:55
openstackbug 1666113 in networking-ovn "In python3.5 environment, synchronization router exception" [Undecided,Fix released] - Assigned to Guoshuai Li (liguoshuai1990)12:55
dalvareznumans, lucasagomes not sure, look:12:55
dalvarezif i understood the code correctly this is what it's getting done:12:55
dalvareznumans, lucasagomes  ^ it works for me regardless of the contents of device owners apparently12:57
dalvarezim running that script with py3.512:57
dalvarez>>> modify_fields_to_db({'port_type': owners})12:57
dalvarez{'port_type': ['network:router_interface', 'network:router_gateway']}12:57
dalvarezsame without 'list'12:57
dalvareznumans, lucasagomes also with kwargs:
openstackgerritNuman Siddique proposed openstack/networking-ovn master: Fix gate issues
* lucasagomes looks13:04
lucasagomesdalvarez, on a side note, thanks for the review on the spec! Very useful, I've answer that13:04
dalvarezlucasagomes, thanks for that! :) i enjoyed reading it13:05
dalvarezyou did a really awesome job with the journaling and now rethiking the whole thing again13:05
lucasagomesdalvarez, you, numans, anil and others helped a lot !13:06
* lucasagomes is trying to find the python3.5 error13:06
* numans still couldn't look into it :(13:06
dalvarezlucasagomes, if you take a look at my last pastebin where i tried to isolate the call13:07
dalvarezit should work13:07
dalvareznumans, i think your new PS will do nothing :P13:07
dalvarezbut it's ok, i'll take care of it hopefully13:07
numansdalvarez, :(13:07
dalvareznumans, <313:07
numansdalvarez, i couldn't run it locally13:07
lucasagomesdalvarez, numans ins't the problem here the db_router.keys() from ?13:13
dalvarezyeah trying that now ;P13:14
lucasagomesbecause that would return a iterable in python3 ?13:14
dalvarezi was on it13:14
dalvarezi think so13:14
lucasagomesif we just add a list() around that13:14
lucasagomesit should work I believe13:14
lucasagomesdalvarez, cool, try updating that patch of yours: with it13:15
dalvarezthat'll make it13:15
dalvarez>>> routers={'a': 1, 'b': 2}13:16
dalvarez>>> fun(None, router_ids=routers.keys(), port_type=owners)13:16
dalvarezTraceback (most recent call last):13:16
dalvarez  File "<stdin>", line 1, in <module>13:16
dalvarez  File "<stdin>", line 2, in fun13:16
dalvarez  File "<stdin>", line 2, in modify_fields_to_db13:16
dalvarez  File "/usr/lib64/python3.5/", line 155, in deepcopy13:16
dalvarez    y = copier(x, memo)13:16
dalvarez  File "/usr/lib64/python3.5/", line 243, in _deepcopy_dict13:16
dalvarez    y[deepcopy(key, memo)] = deepcopy(value, memo)13:16
dalvarez  File "/usr/lib64/python3.5/", line 174, in deepcopy13:16
dalvarez    rv = reductor(4)13:16
dalvarezTypeError: can't pickle dict_keys objects13:16
dalvarezopss sry13:16
dalvarezlucasagomes, ^  that's it :)13:16
dalvarezwith a list around that it works13:16
numansdalvarez, it passed now13:17
lucasagomesdalvarez, cool!13:17
openstackgerritNuman Siddique proposed openstack/networking-ovn master: Fix gate issues
lucasagomesdalvarez, btw, there's a pep8 error in that patch... also, would be good to squash anilvenkata's fix onto it too ?13:18
numansdalvarez, but i forgot to run pep8 locally and it failed in CI :)13:18
lucasagomesor leave as a separated thing ?13:18
anilvenkatalucasagomes, I will squash that13:18
lucasagomesI mean instead of skipping that test, because now we know what's the real problem13:18
lucasagomesanilvenkata, o/ thanks13:18
anilvenkatawc :)13:18
dalvarezlucasagomes, yeah we dont need to skip it anymore13:20
dalvarezwe can squash it and add the two bug numbers13:20
dalvarezplumbling friday anilvenkata lucasagomes numans :)13:20
ajoyou're the best, guys13:21
lucasagomesdalvarez, awesome! Thanks a lot13:22
dalvarezlucasagomes, anilvenkata numans \o/13:23
dalvarezanilvenkata, are you squashing it? if so can you also please add "Closes-Bug: #1708660" to the commit message?13:27
openstackbug 1708660 in networking-ovn "functional tests failing for py35 due to a recent neutron patch" [Undecided,New] - Assigned to Daniel Alvarez (dalvarezs)13:27
anilvenkatadalvarez, ok13:27
dalvarezanilvenkata++ thanks a lot!13:27
anilvenkatadalvarez, lucasagomes  I need a suggestion, As you know, any updates to DB from will go through So I am thinking of adding the db checks( i.e if these new columns r present or not )13:30
anilvenkataajo, numans13:30
ajowhot :D13:31
anilvenkataajo, numans dalvarez lucasagomes where to add them? in or ovn_client.py13:31
dalvarezanilvenkata, so you want to fix the schema thing and not run against 2.7?13:31
lucasagomesanilvenkata, that's about the name/severity thingie ?13:31
ajoI think it is13:31
dalvarezanilvenkata, i think i'd do it in, ovn_client doesn't know much about the db schema so it's gonna be more hidden in commands.py13:31
anilvenkataajo, issue is to new columns added in ovn master  name/severity which are not present in 2.713:31 knows about the database schema13:32
dalvarezanilvenkata, numan's suggestion was to skip it for now until we have green light in our CI13:32
ajowell we may want to go back to 2.8 asap, it's needed for l3ha ;D13:32
anilvenkatadalvarez, but I have to change functional and unit tests then13:32
dalvarezand then address it but if you feel comfortable doing that that'd be fine :)13:32
dalvarezanilvenkata, only switching to 2.7 in functional testing should suffice right?13:32
anilvenkatadalvarez, but we need permanent solution13:33
dalvarezbut +1 for addressing it now for master branch! i'd have it in, sounds good to you?13:33
anilvenkatadalvarez, ajo numans lucasagomes I did same thing in l3ha patch13:33
dalvarezanilvenkata, yeah i fully agree, i was just rephrasing numans which was also coherent since we didn't have a solution in mind for the schema thing13:33
dalvarezi think it makes a lot of sense13:33
anilvenkatadalvarez, lucasagomes ajo numans
dalvarezlet's do it in then!13:33
anilvenkatadalvarez, lucasagomes ajo numans I have to change many unit tests to accomodate that13:34
ajoyeah, those things may move later in time to ovsdbapp13:34
*** fzdarsky has joined #openstack-neutron-ovn13:34
dalvarezanilvenkata, yeah is the place13:34
dalvarezand since you're already doing it, let's go for it13:34
anilvenkatadalvarez, ajo numans lucasagomes but I have to change some unit tests, like I did for l3ha13:35
lucasagomesajo, ++ for having it in ovsdbapp13:35
dalvarezanilvenkata, i tend to agree with numans:   let's first have CI pass13:35
dalvarezand then address it the way you're doing it now?13:35
anilvenkatadalvarez, sure13:35
dalvarezand by having CI green we just need to switch to 2.7 branch13:36
dalvarezas the famous hijacked patch does right now :D13:36
anilvenkatadalvarez, ajo lucasagomes  numans thanks guys13:37
ajothank you anilvenkata13:37
lucasagomesyeah thank YOU anilvenkata13:38
dalvarezteam team team13:39
openstackgerritLucas Alvares Gomes proposed openstack/networking-ovn master: Idea proposal: Neutron/OVN database consistency problem
*** janki has quit IRC13:46
numanslucasagomes, - so far going good. functional job passing for py27 and py3513:47
russellbhappy friday everyone13:48
numansrussellb, hi13:48
numansrussellb, we are having with the gate today13:48
numanshopefully it will be resolved soon.13:48
dalvarezhey hey :)13:49
dalvarezman everything's broken today :p13:49
dalvarezi remember having seen something like that in the past in neutron gate13:49
dalvarezsomething related to sudo has changed lately?13:50
dalvarezanilvenkata, lucasagomes ^13:50
dalvarezajo ^13:50
russellbcool - ping if/when it needs a +213:50
* ajo looks13:50
numansdalvarez, that part of code runs "sudo ip " commands right to create namespace, create veth etc13:51
dalvareznumans, it does13:51
ajohmmm yikes, dalvarez that looks like if sudo was epecting to ask for a password13:51
dalvarezajo but it didn't fail for the patch you submitted today13:51
numansdalvarez, ajo yeah looks like13:51
dalvarezit's the tempest nv job13:52
dalvarezajo,  numans:
dalvarezthis one passed this morning13:52
ajodalvarez may be they updated the image or devstack ?13:52
dalvarezwoa in between the two?13:52
dalvarezprolly we uploaded almost simultaneously13:52
dalvarezanyhow anything executing sudo should fail (not sure if we have something else using sudo)13:52
dalvareznumans, however i'm not calling sudo directly IIRC, just rootwrap13:53
ajono new change in devstack since Aug 1st13:53
ajoso not that13:53
dalvarezajo, now im not passing in neutron.conf13:53
dalvarezmaybe the rootwrap configuration is skipped now13:53
ajodalvarez hmm, it could be that13:53
dalvarezajo any suggestions around that?13:53
ajobut here locally it's working without that somehow :?13:53
dalvarezshall i assume that we have neutron.conf?13:53
dalvarezajo cause you're still passing in /etc/neutron.conf13:53
ajodalvarez no, but my neutron.conf is fake13:54
ajoI only have what I put13:54
dalvarez 620 [agent]13:54
dalvarez 621 root_helper_daemon = sudo /usr/bin/neutron-rootwrap-daemon /etc/neutron/rootwrap.conf13:54
dalvarez 622 root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf13:54
dalvarez 62313:54
dalvarezajo ml2 conf maybe?13:54
ajoI don't have it13:54
dalvarezman :(13:54
ajolet me check13:54
dalvarezthen i dont know13:54
ajodalvarez :13:55
ajo[vagrant@compute1 neutron]$ grep rootwrap * -R13:55
ajo[vagrant@compute1 neutron]$13:55
ajobut may be13:55
ajoI have sudo permission for my user "vagrant"13:55
ajowhich I do13:56
dalvarezoh man :)13:56
*** mlavalle has joined #openstack-neutron-ovn13:56
ajoand I have the notty option in sudoers file13:56
ajoso that's it13:56
dalvarezajo that's it13:56
ajoyou need to configure rootwrap-daemon in your agent file too13:56
dalvarezajo so what do you suggest? adding that option in devstack or in the code?13:56
ajoor make sure neutron will do it for you on the compute nodes too13:56
dalvarezneutron == devstack plugin in neutron?13:56
dalvarezlike copying neutron.conf?13:56
ajodalvarez it may be easier to put in the networking-ovn devstack plugin13:56
ajocompared to doing it in neutron repo13:57
ajoI leave it to your choice ;D , personally, I'd do it in networking-ovn ;D13:57
dalvarezajo but how? picking those options from somewhere and writing them into agent ini file?13:58
lucasagomesdalvarez, damn yet another failure :D glad you already found the problem13:58
dalvarezlucasagomes, yeah not sure how to solve it tho13:58
* lucasagomes is reading the scrollback13:59
dalvarezbecause i think we don't want to assume that compute nodes will have /etc/neutron/neutron.conf present13:59
dalvarezlucasagomes, ^13:59
dalvarezif we assume that, then i'm fine :)13:59
ajodalvarez yes, look at how devstack does it for neutron13:59
dalvarezthat's in neutron-legacy14:00
dalvarezin neutron not sure14:00
dalvarezbut i could take those14:00
ajoyou have it in lib/neutron too I think14:00
ajomay be you can just call that14:00
ajothe same way we call other stuff in lib/neutron14:01
dalvarezajo that creates directories and so on14:02
dalvarezajo that doesn't set the root_helper_daemon in ini file if i'm not mistaken14:02
anilvenkataajo, dalvarez lucasagomes should the higher layers like know that columns like 'name', 'severity' not supported for ACL table and shouldn't pass those columns to ?14:05
ajoright, but we may need that done too14:05
dalvarezajo         iniset $NEUTRON_DHCP_CONF agent root_helper_daemon "$NEUTRON_ROOTWRAP_DAEMON_CMD"14:05
dalvarezyeah probably we're already doing it14:05
dalvarezotherwise i'll do it14:05
dalvarezyoure right14:05
ajodalvarez not doing it, (at least in the metadata case)14:05
dalvarezanilvenkata, good question... i think that 'code base' should support it14:05
ajodalvarez I don't see it in my compute1 :D14:06
anilvenkataajo, dalvarez lucasagomes should be aware what columns it should/shouldn't pass to commands.py14:06
dalvarezanilvenkata, and let deal with the different schema versions :?14:06
ajo[vagrant@compute1 ~]$ ls /etc/neutron/14:06
ajometadata_agent.ini  neutron.conf14:06
dalvarezajo, looking at where to call that fun14:06
anilvenkatadalvarez, should only take care of how to write to db?14:06
lucasagomesanilvenkata, hmm maybe, how would ovn_client be aware of that ? By looking at the a speicifc version or schema or ?14:06
ajoyeah, may be it can compare the schema version14:07
anilvenkatalucasagomes, it will ask if these columns are supported or not14:07
ajoto know when the change took place ?14:07
anilvenkatadalvarez, ^14:07
dalvarezanilvenkata, lucasagomes, i think that the codebase-wise we can assume the columns be there since latest ovn version has it14:07
ajoor well, the same thing if the columns are there or not14:07
dalvarezanilvenkata, lucasagomes but then have a FIXME and check for those columns to exist in the "layer"14:07
lucasagomesdalvarez, we need to have some sort of backward compat for when these columns are not available14:08
* ajo overflows, he's awful multitasker14:08
dalvarezso that we don't have to deal with schema versions there14:08
dalvarezlol ajo14:08
*** fzdarsky has quit IRC14:08
anilvenkataajo, dalvarez lucasagomes other wise is asking something and is hiding that14:08
lucasagomesanilvenkata, yeah, it feels like OVO again :D14:09
dalvarezanilvenkata, yeah...14:09
anilvenkatano need for OVO14:09
lucasagomesyeah maybe for now we could have ovn_client being smart enough to deal with different versions14:09
lucasagomesanilvenkata, yeah just saying it's a similar problem14:09
anilvenkataas both are in same code base and aprt of same process :)14:09
lucasagomesanilvenkata, but yeah, dealing with it seems fair14:10
russellbthis is likely to be an ongoing issue in networking-ovn -- having to deal with different versions of OVN14:10
ajowe need an strategy for that14:10
lucasagomesand less misleading than requests X and in the end is requests Y14:10
russellbuse the new features if available, but make sure networking-ovn can still be used if not14:10
ajomay be a good topic for next meeting14:10
lucasagomesrussellb, yeah we should account to that14:10
numanswe need to probably find a better solution with a proper design14:10
russellbwe avoided this in the past by only supporting latest release, but as of ... right now basically, we can't really do that anymore :)14:11
russellbshould be able to rely on schema version number14:11
* anilvenkata searching for some code (poor in multitasking)14:12
ajorussellb I'd may be try to rely on looking at features of the DB14:12
ajoor not... I don't know14:13
ajoI was thinking about backport patches on core-ovn, that touch the DB14:13
ajoif we look at the schema, it'd be hard to know if the thing is present14:13
dalvarezyeah i agree with ajo..14:14
anilvenkatadalvarez, ajo russellb lucasagomes numans actually I have seen some code in ovn_client which is checking if row is already present or not(asking, then doing some stuff. similarly it can check if the columns are supported or not (asking
* anilvenkata searching again for that code14:15
dalvarezajo: sry for the task switching, are you ok with calling "configure_neutron_rootwrap" where we check if metadata service is enabled?14:15
lucasagomesajo, as long as the changes to the db are backward compatible and we have a number bumped for every change in the schema we could rely on these numbers no ?14:15
russellbOK - i don't feel too strongly about schema version vs introspecting schema itself14:16
ajodalvarez that'd be ok, yes14:16
russellbschema version sounds like slightly less code but14:16
openstackgerritDaniel Alvarez proposed openstack/networking-ovn master: Make Metadata agent independent from other config files
dalvarezajo thanks ^14:16
ajorussellb yeah, it started thinking of that, but I started feeling the pain of bugs that required schema changes14:16
ajostill... well.. this is generally for new features14:16
ajowe don't tend to back port that, but who knows ':D14:17
anilvenkataajo, dalvarez russellb dalvarez I was talking about this existing function check_for_row_by_value_and_retry , we can add a new similar function verify_attribute_supported
anilvenkatanumans, ^14:18
dalvarezanilvenkata, i like that one14:18
dalvarezi think we can stick to that until we come up with a more general approach14:18
anilvenkatadalvarez, thanks Daniel14:19
anilvenkataajo, lucasagomes what do u say about that similar to existing check_for_row_by_value_and_retry()14:19
lucasagomesanilvenkata, looks like a big workaround for me (-:14:20
lucasagomesinsert a row and then delete it to know whether it's supported or not14:20
anilvenkatalucasagomes, ok14:21
lucasagomesif that's the only way, grand, but I would love to have a better way of doing that14:21
anilvenkatalucasagomes, I will modify that14:21
lucasagomesif possible14:21
anilvenkatalucasagomes, check if any rows already present, then check for column, if now rows then insert row14:21
lucasagomesI know that for now we only want to remove that workaround pinning a version14:21
numansi think at ml2 mech driver startup, we need to check the schema version and then load the features like metadata or dns, or ipv6 RA support etc. in a way the ml2 mech driver should be smart enough and make these features kind of pluggable. not sure if this makes sense14:21
lucasagomesbut if we had a "less intrusive" way of detecting that I think we would be better off14:21
lucasagomesnumans, ++14:22
lucasagomesas long as we document that we need to restart the services after updating the schema it should be good14:23
russellbnumans: ++14:23
anilvenkatawill that be applicable for new columns also ?14:23
russellbmight be nice to check per request ... be a bit more dynamic14:24
lucasagomesanilvenkata, I would imagine so, any change to the schema would bump a certain version14:24
russellbrequested an HA gateway -- do we support that?  yes?  create.  no?  reject.14:24
lucasagomesrussellb, yeah that would be even better and would allow to update the db w/o restarting the neutron services14:25
anilvenkatabut these requests are neutron commands right?14:26
anilvenkataif so, how can user check OVN specific things like these new columns('name' and 'severity')?14:27
russellba user?14:31
russellbneutron user?14:31
russellbthey get whatever the neutron API exposes14:31
russellbi guess14:31
anilvenkatarussellb, "might be nice to check per request ... be a bit more dynamic. requested an HA gateway -- do we support that?  yes?  create.  no?  reject", - who issues this request?14:32
russellbi meant checking in the path of neutron API requests14:34
russellbcheck to see if we can fulfill the request, at request time14:34
anilvenkataok, thanks14:36
anilvenkatalucasagomes, " I would imagine so, any change to the schema would bump a certain version" is it already supported in ovn ?14:48
numansanilvenkata, it is expected to, but may not be guaranteed to be the case14:49
ajoseen in our unit tests:14:49
ajo    /opt/stack/networking-ovn/.tox/py27/lib/python2.7/site-packages/oslo_context/ DeprecationWarning: Policy enforcement is depending on the value of tenant_id. This key is deprecated. Please update your policy file to use the standard policy values.14:49
ajo      DeprecationWarning)14:49
ajoI guess we should move all tenant_id references to project_id, I guess?14:50
ajoI'm guessing twice14:50
anilvenkatanumans, oh, then w ecant relay on that14:50
numansanilvenkata, too early to say now14:50
openstackgerritMiguel Angel Ajo proposed openstack/networking-ovn master: Support for L3 gateway HA
ajojust a tiny change14:52
ajoI probably may update the unit test14:52
anilvenkataajo, thanks Miguel14:53
numansdalvarez, russellb ajo lucasagomes anilvenkata passed14:55
dalvareznumans, \o/14:55
dalvarezoh yeah!!14:55
dalvarezlet's merge it and unblock the gate :)14:56
dalvarezi have to recheck quite a good # of patches14:56
numanslucasagomes, and russellb can you please have a look and review it -
russellbi'm fine approving this to fix the gate ...14:58
russellbbut it seems really bad that new columns we don't use yet would break anything14:58
russellbit's one thing to deal with optionally using a new feature, but new features we're not using shouldn't break our tests ...14:59
openstackgerritTerry Wilson proposed openstack/networking-ovn master: WIP Start converting to ovsdbapp impls
lucasagomesanilvenkata, numans sorry I was on my 1:1, reading now15:15
lucasagomesnumans, can't we add some unittest to check for these versions bumps in OVN core then ?15:15
lucasagomeslucasagomes, like OVO, we could hash the schema and if there's any change to it we would detect in a unittest15:15
russellbwe should make our tests not need to detect it15:16
lucasagomesrussellb, but then what happens if you update the schema and forget to bump the version ? That patch could sneak in the repository no ?15:17
russellbi mean on networking-ovn side15:18
lucasagomesoh right15:18
lucasagomesoh I agree with that yeah15:18
russellbschema is hashed on core ovn side15:18
lucasagomesI was thinking about OVN core15:18
russellbyou can't update the schema without updating the hash (which sits right next to the version number in the file)15:18
russellbso as a reviewer, you shouldn't see a hash change without the version changed too15:19
lucasagomesright on, so the tests are in place already15:19
russellbon core side yeah15:19
lucasagomesthat's good then, so anilvenkata ^ sounds like we could rely on that version yes15:19
russellbcould be more explicit ... maybe to ensure a hash change comes with version change15:19
lucasagomesotherwiseguy, when you have some time, me and dalvarez have some doubts that you might help with here (L89)15:33
* otherwiseguy looks15:33
otherwiseguylucasagomes, dalvarez To be honest, I really know very little about the neutron db side of things. Are there cases where you would need to update an object and an object that is referenced as a foreign key at the same time and therefor run into lock-order/deadlock issues?15:43
dalvarezotherwiseguy, i think in neutron is already solved but what lucasagomes proposes is to use kind of a distributed lock in neutron15:44
dalvarezso we thought you would come up with some brilliant idea to not lock on neutron db and solve it at OVSDB level :)15:45
otherwiseguyI just know that most projects I've worked on that add locks after the fact have run into issues (not insurmountable ones, but still).15:45
lucasagomesotherwiseguy, dalvarez right yeah, the more specific question is whether we could rely on IDLs and not have to have a lock in neutron15:45
lucasagomesneutron db*15:45
otherwiseguyWell, my brilliant idea is to add the ability for ML2 to pass through db access to ml2 plugins and use the ovn db as the actual source for truth. I think both of you should implement that while I watch from afar.15:46
dalvarezotherwiseguy, lol15:46
dalvarezotherwiseguy, want some popcorn?15:46
otherwiseguydalvarez, yes please.15:47
otherwiseguyIt would be possible in ovsdb to do locks based on the uuid as well.15:47
dalvarezanyways that sounds good, at least the part of having the ovn db as the source for truth15:47
dalvarezotherwiseguy, as you suggested, using named locks, right?15:47
russellbthat's an enormous amount of work15:47
russellb(using only ovn db)15:47
lucasagomesotherwiseguy, yeah named locks right ?15:47
otherwiseguythey're just name-based locks, so ovsdb lock with name == uuid would be a row-level lock.15:47
lucasagomesotherwiseguy, yeah, I could add as an alternative on the spec15:48
otherwiseguyI have no idea what the performance impact of that would be.15:48
lucasagomesI was just unsure about the amount of locks that ovsdb can handle15:48
otherwiseguyall of them.15:48
lucasagomesbecause I know that for mysql it should be fine, but, idk ovsdb enough15:48
otherwiseguyit can handle all of the locks.15:48
otherwiseguy(i have no idea)15:48
lucasagomesok yeah, it's definetely possible15:48
lucasagomesin the same spec I suggest using named locks in ovsdb for making sure that only one maintenance thread runs in the whole cluster15:49
otherwiseguyIf ovsdb's distributed db was done that would be nice.15:49
lucasagomeslike we have for ovsdb_monitor.py15:49
otherwiseguyIf only there were algorithms out there for solving consensus issues. :)15:50
lucasagomesright (-: etcd!15:50
lucasagomesbut yeah...15:50
otherwiseguyraft, multi-paxos, whatever. i spent a bit of time researching all of that, but the time...who has the time...15:51
lucasagomesyou need 3 dbs running for that tho (I think, it requires minimum 3 for consensus, I might be wrong tho...)15:51
* lucasagomes needs to look into raft more15:51
otherwiseguylucasagomes, with ovsdb each worker is a db so... :D15:52
lucasagomesotherwiseguy, yup, that's the reason why I think we need a distributed lock actually, cause I'm afraid that relying on the in-memory replica model in the IDLs might lead to inconsistencies because they could be outdated15:53
* lucasagomes already had too many problems with idls :-(15:53
otherwiseguyeven with etcd, i think by default you can get stale reads though.15:57
otherwiseguyor at least that was the case when I looked at it a while ago.15:57
otherwiseguyyou can configure it so that isn't the case, just saying that the general issue is a pretty prevalent one.15:59
*** pcaruana has quit IRC16:10
*** lucasagomes is now known as lucas-afk16:28
openstackgerritMerged openstack/networking-ovn master: Fix gate issues
openstackgerritOpenStack Proposal Bot proposed openstack/networking-ovn master: Updated from global requirements
*** anilvenkata has quit IRC17:14
*** openstackstatus has quit IRC17:27
*** openstack has joined #openstack-neutron-ovn17:29
*** openstackstatus has joined #openstack-neutron-ovn17:29
*** ChanServ sets mode: +v openstackstatus17:29
*** markmcclain has quit IRC18:24
*** markmcclain has joined #openstack-neutron-ovn18:24
*** openstackstatus has quit IRC18:26
*** openstack has joined #openstack-neutron-ovn18:28
*** openstackstatus has joined #openstack-neutron-ovn18:28
*** ChanServ sets mode: +v openstackstatus18:28
openstackgerritAkihiro Motoki proposed openstack/networking-ovn master: Improve oslo-config-generator setting
openstackgerritAkihiro Motoki proposed openstack/networking-ovn master: Add auto-generated config reference
-openstackstatus- NOTICE: Gerrit is being restarted to pick up CSS changes and should be back momentarily20:36
*** mmirecki has quit IRC21:08
*** yamamoto has joined #openstack-neutron-ovn22:00
*** yamamoto has quit IRC22:41
*** yamamoto has joined #openstack-neutron-ovn23:09

Generated by 2.15.3 by Marius Gedminas - find it at!