Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Improve dev tooling #1305
Improve dev tooling #1305
Changes from 17 commits
ef3dec5
84e34b7
6f87ad3
a0987d8
28c68d3
652d52f
1b21f1e
6d58b34
34c4fb9
c4aee7e
8f216c2
c53c65a
67e0586
74149ba
8a4028c
7de665e
75894d3
7c50be7
8103dea
43dc74b
af6ecfb
71346cf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we could define a custom static user with ood-portal-generator, this extra logic could be removed. It's not great in my opinion to have this file managed by ood-portal-generator but then due to lack of flexibility, we completely overwrite it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I added this
--force
here because we mount in/opt/etc/ood/config
so the sha file doesn't exist the very first time you run.--force
may actually suite this use case though. We persist theood_portal.yml
on the host file system, mounted into the container. And keep theood-portal.conf
ephemeral, regenerated every time we start the container up, so we actually don't care what it's previous state was.Maybe
--rpm
is the right flag here? But I'm happy to force here in this edge case, and keep theupdate_ood_portal
the way it is, if nothing else, to just keep the attack surface small.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should make it possible to define a Dex user via ood-portal-generator so you don't have to write out a second file for the Dex local user. I believe right now we hardcode in a default local user, which I think was just not thinking people or even developers might want to choose a different user besides the default we provide
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a way to provide development containers with such a feature. Enabling it in ood-portal-generator - I'm not sure. I've been told someone kept that
ood
user around during the basic auth days and it went sideways for them. I mean they accidentally kept it and someone else started using it.I think there could be a discourse topic where someone wanted to do something similar for a proof of concept deployment. So maybe we should provide a way to generate a single user with a new password. For proof of concept deployments and this container.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the biggest argument for using ood-portal-generator for generating the user is we already manage the Dex YAML config with ood-portal-generator so having ood-portal-generator make the config and then modifying it later without ood-portal-generator seems messy and will require subsequent executions of ood-portal-generator to require the --force flag. I think taking the work here for generating a bcrypt password and supporting something similar with ood-portal-generator shouldn't be too big a change and pretty easy to maintain backwards compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@msquee do we need something special here for gitpod?