search

SUSE / manager-build-profiles

Example profiles for building images and systems with SUSE Manager and Uyuni
15 stars 44 forks source link

Add profile for testsuite #7

Closed Bischoff closed 6 years ago

Bischoff commented 6 years ago

Add profile for testsuite, in Testsuite/ top-level directory.

aaannz commented 6 years ago

@joesusecom @abhinav-puri as PM what do you think about this? As this is customer facing github repository, should it also contain testsuite data with links to SUSE internal repositories? Other idea may be not to merge it to master but have i.e. devel/test branch where would be the same profiles at the same paths but with SUSE SLE repositories needed for successful build and useless to public.

PR itself is good and validated by a successful testsuite run.

Bischoff commented 6 years ago

As this is customer facing github repository, should it also contain testsuite data with links to SUSE internal repositories?

@joesusecom @abhinav-puri @aaannz these are precisely not "internal repositories" anymore, since we are opensourcing the test suite.

Otherwise I could stay in our gitlab internal project for profiles, and I would not need this pull request...

The point is precisely to make these resources public.

Ping @mc @dmaiocchi @mbologna and @juliogonzalez for third party advices.

aaannz commented 6 years ago

By internal repositories I mean for packages - e.g. http://euklid.nue.suse.com/mirror/SuSE/build.suse.de/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ and other.

Bischoff commented 6 years ago

By internal repositories I mean for packages - e.g. http://euklid.nue.suse.com/mirror/SuSE/build.suse.de/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ and other.

We consider that external people running the testsuite need have access to SLE products. This will be the case in other part of the testsuite too. Is there a problem with that?

Or we could use openSUSE Leap.

Bischoff commented 6 years ago

I had not the time to comment on the other half of Ondrej's message:

Other idea may be not to merge it to master but have i.e. devel/test branch where would be the same profiles at the same paths but with SUSE SLE repositories needed for successful build and useless to public.

I like the idea. We could call the new branch "testsuite":smiley: .

Well, I would prefer to use "master" branch for the sake of simplicity, but this would be an reasonable solution.

PR itself is good and validated by a successful testsuite run.

Thank you Ondrej for the nice words.

juliogonzalez commented 6 years ago

In theory having the URLs is not a problem, according to what was discussed by @moio and legal a long time ago (in fact we already have some repositories with such internal URLs, and there will be another one on Saturday, after we publish SUSE Manager HEAD code as Uyuni).

I don't have a special problem with having a directory Testsuite with the testsuite stuff, but if this repository is going to be linked at the SUSE Manager/Uyuni doc as a source for examples for customers (despite not supported), at least I will explain at the README what Testsuite is (and IMHO we should explain it for the other folders as well).

Bischoff commented 6 years ago

at least I will explain at the README what Testsuite is (and IMHO we should explain it for the other folders as well).

Already done, look at the README.md in this PR.

Bischoff commented 6 years ago

Done (better README)

mcalmer commented 6 years ago

AFAIK the Retail people needs to decide. If they are ok, we can do it.

aaannz commented 6 years ago

This is not only about Retail. This is about image templates basic sources and examples for customer as a whole. By basic source I mean something that can build an image as is and also customer can use to create their own custom image templates. So I guess that toplevel directory separation for Testsuite is fine, but because this being in documentation in a way "go there and pick something" I was quite hesitant. And that's why I also added @joesusecom and @abhinav-puri Quote from documentation:

SUSE provides examples of fully functional image sources at the SUSE/manager-build-profiles public GitHub repository.

E.g. when @cbosdo finishes virtualization support they may want their own KVM or XEN templates here as a basic sources for customers.

Bischoff commented 6 years ago

@aaannz If it still itches you to have this top-level directory in same branch (and apparently it does), I'm okay with your idea of a separate testsuite branch.

Please decide.

jsrain commented 6 years ago

@Bischoff @aaannz I can live with having internal URLs disclosed in the test suite as long as it is obvious enough that if anyone wants to run the test suite, he needs to change it. Not that I'm entirely happy of no separation, but we should not overcomplicate our lives.

Bischoff commented 6 years ago

@jsrain for the disclosure of internal URLs, as @juliogonzalez said it was asked to legal.

Since Uyuni itself will have public URLs, we should be able to switch relatively soon.

If not, we could use openSUSE URLs.

Please notice it's more general that this PR only, it goes beyond containers and OS images, it also concerns the server, the proxy and all the clients we test. Ping @moio for the consequences on sumaform.

moio commented 6 years ago

https://github.com/SUSE/spacewalk-testsuite-base has been on public GitHub since inception despite testing SUSE Manager only. There is no problem with that.

Internal infrastructure URLs are also not a problem.

I agree with the general view that we should keep our lives as simple as possible.

Thus, I expect testsuites to accompany their respective product versions their branches. So SUSE/spacewalk/Manager-3.0 should contain the 3.0 testsuite, SUSE/spacewalk/Manager-3.1 the 3.1 testsuite and SUSE/spacewalk/Manager-3.2 the 3.2 testsuite which includes Retail. uyuni-project/uyuni/master should contain the Uyuni testsuite, which is what we called the Manager testsuite until yesterday (next major version).

At this point, it does not really make sense to work on a Retail testsuite in uyuni-project/uyuni/master, so all work should happen in SUSE/spacewalk/Manager-3.2 unless I am missing something.

When work on a future Retail version based on the next major Manager version will start, there will be no other chance but to start working on uyuni-project/uyuni master. At that point all work on the 3.2 testsuite will have to be forward-ported, made public, and made optional (default disabled) to be nice with the community.

Bischoff commented 6 years ago

Thanks @moio for the idea.

I see both advantages and a drawback to this suggestion:

I think the advantages overcome the drawback. Would everyone agree with Silvio's solution? If yes, I close this PR and create the profiles in the testsuite itself.

@mcalmer : I would also do so for the container profiles (docker), I would move them from gitlab to the testsuite itself.

mbologna commented 6 years ago

I agree with having the testsuite profiles not in this PR but rather in the testsuite itself.

Bischoff commented 6 years ago

OK, creating a card to do it (under waterline) on next sprint. Closing here.