search

redhat-cop / cluster-lifecycle

Sample Repository that shows state management
Creative Commons Attribution Share Alike 4.0 International
4 stars 8 forks source link

Can we move this repo towards a reference architecture of applier conventions rather than library of examples? #9

Open etsauer opened 6 years ago

etsauer commented 6 years ago

I'm noticing that there are a few very different directory structures developing in different repos for applier inventories and i'm wondering if there are some things we can do to tighten that up.

I know that, when we first conceived of the applier concept/pattern (before ansible was even a part of it), one of the goals we had was to agree on a common 'language' for IaC for OpenShift. As we've moved towards the applier being a piece of technology, it ended up being much more flexible to where the language, or structure, is not really necessary or enforced. While I think that's a good thing for the implementation, I still thing that agreeing on a convention for this type of thing is very valuable.

To that end, I would like to see this repository become more opinionated towards a directory structure for both the ansible inventory, and the template/resource files we manage. I would also like us to condense the two separate examples into a single, cohesive IaC repo, and have the README read more like a reference architecture guide with opinions and the "why" behind them. The README could also link out to other repositories where we have applier inventories we feel follow the conventions well (places like labs-ci-cd, container-pipelines/quickstarts, casl, etc... once we tighten them all up).

To get this kicked off, let me propose a standard directory structure convention.

repo_root/
  .openshift/
    inventory/ (or if there's a need for multiple, use inventory- as a prefix)
    projects/ - projects to create
    policy/ - cluster-level objects like clusterRoles, roleBindings, storageClasses (static files only, no templates)
    templates/ - openshift template files
    params/ - parameter files
  ... other files directories in the repo...
sherl0cks commented 6 years ago

in general, I support a convention. I have questions/thoughts:

etsauer commented 6 years ago

@sherl0cks in the projects dir would be your ProjectRequest objects or your project/namespace definitions. The reason for the separate directory here is that projects/namespaces require special handling (e.g. you cannot oc apply a ProjectRequest)

My thought behind just templates is that its already in the context of an applier folder. if we another convention where all of these directories were in the project root, i would agree, that name might be problematic. however, none of the other directories have openshift in the name so it seems weird to only put it there.

sherl0cks commented 6 years ago

but you can oc create them with the applier's error handling just fine. We should be doing that by default so a user without elevated privileges can run the inventory. see:

etsauer commented 6 years ago

@sherl0cks exactly. that's what I was saying.. becuase ProjectRequests need to be created not applyd they need to be separate, thus the projects folder.

sherl0cks commented 6 years ago

well they don't need to be separate. you just point an inventory to them wherever they are. if you are arguing that they should be separate, I guess I just don't see why. I see them as params like all other params... would like @oybed or @sabre1041 to share opinions there.

etsauer commented 6 years ago

ah yeah, sorry. I didn't explain. The reason I have for having a separate folder is that, because there's very little to parameterize in a ProjectRequest, i often just define all of them in static files, and oc create -f the entire directory. this is the same thing that I do with the policy directory, except i use apply, thus the separation between the two. In some future state, where the design of ProjectRequest is fixed, this need could go away. But I could also just handle them differently.

etsauer commented 6 years ago

also i now realize the projects/projects.yml implies all my projects are in a single file, which devalues the direcory. I removed the file for clarity, but i'm still open to removing the directory completely.

etsauer commented 6 years ago

@sherl0cks @redhat-cop/casl : we had a conversation today about some work that @mike4263 did to build a dynamic inventory script that generated the openshift_cluster_content structure by traversing a directory tree. This is a pretty interesting use case that, to me, further supports a good case for having a defined "schema" for applier inventories.

sherl0cks commented 6 years ago

That's cool - keen to see some code / an example.

@etsauer - we've been using https://raw.githubusercontent.com/redhat-cop/cluster-lifecycle/master/files/projectrequest/template.yml, so it gets treated like every other template. Can this just be an either / or situation? projects exists if it contains files. if it doesn't exist, then you should expect projects to be treated like any other template, with the exception of the created vs applied thing

etsauer commented 6 years ago

Finally coming back around to this...

@sherl0cks yes, it would be either/or. and really... the projects directory would ONLY be used in the case that you're using ProjectRequests to create the projects, since they aren't a normal resource (i.e. can't use them to control the full lifecycle)