Closed keichwa closed 4 years ago
I provided a dedicated file for Uyuni and put the ifdefs into the nav file.
I think the SCC section will work with Uyuni, too. (I'm not sure whether we want this info here, though). Edit: I see that Julio already said: "This part is optional in Uyuni." @juliogonzalez would it be sufficieant if I'd provide a note at the beginning of this section where I say this?
On 2019-11-11 17:40, Julio González Gil wrote:
+== Set up {productname} with {yast}
This is incomplete. It's not explained to the user how to get the packages installed first :-)
For stable: https://www.uyuni-project.org/pages/stable-version.html For master: https://www.uyuni-project.org/pages/devel-version.html
Yes, but this has to be part of the install file. Similar to install-vm.adoc, I think.
It's basically the same procedure with different repositories, but I am not sure you you want to handle when to show stable and when master. Maybe it's something to be discussed with @jcayouette
In the product documentation the main focus is stable.
+== Synchronizing Products from {scc}
We need to clearly state that this optional.
ok, will do it.
-- Karl Eichwalder
If you do not veto, I'll also back-port it to manager-4.0
I please want another review. @Loquacity @juliogonzalez . All suggestions are in, and additional small changes.
Some comments. Also, when everything is fixed and ready for review, can you generate the PDF and uploaded it, so I can review a rendered doc?
All feedback is now either in or answered. Here is the PDF! @juliogonzalez uyuni_installation_guide.pdf
It looks like some things were resolved but the changes aren't in (like the parentheses in the table). Also, reviewing the PDF made me realise that we have requirements in the installing section, when they should be in the requirements section. I think this needs more thought from a structure perspective.
Lana Brindley notifications@github.com writes:
It looks like some things were resolved but the changes aren't in (like the parentheses in the table).
It wasn't that clear to me whether Julio also wanted content changes. Now I reworked the table along the one we have for SUMA. (BTW, morphing these into variable lists would also be an improvement.)
Also, reviewing the PDF made me realise that we have requirements in the installing section, when they should be in the requirements section.
Ok, I'll create a separate file. (BTW2, I'm still not convinced that all these small files are easy to maintain.)
-- Karl Eichwalder SUSE Software Solutions Germany GmbH PES / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany Geschäftsführer: Felix Imendörffer (HRB 36809, AG Nürnberg)
@juliogonzalez we have a fresh PDF: uyuni_installation_guide.pdf
Lana Brindley notifications@github.com writes:
Also, reviewing the PDF made me realise that we have requirements in the installing section, when they should be in the requirements section.
Ok, done. The ports list is too long. I'd move it to the end of the book, as an appendix.
I think this needs more thought from a structure perspective.
ATM, the actual server installation starts at page 18 (of 36). That's much too late.
-- Karl Eichwalder SUSE Software Solutions Germany GmbH PES / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany Geschäftsführer: Felix Imendörffer (HRB 36809, AG Nürnberg)
This might be a dramatic call, but I've been staring at this for an hour now, and maybe we should go ahead and split this into two: one for SUMA, one for Uyuni? It might make @jcayouette 's job with the repo slightly easier too. After all, the Install Guide is where the majority of the differences are. Thoughts?
Lana Brindley notifications@github.com writes:
This might be a dramatic call, but I've been staring at this for an hour now, and maybe we should go ahead and split this into two: one for SUMA, one for Uyuni?
I'm not exactly sure what you want to split ;) This PR, or the whole Install Guide? For Uyuni and SUMA I already created dedicated files (and they are ifdef'ed in the nav file).
Nevertheless, we'll need all these changes in the 4.0.x maintenance and the devel branch (= master = 4.1).
And we should merge this ASAP ;-)
It might make @jcayouette 's job with the repo slightly easier too.
I do not think so. He just must talk to Julio and the developers and understand their branching model. This branching model will then become our, too. It's easy, just follow their rules.
After all, the Install Guide is where the majority of the differences are. Thoughts?
Depends on your POV.
-- Karl Eichwalder SUSE Software Solutions Germany GmbH PES / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany Geschäftsführer: Felix Imendörffer (HRB 36809, AG Nürnberg)
Still one missing thing, it seems.
I forgot to push this one: https://github.com/SUSE/doc-susemanager/pull/880/commits/80455c6642f4e216cdf815703163569b64568edd
Lana Brindley notifications@github.com writes: This might be a dramatic call, but I've been staring at this for an hour now, and maybe we should go ahead and split this into two: one for SUMA, one for Uyuni? I'm not exactly sure what you want to split ;) This PR, or the whole Install Guide?
I mean the whole guide.
For Uyuni and SUMA I already created dedicated files (and they are ifdef'ed in the nav file). Nevertheless, we'll need all these changes in the 4.0.x maintenance and the devel branch (= master = 4.1). And we should merge this ASAP ;-)
Agreed. It doesn't need to be in this PR.
It might make @jcayouette 's job with the repo slightly easier too. I do not think so. He just must talk to Julio and the developers and understand their branching model. This branching model will then become our, too. It's easy, just follow their rules.
I agree, but we need to wait for him to understand the problem first.
After all, the Install Guide is where the majority of the differences are. Thoughts? Depends on your POV.
Doesn't everything? :wink:
Lana Brindley notifications@github.com writes:
I mean the whole guide.
Ok, I created https://github.com/SUSE/spacewalk/issues/10178
Agreed. It doesn't need to be in this PR.
Ok, then please approve (once again ;) ).
I agree, but we need to wait for him to understand the problem first.
Yes, and now I stop discussing these issues (branching, changelog, xref'ing).
After all, the Install Guide is where the majority of the differences are. Thoughts? Depends on your POV.
Doesn't everything? :wink:
What I mean here is: Do we want to discuss or describe Uyuni from the pure community POV: Managing Leap, Debian, and similar installations with Uyuni.
Or is "Managing SLE with Uyuni" also an iusse? Then it is not that bad if we'd talk about mirroring credentials, registration codes, and all that.
-- Karl Eichwalder SUSE Software Solutions Germany GmbH PES / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany Geschäftsführer: Felix Imendörffer (HRB 36809, AG Nürnberg)
What I mean here is: Do we want to discuss or describe Uyuni from the pure community POV: Managing Leap, Debian, and similar installations with Uyuni. Or is "Managing SLE with Uyuni" also an iusse? Then it is not that bad if we'd talk about mirroring credentials, registration codes, and all that.
I think if we're going to have a separate doc for Uyuni, then yes, we should take it from the community POV. I would stick to just installation, though. We can split the Client Guide next.
close https://github.com/uyuni-project/uyuni/issues/1559