On 2/27/19 2:38 AM, Han Zhou wrote:
On Tue, Feb 26, 2019 at 1:13 PM Mark Michelson <[email protected]> wrote:
On 2/22/19 4:45 PM, Ben Pfaff wrote:
On Fri, Feb 22, 2019 at 04:15:27PM -0500, Mark Michelson wrote:
On 2/22/19 4:01 PM, Ben Pfaff wrote:
On Mon, Feb 18, 2019 at 09:50:56AM -0500, Mark Michelson wrote:
Hi everyone,
I have completed a *rough* POC of an OVN/OVS code split. You can find it at
https://github.com/putnopvut/ovn.git
Please take a look at the README file since that highlights how the split
was done, as well as some known issues.
My attitude towards this repo is that it is a throwaway prototype. It
essentially proves the concept that OVN can include OVS as a git subtree,
while not really attempting to do a production-ready job of
doing so. There is a lot of unfinished work.
It looks like the sort of thing I'd expect to see.
One thing I don't expect to see for a first cut or an nth cut is
perfection. Stuff in corner cases is going to be broken. That's the
nature of big changes. We'll fix them as we notice them.
The manpages.mk errors are from the rule in the Makefile that tries to
rebuild manpages.mk. That's why touching it helps, since it keeps the
Makefile from trying to rebuild it.
What do you think is your next step?
Hi Ben,
Thanks for the reply. My current step is to get buy-in for this approach. If
people have suggestions for improvement or outright disapproval (with
logical reasoning of course), then I'll iterate and try to take those
suggestions into consideration.
If people are 100% cool with the approach I've taken, then the next step
will be to come up with a plan to officially split the OVN code out from
OVS. It'll need a plan for a few reasons:
1) We'll need to get an official OVN repo to perform the work in.
That is easy. I (or any other OVS committer) can create one under the
openvswitch organization on github. I'm happy to do so whenever you
like, even now.
There's also the "ovn-org". Justin is the sole owner of that org
currently. I guess he'll probably add more people.
(It's easy to transfer repos between orgs, so no worries about that.)
2) We'll essentially need to have a "freeze" on OVN development during the
split. Otherwise, changes that occur between the start of the split and the
completion of the split could get lost. Or it will require some porting of
the changes between repos. Either way, not a fun task.
Good point.
3) We'll want to have testing plans in place. Tests will need to be focused
on ensuring that OVN works with compatible versions of OVS. Compatibility is
something that we've avoided trying to make official stances on, but that
could be a sub-item to perform here as well.
Do you plan to make a proposal here?
I'm hesitant to for a couple of reasons. One is that I've worked with
enough software to know that guarantees *will* be broken. For instance,
we might attempt a policy like "we will guarantee that the current
version of OVN will work with the current version of OVS as well as the
previous minor version". But things like security issues and other
critical fixes could result in that guarantee being broken.
Also, it's very possible that new features introduced in OVN mean that
it is "compatible" with the previous version of OVS but runs in a
crippled capacity due to missing requirements in OVS.
I think the appropriate policy here would be a best-effort to maintain
compatibility with the current version of OVS as well as the previous
minor version. Compatibility with any older versions of OVS cannot be
guaranteed. Any exceptions to the best-effort approach will be
documented in some file in the OVN repo.
Are you more concerned about OVN or OVS for testing? It's easy for OVN
to accidentally add a dependency on some later-than-intended version of
OVS or OVSDB (although maybe just testing with the intended version
helps?) but it's also easy for OVS to accidentally make some change that
breaks OVN.
I think I'm more concerned about OVS. OVN developers will be well aware
of the changes that they are making in both repos. OVS developers have
the potential to introduce changes that compile in OVS but cause
breakage in OVN. It's an understandable problem since some OVS
developers may not even be aware that OVN depends on OVS.
CI can be used to ensure that OVN compiles against supported versions of
OVS and that tests still pass. This way, OVN devs can be notified if
there's a new breakage in OVN and fix it as soon as possible.
4) We'll want to be sure we're all on the same page regarding when the OVN
split occurs. Will we do it at the same point that OVS 2.12 is being
released, or will we do it as soon as possible and have OVN start its own
versioning independent of OVS immediately?
Is there any advantage to waiting, once we're ready?
If OVN is versioned independently from OVS, then there's no real reason
to wait for an OVS release. We can do it whenever we're ready.
This might be a good time to increment the OVS major number to 3.0.
Once all of the above are determined, then I think it's a matter of
essentially re-doing what I've done already, but in a more official capacity
(i.e. using an official repo, making more coherent commits, ensuring builds
work across platforms). Once there is a functioning repo in which work can
be done, we can work on the finer details (i.e. removing additional
irrelevant files, reworking documentation). And once all of that is done,
then I think the administrative details can become important (i.e.
determining committers, updating websites, mailing lists, etc.)
Oh my, it'll take a long time to get that right.
I wonder whether OVN should adopt a more "modern" workflow, such as
Github pull requests instead of emails.
I'd certainly be OK with that. The main advantage I see of a more
"modern" workflow is the ability to gate merges based on things like CI
passes.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
I agree with the approach. I just want to add that there are some
reverse dependencies from OVS to OVN, probably only in tests. At least
one example is that ovsdb-cluster.at uses ovn to do tests. It can be
solved with some changes, but it is definitely some work there.
Thanks for pointing this out. It makes sense that the tests use OVN
since ovsdb clustering is targeted at OVN's use.
Apart from this, I have just some trival problem/questions. I went
ahead to clone the repo and try to play with it to get some real
feelings. However, I encountered an error when doing make:
make[4]: *** No rule to make target 'lib/dhparams.c', needed by
'lib/dhparams.lo'. Stop.
This is a problem that Numan ran into as well when he tested it out. I
haven't seen it on my setup so it's been difficult to tell what's going
on. I'll talk about this a bit more below.
This same error occurred when I tried to make in the ovs sub directory.
This is because the error is happening when the ovs Makefile is invoked.
The ovn Makefile.am has "SUBDIRS = ovs" in it, so it calls into the ovs
Makefile as part of the build process.
Another question is regarding git subtree. I didn't see the ovs sub
directory as a git subtree in your repo. I am not familiar with git
subtree, but it seems the ovs sub directory is included directly in
the repo? Or how can I confirm it is a subtree instead of a part of
the ovn repo?
This is one of the ways that git subtrees differ from git submodules.
git submodules are essentially "links" to a remote repo, whereas
subtrees are essentially copies of a separate repo. With subtrees there
is no git metadata that indicates that the subdirectory comes from a
remote repo. There is no way to tell from inspection alone that the ovs/
subdirectory is a subtree. It must be documented as part of the
project's policy.
In addition, I noticed that the changes are based on an old version in
Apr 2018. I wonder why not starting with the latest master, but maybe
that doesn't matter too much for a POC.
Yes, this was a mistake on my part. I decided to use a personal clone of
ovs as the basis for the split. I did not realize that I had not rebased
against upstream master and went forth with the split using the old code.
I did not realize I was using such an old version until Numan reported
having an issue with the dhparams.c file. It was then that I realized
how out of date the POC was. Unfortunately, just updating the ovs/
subtree wouldn't be enough, because the top-level ovn files were also
horribly out of date. In order to update properly, I'd need to redo the
split from scratch using an up-to-date version of ovs. Having done the
split once, it probably wouldn't take too long to get it completed if I
had to do it over again, but I figured I could get some early opinions
on the matter even if it's an old version and not in the greatest shape.
Given that I've now had multiple reports of the build being a problem
due to the dhparams.c error, it is probably worth my while to re-do the
split on a newer version of ovs master. For one thing, it would be a
good indicator of how long the split would take when we do it for real.
Thanks,
Han
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
