> > But the issue here is we don't always mark them with versions > > properly... > I see that there is a room for improvement for our review process :) For certain, even I'm guilty of this (and I'd like to think I'm fairly well acquainted with lib389 ;) ) > > > >> > * We can tightly tie in features of DS with lib389 and their > >> > administration (ie no need to worry about backward compatibility). > >> > * Simpler release process - we only need to release 389-ds-base, and we > >> > are done. > >> > * No more split patches for lib389 features and tests. > >> > > >> > Cons: > >> > * We will need to backport lib389 features to backport tests for fixes > >> > to older versions. > >> > * Inability for latest lib389 to manage older (or newer) versions of ds. > >> > > >> > -- Separate lib389 > >> > > >> > We have lib389 as a project that moves at a different rate to the > >> > 389-ds-base project. > >> > > >> > Pros: > >> > * lib389 is able to use it's "knowledge" to administer *multiple* > >> > versions of Directory Server, rather that singly linked ones. > >> > * We can write tests into lib389 once and test them against all DS > >> > versions, or just relevant versions. > >> > * We can have the admin tools manage many versions of the software which > >> > may be cross platform/distro. > >> Why these 3 points can't be done in merged lib389 using version specific > >> logic in lib389 and the tests? > > > > This is also true. But once we merge, is there much need? > Yes, there is a need for downstream, especially in the late release > phase, when we can't add new fixes (with tests) in the builds (unless > really urgent issues), but we need to continue testing. > > We only need the connected test set. Issues we find in version 1.3.7 > > are unlikely to be backported as fixes to 1.3.6 so the test cases > > aren't relevant here IMO. > Not always, regression bugs and security issues are fixed in multiple > branches, but usually only DS code is cherry picked, but not tests > (because we have different dir structure, changes in boilerplate code, > etc). But if we have the fix and the test in one patch, and they are in the same repo, any lib389 enablement code can we backported in "one shot" here too. > > My thinking is rather than have many cases/switches for all our > > lib389 to ds versions (which means we need to define a support policy), > > we can have a simpler 1:1 mapping. Makes the code easier for us, and > > given that most distributors will ship these together, makes that job > > easier too. > I see that we have different approaches to running tests. Let me explain > how we're doing it. We have downstream acceptance tests, that live in > git where each branch corresponds to Y-release of RHEL, e.g. RHEL69, > RHEL73, etc. Over time tests evolved to the point where backporting > something from RHEL7x branch to RHEL6x is a real pain. Master branch was > used for testing Fedora releases, but many times there was a situation, > when tests worked differently because of the change in DS that was on > Fedora N release, but not in N-1, so running tests from master was kinda > pointless. Also old framework doesn't support skipping tests out of the > box. So when upstream tests started to be using py.test, that was a > relief, because py.test has many great features like fixtures and marks. > For us logical way was to run upstream tests from master branch on all > versions of DS, but separating what can be run in the test/framework > logic itself, rather than using VCS branching. Think of it like of a > rolling release. With this approach we're not tied to RHEL schedules, > because we can always merge a test in master branch. And the same code > works across all DS versions unless version specific tests are used. > > I agree, that merging lib389 to 389-ds-base should guarantee that tests > from the same revision work. Yep. I think that we should be looking at the rolling release model really here, and we should be using these marking features. Today though, we are not in that position, but this merge, and some dedication, I think we could get there. Especially if we want to clean our test structures from the ticketXXXXX to actually sorting them correctly to suites. Really, I think that we just need to be willing to make some sweeping changes in this space, and merging is step 1 to that, because I think that this would really help us when we go to run CI, and for you with the downstream acceptance suites. > > > > >> > * No more split patches for lib389 features and tests. > >> > > >> > Cons: > >> > * Need to invest time into version detection of the 389-ds-base package > >> > for configuration (both local and remote). IE we add a plugin in 1.3.7, > >> > but we need to know if lib389 is accessing 1.3.6 (and disallow the > >> > change). > >> I think of this as not a con, but a feature. Also adding more sanity > >> checks would be good. Our tools should be fool-proof. > >> > * Continue to manage separate release of software. > >> > * Need to manage lib389's older versions operating against *newer* > >> > 389-ds-base versions. This adds a lot of complexity and version checks > >> > (potentially with some server awareness?) > >> > > >> > -- Do nothing > >> > > >> > This is the current status. > >> I thought that separate lib389 is a current status, no? > > > > Yes, but this means we leave it seperate, and continue as is. The others > > propose moving the test suites *from* 389-ds-base/dirsrvtests to lib389, > > *OR* merging lib389 to 389-ds-base. > Moving 389-ds-base/dirsrvtests is a no-go IMHO, especially if we want to > gate changes when tests do not pass. Code and tests should live together. Yep - thus why I'm on the "merging" side of this argument. I think there is no reason to seperate our test cases in DS from the framework that runs them - especially if we keep changing the framework, we need to keep dirsrvtests in sync. If we have to lock-step them, then again, justification to merge. > > > >> > > >> > Pros: > >> > * We don't spend any time on the issue at all. > >> > > >> > Cons: > >> > * We get the worst of both worlds. > >> > * Continue to increase complexity as these diverge. > >> > * we often see the need to expand lib389 to express a test in > >> > 389-ds-base, so we will continue to need to split patches > >> > > >> > > >> > ============================ > >> > > >> > My vote is to merge them. I came to this decision because I believe that > >> > this will make development against multiple branches easier with regard > >> > to testing and backport of patches. For example, we'll know that lib389 > >> > that's inside of 1.3.7 will *always* work with that release, even if we > >> > have improved in 1.4.x etc. > >> My vote is to merge them as well. But for slightly different reasons: > >> packaging (blocking dependencies are not fun), single place of > >> development. > > > > Cool! That's 2 for merge so far :) > > > >> > > >> > We also are developing new CLI and admin tools, and these are often > >> > tightly linked to a version of Directory Server. I think that it's > >> > easier for us as developers to have this specific linking, than trying > >> > to spend large amounts of time making something generic that works for > >> > all versions. > >> What about migration scenario, when you have a mix of old and new > >> versions of DS, and latest tools should be able to handle them? > > > > You would use the tools on the local host to manage it I would think. > > Just the same today with the pl tools. > I was thinking about new admin server capabilities, similar to what we > have currently with 389-admin and 389-console, where console from one > machine can control other versions of DS. Yep. I was coming at this from the angle of "you should only manage the instance with the tools on the same server". If we push for a seperate admin server, I think that would use mark's DMC design (which is easily a year or more away). So today, I think saying the admin tools have to be the ones on the server is fine, and when we go to DMC, we need the version logic there - and that's a whole different set of challenges in itself for us to work out. It saves me in engineering the extra work of api compat over versions, because let's face it, we have X hours in a day, and I need to spend them on things that are not "how can I maek this work with old version X". As well, that would make CI more difficult perhaps, because we would need to CI lib389+ds of version X, and then test them with version X minus N that we decide to keep compat for (or X plus N for forward admin). Both of which are a harder task to achieve, and I don't want to invest in. We have bigger issues to deal with IMO. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
