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

Test self-built rook containers also with SES #229

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

shaas
Copy link
Collaborator

@shaas shaas commented Dec 4, 2020

This PR adds the possibility to test self-built rook containers against SES

Signed-off-by: Stefan Haas [email protected]

@shaas shaas force-pushed the master branch 2 times, most recently from 36e716a to 5c556b6 Compare December 7, 2020 10:06
@shaas
Copy link
Collaborator Author

shaas commented Dec 7, 2020

@jhesketh Please have a look

Copy link
Contributor

@jhesketh jhesketh left a comment

Choose a reason for hiding this comment

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

I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:

  • branch the devel or OBS project into your home repo,
  • pull in your git branch of github.com/SUSE/rook,
  • build in OBS
  • Point rookcheck at the built containers

This will ensure we are building in the same manner as the proper pipeline.

Thoughts?

config/rook_upstream.toml Outdated Show resolved Hide resolved
config/ses.toml Outdated Show resolved Hide resolved
config/settings.toml Outdated Show resolved Hide resolved
tests/lib/rook/ses.py Outdated Show resolved Hide resolved
tests/lib/rook/ses.py Outdated Show resolved Hide resolved
@shaas
Copy link
Collaborator Author

shaas commented Dec 8, 2020

I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:

* branch the devel or OBS project into your home repo,

* pull in your git branch of github.com/SUSE/rook,

* build in OBS

* Point rookcheck at the built containers

This will ensure we are building in the same manner as the proper pipeline.

Thoughts?

My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES.
Testing changes with your proposal would take ages.

@jhesketh
Copy link
Contributor

jhesketh commented Dec 9, 2020

I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:

* branch the devel or OBS project into your home repo,

* pull in your git branch of github.com/SUSE/rook,

* build in OBS

* Point rookcheck at the built containers

This will ensure we are building in the same manner as the proper pipeline.
Thoughts?

My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES.
Testing changes with your proposal would take ages.

Why would it take ages? It's a few more manual steps, but it at least allows us to use the same tooling as the release pipeline.

@shaas
Copy link
Collaborator Author

shaas commented Dec 9, 2020

I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:

* branch the devel or OBS project into your home repo,

* pull in your git branch of github.com/SUSE/rook,

* build in OBS

* Point rookcheck at the built containers

This will ensure we are building in the same manner as the proper pipeline.
Thoughts?

My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES.
Testing changes with your proposal would take ages.

Why would it take ages? It's a few more manual steps, but it at least allows us to use the same tooling as the release pipeline.

This feature is really all about to test changes while the development process or e.g. bug hunting. This means adding additional steps makes it more complicated and adds more possible places of errors.
But you are correct, in the end it needs to go the way you described. But IMO not for each and every dev-test I want to do "locally".
(Also, adding this possibility does not hurt ;) )

Is this OK for you?

@jhesketh
Copy link
Contributor

I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:

* branch the devel or OBS project into your home repo,

* pull in your git branch of github.com/SUSE/rook,

* build in OBS

* Point rookcheck at the built containers

This will ensure we are building in the same manner as the proper pipeline.
Thoughts?

My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES.
Testing changes with your proposal would take ages.

Why would it take ages? It's a few more manual steps, but it at least allows us to use the same tooling as the release pipeline.

This feature is really all about to test changes while the development process or e.g. bug hunting. This means adding additional steps makes it more complicated and adds more possible places of errors.
But you are correct, in the end it needs to go the way you described. But IMO not for each and every dev-test I want to do "locally".
(Also, adding this possibility does not hurt ;) )

Is this OK for you?

Well it adds a bit of complication and also the possibility for something to work in this environment but not OBS. Having said that, I'm fine with this. If you can fix up the tox issues we can merge it :-)

@shaas
Copy link
Collaborator Author

shaas commented Dec 10, 2020

I'm a little unsure if building from git is the right place. We may carry patches and other nuances in OBS. I'm inclined to say that the correct method would be to:

* branch the devel or OBS project into your home repo,

* pull in your git branch of github.com/SUSE/rook,

* build in OBS

* Point rookcheck at the built containers

This will ensure we are building in the same manner as the proper pipeline.
Thoughts?

My point is to test a self-built rook-container (this might be a branch of SUSE/rook or also rook/rook) against SES.
Testing changes with your proposal would take ages.

Why would it take ages? It's a few more manual steps, but it at least allows us to use the same tooling as the release pipeline.

This feature is really all about to test changes while the development process or e.g. bug hunting. This means adding additional steps makes it more complicated and adds more possible places of errors.
But you are correct, in the end it needs to go the way you described. But IMO not for each and every dev-test I want to do "locally".
(Also, adding this possibility does not hurt ;) )
Is this OK for you?

Well it adds a bit of complication and also the possibility for something to work in this environment but not OBS. Having said that, I'm fine with this. If you can fix up the tox issues we can merge it :-)

Fixed!

Thank you.

Copy link
Contributor

@jhesketh jhesketh left a comment

Choose a reason for hiding this comment

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

A couple of extra things I noticed/nits. However I know we've done a lot of revisions on this so if you'd like we can merge it and follow them up in a new PR?

# The target version of SES to install. This must match a key below that
# contains the repositories and yaml substitutions.

target = "devel7"

[ses.ses7]
rook_ceph_chart = "registry.suse.de/suse/sle-15-sp2/update/products/ses7/charts/rook-ceph:latest"
ceph_image = "registry.suse.de/devel/storage/7.0/containers/ses/7/rook/ceph:latest"
Copy link
Contributor

Choose a reason for hiding this comment

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

This shouldn't be devel?

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually thinking about this more, why is the ceph_image part of this change? It seems unrelated to providing a custom rook_image. It could be a separate change though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

When using self-build rook-images I do not want to use the rpm-package with the upstream or SES based yaml-files and helm charts. I want to use the ones out of my set rook-branch. Therefore I need to know which images for "fixing" the yaml-files.

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, I see now.

We could use the yaml_substitutions to achieve this, but that might be too complex? Maybe an example file would help if we did though.

If not, it might be worth noting that this is only used when building from git, and that the below yaml_substitutions are only used when /not/ building from git.

@@ -0,0 +1,21 @@
---
Copy link
Contributor

Choose a reason for hiding this comment

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

(nit) Would prefer this file to be renamed to avoid the confusion between ses and upstream. Perhaps playbook_rook_ses_custom_image.yaml?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I am fine with that change, too. My intention was to use the naming-scheme which is already present (playbook_rook_upstream.yaml).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants