Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: ansible-operator-devex.md

title: Ansible Operator Developer Experience Improvements authors: "@fabianvf" reviewers: TBD approvers: TBD creation-date: 2019-12-18 last-updated: 2019-12-18 status: implementable see-also: https://github.com/operator-framework/operator-sdk/pull/2048 replaces: [] superseded-by: [] \[x\] Enhancement is `implementable` \[x\] Design details are appropriately documented from clear requirements \[ \] Test plan is defined \[ \] Graduation criteria for dev preview, tech preview, GA \ This is where to call out areas of the design that require closure before deciding to implement the design. For instance, > 1. This requires exposing previously private resources which contain sensitive information. Can we do this? During the OpenShift 4.4 development timeframe, we plan to improve the developer experience, focusing on a few key areas: Ease development/debugging friction by making it easier to debug and test locally. Allow users to customize the behavior of the proxy, to allow them to work around APIs that do not follow conventions rather than requiring additional logic in the Golang controller. Update scaffolding and examples to take new tooling and best practices into consideration. The motivation for these changes is to ease development friction and give more power to the users, shortening the development iteration loop and preventing them from being blocked by the Golang portion of the Ansible Operator due to Kubernetes/OpenShift API inconsistencies or operator-sdk bugs/behaviors. Allow users to whitelist/blacklist resources to be passed through the cache Update Ansible scaffolding, test scenarios, and examples to make use of newer Ansible features and best practices, including support for collections and simpler and more flexible test scenarios. Readable logs without additional dependencies, and ideally without a sidecar container. Perfection of the logging. We are trying to get incremental improvement for the logs of the Ansible Operator, but there will likely be additional changes and improvements that we make before a 1.0 release. Significant changes to the tooling used for tests. We are aiming primarily to remove/refactor unnecessarily complicated aspects of the scaffolded tests, while making it easier for the user to get the behavior that they need without needing to delve into some of the nittier aspects of the testing logic. This is where we get down to the nitty gritty of what the proposal actually is. As a user, I would like to be able to run `operator-sdk up local` to run my Ansible-based Operator without requiring additional work or

Although it is currently possible to use `up local`, there are a variety of limitations that make the experience inferior to deploying the operator to a real cluster. I would like to be able to run `up local`, and see both the operator logs as well as the logs from the Ansible stdout. I would like both logs to be useful and readable. I would like to be able to run `up local` and not need to change my `watches.yaml` to reflect the different paths of my host vs the operator container. As a user, I would like to be able to use the scaffolded molecule scenarios to run the same set of tests against Kubernetes clusters in the following scenarios: An ephemeral cluster provisioned by molecule An existing cluster local to my machine An existing cluster in the cloud A cluster with OLM installed A cluster without OLM installed As a user, if there are issues in the way the proxy/cache handles a certain resource, I should be able to work around those issues without needing to wait for bugfixes or features in the operator-sdk, by preventing those resources from being passed through the cache at all. For example, if I need to access an OpenShift Project resource (which is not cacheable, because it is not watchable), I should be able to specify that the Project resource skips the cache in my watches.yaml. As a user, I would like to be able to tail the log of the primary operator pod and be able to see both what the Golang process and the child Ansible processes are doing, in a human readable way. Because these are primarily UX improvements, there isn't too much risk of breaking compatibility or hitting unforeseen issues. The primary issue I could see is that if we begin parsing the event messages that Ansible gives us we become reliant on their structure, which is not guaranteed to remain static, so it could lead to a marginally higher maintenance burden when changing Ansible versions. We will add at least one test for each molecule scenario (when possible). We will add tests that make Ansible emit messages of each type that it supports, to help ensure that we can easily catch changes to the messag format. We will add a test scenario that uses `up local`. N/A N/A N/A Major milestones in the life cycle of a proposal should be tracked in `Implementation History`. None None