Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Akihiro Suda
@AkihiroSuda
日本語テスト japanese text test
Hitoshi Mitake
@mitake
from android
Akihiro Suda
@AkihiroSuda
We've just released Namazu v0.2.0: http://osrg.github.io/namazu/post/release-0-2-0/
Please feel free to talk to us, if someone is watching this (inactive :worried: ) gitter!
v01dstar
@v01dstar
Hi I am Yang Zhang from PingCAP. We are developing a automated tests now. After reading your example (example/zk-found-2212.ryu), I have several questions to ask.
  1. My understanding of your example: You have a testing environment(docker run osrg/namazu) let's name it as container-nmz. Then you create a zookeeper cluster (czk1, czk2, czk3) in this container(docker-in-docker). You hook all network traffic that go through container-nmz (through hookswitch, your python inspector and nmz REST API), so that all packets between czk1, czk2, czk3 will be filtered because they are in this container. Then nmz will decide whether a pakcet will be dropped according to the policy and delivery this action to your python inspector then to hookswitch, ask hookswitch to execute this action. Is my understanding right?
  2. I notice that you didn't assign FaultActionProbability in config.toml. Which means that actually there is no packet being dropped (also can be observed by inspector.log). So how this bug being found? Is this related to the interval?
    I had a quick view of your doc and code, so probably miss some points. If so, sorry about that.
v01dstar
@v01dstar
@mitake @AkihiroSuda
Akihiro Suda
@AkihiroSuda
Hello! :smiley:
v01dstar
@v01dstar
Hi!
Akihiro Suda
@AkihiroSuda
For ZOOKEEPER-2212, we did not drop any packet
The issue is just related to the ordering of packet
v01dstar
@v01dstar
ok, i see
Akihiro Suda
@AkihiroSuda
ZooKeeper has two types of packets for its ensemble: ZAB and FLE
ZAB uses tcp 2888 and FLE uses tcp 3888, so it is non-deterministic you receive ZAB then FLE, or FLE then ZAB
v01dstar
@v01dstar
ok
What about the system hook part
Akihiro Suda
@AkihiroSuda
So for question 1,
v01dstar
@v01dstar
yep?
Akihiro Suda
@AkihiroSuda
The answer is basically yes, but nmz decides the ordering of packet rather than dropping it
v01dstar
@v01dstar
ok, thank you
Akihiro Suda
@AkihiroSuda
For question 2, yes to "Is this related to the interval?"
v01dstar
@v01dstar
but here is a problem. If we build a huge cluster
For example tons of docker container
Akihiro Suda
@AkihiroSuda
Yes, nmz does not scale for large cluster
v01dstar
@v01dstar
ok
Akihiro Suda
@AkihiroSuda
But scalability is not a problem when you use randomized policy
v01dstar
@v01dstar
yes
Akihiro Suda
@AkihiroSuda
because you can launch randomized nmz for each of the node, so there is no interaction between nmz nodes
v01dstar
@v01dstar
cool, that's the next question i want to ask
haha
thanks a lot
Akihiro Suda
@AkihiroSuda
Thank you a lot for looking into our work :smile:
v01dstar
@v01dstar
your project is super cool by the way
Hitoshi Mitake
@mitake
@v01dstar thanks for your interest :)
Akihiro Suda
@AkihiroSuda
也TiDB和TiKV 超酷 :cool:
v01dstar
@v01dstar
haha
thank you
Akihiro Suda
@AkihiroSuda
Please feel free to give us your feedback if you have any further questions and suggestions
v01dstar
@v01dstar
sure
Akihiro Suda
@AkihiroSuda
thanks!
v01dstar
@v01dstar
:smile:
v01dstar
@v01dstar

I found that nmz "container mode" is a very convenient tool to use, it can be easily integrated with CI.
For example:

nmz container run TiKV --name kv1 
nmz container run TiKV --name kv2
nmz container run TiKV --name kv3
nmz container run TiDB

But I also found that nmz doesn't support some docker args like -p. Is there any specific reason for doing this?

v01dstar
@v01dstar
@AkihiroSuda @mitake
Akihiro Suda
@AkihiroSuda
Thank you for trying the container mode
Actually there is no specific reason
Currently, nmz parses CLI flag strings by itself rather than passing them to the docker command
And nmz calls github.com/fsouza/go-dockerclient.CreateContainerOptions() for creating container https://github.com/osrg/namazu/blob/master/nmz/cli/container/run/runflag.go
Due to this implementation approach, currently nmz supports only limited numbers of docker run flags
I'm planning to use os/exec for calling the docker rather than the current approach
Akihiro Suda
@AkihiroSuda
So the current workaround is to use docker run --privileged -p ... instead of nmz container run,
and use nmz inspectors proc or nmz inspectors ethernet within the privileged docker containers