[389-devel] Please review: 49348 and 88
Hi, While at pyconau I was very quiet - because I was working toward a major goal that I have had for a while. This patch allows a perl-less install of the 389-ds server: https://pagure.io/389-ds-base/issue/49348 https://pagure.io/389-ds-base/issue/raw/files/fe5ffea4d8cbcd9f0a806aecf39d523684ecefe5660760b152370a949d61de4a-0001-Ticket-49348-support-perlless-and-wrapperless-instal.patch This ticket provides the enablement for lib389 to support testing our server with no perl - ie we can create and remove instances with pure python 3 tools. https://pagure.io/lib389/issue/88 https://pagure.io/lib389/issue/raw/files/a1201152a0861b50098aa7f84c83e7bc201334332d5fc42ca75319b96883164e-0001-Ticket-88-python-install-and-remove-for-tests.patch This is a really exciting milestone for us for our new administrative toolkit in python, and is a major stepping stone to deprecating and removing perl from our codebase. This will make platform ports significantly easier as we will no longer rely on the perl-mozldap components. Thanks, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: future of lib389 - seperate or merged?
> > > > -- Merging lib389 to 389-ds-base > > ... > > * Testing DS is guaranteed to work. Right now we have rapid change in > > lib389 and the tests in say 1.3.5 or 1.2.11.x are unlikely to work with > > latest lib389. > Another problem here is that tests are not backported to the older > branches. The only true source of tests is master branch that is > guaranteed to work with the latest lib389. But the issue here is we don't always mark them with versions properly... > > * 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? 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. 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. > > * 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. > > > > 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. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: [PATCH] Allow to override build date
On Tue, 2017-08-08 at 08:00 +0200, Bernhard M. Wiedemann wrote:
> in order to make builds reproducible.
> See https://reproducible-builds.org/ for why this is good
> and https://reproducible-builds.org/specs/source-date-epoch/
> for the definition of this variable.
> ---
> buildnum.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/buildnum.pl b/buildnum.pl
> index 6d8804f..8db83da 100755
> --- a/buildnum.pl
> +++ b/buildnum.pl
> @@ -31,7 +31,7 @@ if ($opt_H) {exitHelp();}
> $platdir = $opt_p;
>
> # Get current time
> -@now = gmtime;
> +@now = gmtime($ENV{SOURCE_DATE_EPOCH} || time);
>
> # Format buildnum as .DDD.HHMM
> $year = $now[5] + 1900;
> --
> 2.12.3
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Please see https://pagure.io/389-ds-base/issue/49347
Where I have merged this commit. Thanks for your contribution!
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] please review: Ticket 87 - lib389 - Update access log regex patterns for HR etimes
https://pagure.io/lib389/issue/87 https://pagure.io/lib389/issue/raw/files/9d484648d1fd332992c9404869d5b34b57688775c2a2f0223da0dda4ea67a401-0001-Ticket-87-Update-accesslog-regec-for-HR-etimes.patch ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review 48081: CI test - password :: regression tests
https://pagure.io/389-ds-base/issue/48081 https://pagure.io/389-ds-base/issue/raw/files/2411b2d29d9ffe07a512347365b1085f8743634aa431a8fb663a3151a7429dae-0001-CI-tests-PasswordCheckSyntax.patch ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: future of lib389 - seperate or merged?
On Tue, Aug 01, 2017 at 04:00:23PM +1000, William Brown wrote: > 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. > > 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. > > For example, this would make the CI workflow much simpler as we just get > "389-ds-base" and it's a self contained test suite and admin system. No > need to get the "matching pairs" as the separate workflow would require. > I agree. I vote for merging too. Also, besides all stuff you and Viktor have mentioned, while developing something for lib389 (some new feature or fixing the old code) I feel a natural need to fix 389-ds-base according to my changes. Thank you for bringing up the topic! :) And for all the info you've structured. Simon > > Thanks, I look forward to the discussion and various inputs to the this > topic. > > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org signature.asc Description: PGP signature ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: future of lib389 - seperate or merged?
Hi William, On Tue, Aug 01 2017 at 16:00:23 +1000, William Brown wrote: > Hi all, > > Last night on IRC we were discussing the curious case of lib389. I think > this is a discussion we should have at some point. > > The question really boils down to - "is lib389 a seperate project? Or is > it part of 389-ds-base?" > > There are some pros and cons to both view points. > > lib389 is a python library that exposes high level interactions with 389 > directory server. This is done by making various calls via LDAP to the > server. > > The issue is that we have a split: we have tests in > 389-ds-base/dirsrvtests that are often *version* dependent. They relate > to features of the server, or issues in specific versions of the server > that may not exist in older versions. Today we kind of stradle the line > of "it's a bit of both". We have tests in 389-ds-base that depend on > versions of lib389 - but lib389 moves quickly and has little ability to > distinguish 389-ds-base versions. I don't think that we will avoid version dependency completely. These days we mark tests that can't be executed on the older versions of DS with skipif fixture as we run tests from master branch. > > -- Merging lib389 to 389-ds-base > > One proposal is to merge them. We would mix in lib389 and the > dirsrvtests into lib389 tests. It is often the case that lib389's > features are bound tightly to a version of directory server. > > Pros: > * No need to separate version lib389 to ds. lib389 is guaranteed to work > with *that* version of DS > * Testing DS is guaranteed to work. Right now we have rapid change in > lib389 and the tests in say 1.3.5 or 1.2.11.x are unlikely to work with > latest lib389. Another problem here is that tests are not backported to the older branches. The only true source of tests is master branch that is guaranteed to work with the latest 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? > * 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? > > 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. > > 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? > > For example, this would make the CI workflow much simpler as we just get > "389-ds-base" and it's
[389-devel] Please review 48081: CI test - password - regression tests
https://pagure.io/389-ds-base/issue/48081 https://pagure.io/389-ds-base/issue/raw/files/f42429499528aa390d9bbaa02ed82eae90e693866a6456beaa04b4cd0eb9911c-0001-CI-tests-PasswordCheckSyntax.patch ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Please review: issue 77, issue 79, issue 83
Hi team, please, check out the issues. They were updated recently (or just waiting for the review): https://pagure.io/lib389/issue/77 https://pagure.io/lib389/issue/raw/files/6047ac156e06192837271afc2770a83f7f3206400669537bb1d8f43ab7b9a434-Guidelines-for-using-pytest-and-lib389_47541162.html https://pagure.io/lib389/issue/79 https://pagure.io/lib389/issue/raw/files/7be353523a4a7ad8382a9a98ad778819f5e7557ab1812b9d1e595499ef821244-0001-Issue-79-Fix-replica.py-and-add-tests.patch https://pagure.io/lib389/issue/83 https://pagure.io/lib389/issue/raw/files/57003067766f1a08da96060e1d51e95583cc5a43ef98d73991fb2576a50501ce-0001-Issue-83-Add-an-util-for-generating-instance-paramet.patch Thanks, Simon signature.asc Description: PGP signature ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
