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. 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 same error occurred when I tried to make in the ovs sub directory. 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? 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. Thanks, Han _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
