Todd: doc to specify Kab CLI service metadata in kabanero operator yaml about docs HOT 27 CLOSED

@davco01a Is there an update to the docs required for this? The referring issues says : This needs to be reevaluated after discussion with the originating requestor and is in Closed status. Can this issue also be closed?

from docs.

@bschrammIBM Yes, we will need doc, I am in the process of writing up doc at this wiki right now:

https://github.com/kabanero-io/kabanero-operator/wiki/Todd's-input-for-the-Kabanero-operator

from docs.

Should this be in a readme? Is it part of installation and configuration?

from docs.

@bschrammIBM recommends we add a step to:

https://kabanero.io/docs/#scripted-kabanero-foundation-setup.html

to configure the Kabanero document

from docs.

• Specify repository URL in the Kabanero document (object) to point to cloned, customized index.yaml for the master collection
• In kabanero crd specify:
  • git group or organization in the organization field
  • git team name(s) in the teams field
  • the api github url in the apiurl field. ( env variable: github.api.url )
  • the kabanero namespace(s) in the namespaces field

@tim.kaczynski is this only one single CRD for the Kab operator to get updated?

from docs.

@davco01a You modify the CR instance of the Kabanero CRD. So if the user created one Kabanero instance then that's the one that they'd modified. Today, we only support one instance, in the Kabanero namespace, so that's the one they'd modify. And most of the fields you're referring to there are not merged yet (see PR kabanero-io/kabanero-operator#170)

from docs.

Ok, I want to to net out which fields Todd needs to focus on for modification and document those.

from docs.

@davco01a @kaczyns
Can you provide a better title for this?
Is it 'Configuring OpenShift to recognize the Kabanero namespace'

from docs.

@kaczyns Do you have any recommendation of what we should call deonfiguring the Kabanero CRD?

Perhaps just: Configuring the Kabanero Custom Resource Definition

from docs.

@davco01a @bschrammIBM I'm sorry, I'm a little lost.

The install script that was mentioned earlier in https://kabanero.io/docs/#scripted-kabanero-foundation-setup.html:
openshift_master_default_subdomain=my.openshift.master.default.subdomain ./install-kabanero-foundation.sh

it already installs an instance of the Kabanero object. There are no modifications that anyone would need to make at this point.

It's not until Champ clones the collections, and makes changes, that Todd would need to either go back to the Kabanero document that was created in the install script, and change it, or just delete it and make a new one.

So, I don't think the install script page is where we should be talking about modifying the Kabanero document.

When we get there, I think it should be called "Configuring the Kabanero CR instance to point at the curated collections" or something like that. And it should describe where the collection URL needs to be set, where the Github organization/team/apiUrl needs to be set.

from docs.

@kaczyns +1

from docs.

@davco01a @kaczyns @bschrammIBM Looks like the best place for this is https://github.com/kabanero-io/docs/blob/master/ref/general/collection-building.adoc -- could you recommend where the new content would go in the workflow on that page?

from docs.

I thought @kaczyns gave recommendations on reordering the content of this page and placing the Kab document updates accordingly, but I don't see those changes reflected yet

from docs.

We had been working thru this page:
https://github.com/kabanero-io/docs/blob/master/ref/general/collection-building.adoc

One way we could slice this... is to insert steps between step 1 and 2. Basically:
1a) Create the initial tagged release of the cloned collections (v1)
1b) Create any org-level teams that should administer the cloned collection and add members to those teams.
1c) Alter the Kabanero document to point to that named release (v1) and add the Github: section pointing to the github org, team(s), and api url

then continue on.... but when we get to step 7 we have to figure out what to do because you can't test the changes until you've pushed them back to your remote (cloned) github repository

I think move 7 to after 9. So 7 would be push back, 8 would be make a release (not final version), and 9 would be test by altering the Kabanero document to point to the release. if errors are found iterate back and update the release. Then 10 would be to declare the release final.
I think that just editing step 1 addresses this issue.

from docs.

There is a pull request with the discussed changes waiting for review:
#91

from docs.

@jantley-ibm added some comments to your PR

from docs.

@jantley-ibm - Does the issue contain what is needed for the ID team to provide the 'ID-reviewed' label?

from docs.

At this point in time we are really working off of:

https://github.com/kabanero-io/docs/blob/master/ref/general/collection-building.adoc

from docs.

I also have this issue open to retitle this document:

#119

from docs.

Additionally:

Bullet one of Step 3 needs some rework -

Specify the repository URL in the Kabanero document (object) to point to a cloned, customized index.yaml for the master collection. The URL setting is in the Spec.Collections.Repositories section of the Kabanero Custom Resource (CR) instance. You can either alter the Kabanero CR instance that already exists, or delete it and create a new one.

master collection should be curated collection

from docs.

Also some mention of step 3 about how to edit the Kabanero document would be help, e.g. oc edit or how to navigate to the CR from within the OKD console

@mtamboli ^^

from docs.

@mtamboli - From SVT perspective, do you have what you need?
@davco01a and @kaczyns - Since ID work @jantley-ibm is complete, is the issue ready to close?

from docs.

@davco01a I think your comments are addressed in PR #127 . Could you please review that?

from docs.

I'm currently writing a guide on "Working with Collections" (Champ - #55), which covers cloning the public collections to a local Git org/repo, understanding the content/structure of a collection, customising a stack in a collection, building a collection, testing the stack he customised, and pushing the updated collections back to GitHub. Draft here: https://github.com/kabanero-io/draft-guide-working-with-collections

The part "build a collection" is largely duplicated by the content in this reference topic, except for the custom resource definitions needed for the Operator. I think that part of the process is likely to be something Todd would do?

So I would say that adding the CRD info does not fit my guide, but the full content of what you have here mixes up a process Champ might do with one that Todd might do. Is the reference topic temporary? Is there another guide planned for this task information? Or are we leaving task information in the Docs? @bschrammIBM @jantley-ibm

from docs.

Once #127 is merged, then we can close this

from docs.

#127 is merged, I am closing this issue. #134 was opened to make an edit to the new page.

from docs.

closing bc 127 is merged now

from docs.