How might we accelerate adoption of applier?

[etsauer]

I'm starting a thread to start to brainstorm/propose how we can go about increasing the adoption of applier, both on the app and ops sides.

Some things on my mind at the moment are:

• An introductory tutorial
• A set of labs/exercises that someone could go through
• A set of links to other resources and repos that use applier

@redhat-cop/casl @redhat-cop/cant-contain-this @redhat-cop/developer-workflow

[logandonley]

I like the idea of some labs to go through which would demonstrate how to build out the templates & inventory from scratch, rather than using something like the labs-ci-cd project. Labs-ci-cd is great for once you already know how to use the applier, but I think it introduces too much all at once if you've never used it before.

I'd be happy to help write/edit some of these labs once we get an idea of what we want to cover, since I go through the process of teaching the applier on all the projects I'm on.

[etsauer]

@logandonley sounds great. Let's figure out an mvp skeleton of some kind that we can get merged into the repo so that we can do PRs in small chunks.

[sherl0cks]

This is precisely the approach the Labs enablement took. Check out https://rht-labs.github.io/enablement-docs/#/1-the-manual-menace/README and https://github.com/rht-labs/enablement-docs/tree/master/exercises/1-the-manual-menace before doing anything else.

That said, the biggest barrier to adoption IMO is support status. We need have this part of the product or at least the Mike Barrett's of the world saying this type of approach is ideal/preferred.

[rdebeasi]

+1 to all of this. labs-ci-cd is great if you just want to pull a cake out of the oven, but we should give folks the recipe too.

Also, it would be fantastic to have documentation on the convention of using an .openshift-applier directory, and maybe a simple example application with applier directories and Jenkinsfiles. There's documentation on openshift_cluster_content, but the idea of putting some of this content in an applier directory is is "tribal knowledge."

@pcarney8, @nmalvankar, and I are working on a "booster" project that could double as a sample of how to use the applier.

[pcarney8]

what would be crazy awesome is an interactive tutorial like the RHOAR stuff.

[sabre1041]

@pcarney8 katacoda would be pretty nifty

[etsauer]

@sherl0cks I know i've harped on this before, but I don't see a big need to productize this. We should teach "applier" as if its a pattern, not a tool, and use it to enable on the oc process | oc apply concepts and infrastructure as code practices with Ansible via Git, and in that way, we can avoid "support" type conversations.

[sherl0cks]

I know where you stand on that.

You asked how we drive adoption. Literally the only push back I have ever gotten with the approach is support status.

Its entirely possible that this group decides that enablement work will have larger impact than removing the support detraction.

On Tue, May 22, 2018, 12:16 Eric Sauer [email protected] wrote:

@sherl0cks https://github.com/sherl0cks I know i've harped on this before, but I don't see a big need to productize this. We should teach "applier" as if its a pattern, not a tool, and use it to enable on the oc process | oc apply concepts and infrastructure as code practices with Ansible via Git, and in that way, we can avoid "support" type conversations.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/redhat-cop/openshift-applier/issues/23#issuecomment-391089751, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRfYeq0mJQJmh7PZmpfYPhpTujF8vz3ks5t1FXbgaJpZM4UIqBk .

[pcarney8]

@sabre1041 exactly, i was thinking similar like this: https://learn.openshift.com/middleware/rhoar-getting-started-spring :+1: which is powered by katacoda!

[etsauer]

@pcarney8 @sabre1041 agree. a katacoda quickstart would be wicked.

[logandonley]

Has anyone here worked on a katacoda with an OCP environment before? I'm not seeing it as an option on here: https://www.katacoda.com/docs/scenarios/environments, though clearly OpenShift katacodas exist.

On Tue, May 22, 2018 at 3:38 PM Eric Sauer [email protected] wrote:

@pcarney8 https://github.com/pcarney8 @sabre1041 https://github.com/sabre1041 agree. a katacoda quickstart would be wicked.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/redhat-cop/openshift-applier/issues/23#issuecomment-391115080, or mute the thread https://github.com/notifications/unsubscribe-auth/AYtGPKyhGANmkwT--XoSnXtgpO1i7DZvks5t1GktgaJpZM4UIqBk .

[sherl0cks]

@springdo be advised of this thread.

Please, please, please be mindful of maintenance folks. If katacoda is really deemed as that valuable (honestly I struggle to see the value over just spinning up minishift if needed), then we need to integrate that with Labs enablement, not build a separate offering. We simply do not have the luxury to duplicate efforts.

[pcarney8]

@logandonley https://www.katacoda.com/courses/openshift this what you're looking for?

[logandonley]

@pcarney8 When you go to create a katacoda course you need to specify the environment, but OpenShift doesn't show up as an option on the list, despite those courses (as you linked) existing. So I'd like to see the source of one of those.

But I think as @sherl0cks said, katacoda might be overkill. And at least for me, I would find it more valuable if it was a lab I could do at the beginning of residencies with the customer to get them on board with how it works (ideally run in our residency cluster).

[sabre1041]

@logandonley @pcarney8 I agree. I would recommend to start just providing a simple getting started walkthrough. This could consist of the following:

• Setting up local environment
  • Create base folder structure and requirements.yml and inventory structure (maybe we create an archetype or boiler plate code somewhere
• Iteratively walk through a scenario having the user execute the applier after each action
  • Create OpenShift project
  • Create various OpenShift objects that eventually results in a deployment

[etsauer]

Latest directory structure proposal from conversation with @pcarney8 and @logandonley :

project_root/
  .openshift/ <-- aligns with pre-existing conventions in the ecosystem (e.g. Launch, Fabric8)
    templates/
    params/
    projects/
    ... etc. ...
  .applier/ - traditional Ansible directory structure.
    inventory/
    playbooks/
    roles/

[oybed]

@etsauer I realize I am missing quite a bit here from being on vacation, but a few questions for starters:

• why are we “hiding” this structure? (Ie hidden directories)
• why not include the applier directory within the OpenShift directory? (It’s all related)
• what’s the need for the playbook and roles directories in the “applier” dir? Are they for the most part there just-in-case? (I’d expect them to be mostly unused)
• why do we have a separate templates vs projects directory? Or are these just an example since you have the “....etc...” indication. Also, in general I’d expect many templates and static files to come from “common/shared repos”, how’s this reflected - if at all?

[pcarney8]

@oybed I really like the logical separation between where OpenShift-y things live and where Ansible-y things live. it reinforces to me that you can take the .openshift directory and do whatever you want with it. run it by hand, whatever, but then having the .applier dir allows you to automate these things

[etsauer]

@oybed

• the reason for the hidden directories is that that's the convention elsewhere in the openshift space.. i.e. .openshift/ is where you place your openshift resources in a repo with other stuff in it. I just kept it for .applier but it could change. To me, its not about the directory being hidden, but when I see a .[a-z]/ directory in a git repo, I know that its meaningful for programmatic reasons.
• (see @pcarney8 's response ).. its basically to separating the content from the tool. i.e. for things like OpenShift Launch missions, they will generate for you a set of templates, and eventually parameters, and we could use applier to tack on the IaC bits
• correct, the playbooks and roles directories in simple use cases wouldn't be there, but essentially now, the entire .applier directory takes on the structure of an ansible project. you should only have the directories that are used.
• all directories within are just examples. I think the only two that will always be there are templates and params

[etsauer]

All that to said, I don't ever intend to treat of of the directory stucture stuff as "These are the rules", just "this is a convention to help you build a mental model"

[springdo]

Bit late to the game on this one as was away last week delivering the enablement but here are some of my thoughts.....

• I'm all in favour of it being a hidden folder, .openshift-applier or whatever; don't care about semantics of the name. I am in favour of having both applier and openshift things in one place though. Feels like more hassle to have to flip between things otherwise, plus the readability of paths in one dir approach Im guessing would be simpler. But @pcarney8; i do see your point around separation or concerns (tools and content). Personally I think this all is a very complex way of defining an app's dependencies and such as is so lightening the load of what you need to know etc would be easier for adoption. As it is; with this approach I already need Ansible, Python, and OC client installed to use this thing and if I am just a lazy JS developer (true story) then I want to lower the dependencies my app has not increase or widen them.

• There are examples; as @sherl0cks has suggested, for most of this stuff in the enablement-docs and corresponding enablement-ci-cd. One thing to note here is people attending the course WILL DRIVE ADOPTION OF THE APPLIER. We are aiming to get through 100s of consultants over the next year so if you want to drive adoption through best approach or something start there not in a fork.

• @rdebeasi Example of the .openshift-applier approach with ref app etc and (jenkinsfile in the branch labelled accrodingly) check out the todolist-fe. For a better example where the app has a dependency eg Mongo, this gets lifecycled with the app in todolist-api. Instructions for adding the cluster configs to OCP is available as part of the course material in Exercise II - Attack of the Pipelines. Instructions for Jenkinsfile as part of the pipeline etc checkout Exercise IV - An Enslaved Hope

• If you do want to go down the Katacoda route; I was chatting to the guy who runs it here in London the other day. Can probs setup a call / introduce people if needed.

• I agree the labs-ci-cd is a monster and a bit much to tackle for the applier as a ref example in it's current state; but perhaps when more of the PR and cleanup activities get mergé we'll be in a better state to show it off as a master class in Applier world.

[pcarney8]

Since we already have 3 katacoda scenarios for the applier can we please link to them in this repo?

[rdebeasi]

@pcarney8 I've proposed tutorial links in #90.