Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adds migrate and run ansible commands #887

Merged
merged 5 commits into from
Jan 9, 2019

Conversation

mhrivnak
Copy link
Member

@mhrivnak mhrivnak commented Jan 7, 2019

The operator-sdk migrate command adds go source and other files necessary to
convert an ansible operator to a hybrid operator.

The scaffolds used for migrate are also made available for use in creating
the ansible-operator base image through
commands/ansible-operator-base/main.go.

The operator-sdk run ansible command uses the operator-sdk binary as the
production-use ansible operator binary.

fixes #886

The `operator-sdk migrate` command adds go source and other files necessary to
convert an ansible operator to a hybrid operator.

The scaffolds used for `migrate` are also made available for use in creating
the ansible-operator base image through
`commands/ansible-operator-base/main.go`.

The `operator-sdk run ansible` command uses the operator-sdk binary as the
production-use ansible operator binary.

fixes operator-framework#886
@mhrivnak mhrivnak added kind/feature Categorizes issue or PR as related to a new feature. language/ansible Issue is related to an Ansible operator project labels Jan 7, 2019
@openshift-ci-robot openshift-ci-robot added the size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. label Jan 7, 2019
@estroz
Copy link
Member

estroz commented Jan 7, 2019

@mhrivnak why do we need both commands/ansible-operator-base/main.go and operator-sdk migrate? Can the former not be a part of the latter? Perhaps I'm missing something.

@mhrivnak
Copy link
Member Author

mhrivnak commented Jan 8, 2019

@mhrivnak why do we need both commands/ansible-operator-base/main.go and operator-sdk migrate? Can the former not be a part of the latter? Perhaps I'm missing something.

The migrate command is for an end user who already has a functioning ansible operator and wants to turn that into a hybrid operator.

The commands/ansible-operator-base/main.go file is for our own release engineering only, to create the ansible-operator base container image starting from zero. Differences from the migrate command include: there is no Go source code involved, no Gopkg.toml, no ansible role or playbook, no CRD, no watches.yaml file, no existing Dockerfile that needs to be replaced. As opposed to the migrate command, which lays down a main.go that will eventually be compiled into the operator binary, this base image creation workflow assumes that the operator-sdk binary itself will be built through other means and added to the container image that's being composed.

FWIW I don't know if this is the best location for this file. Since it is for release engineering only, maybe it would be more clear to move it into hack/image/ or similar?

@estroz
Copy link
Member

estroz commented Jan 9, 2019

@mhrivnak thanks for clarifying. I agree, since commands/ansible-operator-base/main.go isn't intended to be a compiled command it should go into hack.

Copy link
Member

@shawn-hurley shawn-hurley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some user experience questions

Watches: true,
Roles: true,
}
_, err := os.Stat("playbook.yaml")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonder if this should be a flag or at least alert the user that we are assuming no playbook if this is not found. I could see cases, where playbooks are in a new directory and users, have changed things. Telling the users what we are doing, and what they can do to change it back if that is incorrect might be a good idea. Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah a good example of this would be the etcd operator which puts all of it's ansible code under a folder ansible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. If they put it in a different location that what we expect, they'll have to manually add it to their new Dockerfile. Presumably they'd catch that in comparing their old Dockerfile to new, but it's worth calling out explicitly.

}

dockerfilePath := filepath.Join(scaffold.BuildDir, scaffold.DockerfileFile)
err = os.Rename(dockerfilePath, dockerfilePath+".sdkold")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to alert the user that we took this action after this finishes IMO.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, at the end of the command, should we run dep ensure? or should we ask the user to run dep ensure?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed to the alerting. I'll log something about it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I lean toward not running dep automatically, in part because it will cause the e2e tests to fail in cases like we see here where operator-sdk has changes that aren't in the upstream repo. It makes me think there are enough other cases where the user doesn't want to run dep ensure right away, that we shouldn't do it automatically.

Copy link
Contributor

@dymurray dymurray left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like the approach you took and I had success with the migrate and run commands. Good stuff!

estroz and others added 2 commits January 9, 2019 14:07
fixes version check in `release.sh`

Co-Authored-By: mhrivnak <mhrivnak@hrivnak.org>
@mhrivnak
Copy link
Member Author

mhrivnak commented Jan 9, 2019

@estroz thanks for the assist with release.sh! I think it should be set now.

@mhrivnak mhrivnak merged commit dd62eaa into operator-framework:master Jan 9, 2019
@mhrivnak mhrivnak deleted the migrate-and-run branch January 9, 2019 22:58
@hasbro17
Copy link
Contributor

hasbro17 commented Jan 9, 2019

@mhrivnak Can you please update the CHANGELOG for the migrate and run ansible commands as well?

@hasbro17
Copy link
Contributor

hasbro17 commented Jan 9, 2019

We also need to update the CLI reference guide for the new commands.
https://github.com/operator-framework/operator-sdk/blob/master/doc/sdk-cli-reference.md

@hasbro17
Copy link
Contributor

Also the relevant issue for this PR is #860, not #886 I think.

@mhrivnak
Copy link
Member Author

@mhrivnak Can you please update the CHANGELOG for the migrate and run ansible commands as well?

Yes, I'll add that and a bit of documentation separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. language/ansible Issue is related to an Ansible operator project size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

enable ansible e2e test that checks for errors in logs
6 participants