{"action":"created","issue":{"url":"https://api.github.com/repos/svinota/pyroute2/issues/279","repository_url":"https://api.github.com/repos/svinota/pyroute2","labels_url":"https://api.github.com/repos/svinota/pyroute2/issues/279/labels{/name}","comments_url":"https://api.github.com/repos/svinota/pyroute2/issues/279/comments","events_url":"https://api.github.com/repos/svinota/pyroute2/issues/279/events","html_url":"https://github.com/svinota/pyroute2/issues/279","id":173055363,"number":279,"title":"Commit does not update the IPDB cache","user":{"login":"Thoth19","id":6969212,"avatar_url":"https://avatars.githubusercontent.com/u/6969212?v=3","gravatar_id":"","url":"https://api.github.com/users/Thoth19","html_url":"https://github.com/Thoth19","followers_url":"https://api.github.com/users/Thoth19/followers","following_url":"https://api.github.com/users/Thoth19/following{/other_user}","gists_url":"https://api.github.com/users/Thoth19/gists{/gist_id}","starred_url":"https://api.github.com/users/Thoth19/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Thoth19/subscriptions","organizations_url":"https://api.github.com/users/Thoth19/orgs","repos_url":"https://api.github.com/users/Thoth19/repos","events_url":"https://api.github.com/users/Thoth19/events{/privacy}","received_events_url":"https://api.github.com/users/Thoth19/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/svinota/pyroute2/labels/question","name":"question","color":"cc317c"},{"url":"https://api.github.com/repos/svinota/pyroute2/labels/waiting%20for%20feedback","name":"waiting for feedback","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-08-24T20:52:48Z","updated_at":"2016-08-25T08:04:05Z","closed_at":null,"body":"Based on the http://docs.pyroute2.org/ipdb.html we note that \"So IPDB is updated asynchronously, but the commit() operation is synchronous.\"\r\nAs expected,\r\n```python3 \r\nimport pyroute2\r\nIFACE = pyroute2.IPDB()\r\nIFACE.interfaces.eth1.up()\r\n```\r\ndoes not do anything according to ifconfig eth1 and later running\r\n\r\n`IFACE.commit()` causes eth1 to come up.\r\n\r\nHowever, the following causes assertion errors:\r\n```python3\r\nfor i in range(100):                                                                                                       \r\n    print(i)\r\n    IFACE.interfaces.eth1.up()\r\n    IFACE.commit()\r\n    #1\r\n    assert IFACE.interfaces.eth1.operstate == 'UP'\r\n    IFACE.interfaces.eth1.down()\r\n    IFACE.commit()\r\n    #2\r\n    assert IFACE.interfaces.eth1.operstate == 'DOWN'\r\n```\r\nIf we add IFACE.interfaces.eth1.reload() at 1 and 2, the failures continue. It we add IFACE.initdb() at 1 and 2, the failures continue. If we try to rebuild the IFACE object with IFACE = pyroute2.IPDB() at 1 and 2 the failures continue. However, if we replace the asserts with \r\n`assert 'UP' in subprocess.check_output('ifconfig eth1')` and `assert 'UP' not in subprocess.check_output('ifconfig eth1')` the failures disappear. This implies that the changes are successfully sent to the kernel, but not being propagated back to the library's IPDB cache. This is corroborated by pausing using pdb and checking the output of `ifconfig eth1` and `IFACE.interfaces.eth1.operstate` until the later updated.\r\n\r\nIs there an intended workaround? We have been able to get away with using subprocess, but this seems like an unintended behavior. \r\n\r\n"},"comment":{"url":"https://api.github.com/repos/svinota/pyroute2/issues/comments/242310368","html_url":"https://github.com/svinota/pyroute2/issues/279#issuecomment-242310368","issue_url":"https://api.github.com/repos/svinota/pyroute2/issues/279","id":242310368,"user":{"login":"svinota","id":814602,"avatar_url":"https://avatars.githubusercontent.com/u/814602?v=3","gravatar_id":"","url":"https://api.github.com/users/svinota","html_url":"https://github.com/svinota","followers_url":"https://api.github.com/users/svinota/followers","following_url":"https://api.github.com/users/svinota/following{/other_user}","gists_url":"https://api.github.com/users/svinota/gists{/gist_id}","starred_url":"https://api.github.com/users/svinota/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/svinota/subscriptions","organizations_url":"https://api.github.com/users/svinota/orgs","repos_url":"https://api.github.com/users/svinota/repos","events_url":"https://api.github.com/users/svinota/events{/privacy}","received_events_url":"https://api.github.com/users/svinota/received_events","type":"User","site_admin":false},"created_at":"2016-08-25T08:04:05Z","updated_at":"2016-08-25T08:04:05Z","body":"> So does this mean that the standard ip commands are doing something strange to get the \"wrong,\" answer?\r\n\r\nNo, the `ip` command works in the very same way:\r\n```\r\n[root@localhost ~]# ip link show dev dummy0\r\n16: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000\r\n    link/ether 5e:cd:78:07:2f:18 brd ff:ff:ff:ff:ff:ff\r\n[root@localhost ~]# ip link set dev dummy0 up\r\n[root@localhost ~]# ip link show dev dummy0\r\n16: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\r\n    link/ether 5e:cd:78:07:2f:18 brd ff:ff:ff:ff:ff:ff\r\n```\r\n\r\nPls notice `BROADCAST,NOARP,UP,LOWER_UP` — **flags**; and `state UNKNOWN` — **operstate**\r\n\r\nThe `ifconfig` command also shows the **flags**, but not the **operstate**:\r\n```\r\n[root@localhost ~]# ifconfig dummy0\r\ndummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500\r\n        inet6 fe80::5ccd:78ff:fe07:2f18  prefixlen 64  scopeid 0x20<link>\r\n        ether 5e:cd:78:07:2f:18  txqueuelen 1000  (Ethernet)\r\n        RX packets 0  bytes 0 (0.0 B)\r\n        RX errors 0  dropped 0  overruns 0  frame 0\r\n        TX packets 6  bytes 420 (420.0 B)\r\n        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0\r\n```"}}
{"actor":{"display_login":"svinota"}}