-
Notifications
You must be signed in to change notification settings - Fork 296
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
NAS-120628 / 23.10 / Add IPFS app to community train #1023
Conversation
df265d8
to
caeb99a
Compare
ae299d9
to
c3de3eb
Compare
1db19d3
to
c92bf3e
Compare
2744c08
to
024b5f1
Compare
required: true | ||
|
||
- variable: resources | ||
label: "" |
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.
Missing label
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.
It's on purpose, As it's the same as the group name. And it just shows the same text twice
be453ee
to
9366e90
Compare
96c4604
to
b95345f
Compare
3c06e5b
to
4b5ba07
Compare
45444f2
to
42145c0
Compare
4b5ba07
to
b8ae72d
Compare
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.
We are missing upgrade strategies files so these apps won't get updates..
Also are we going to chown the storage paths?
I'll need help with the update strategies, at least until I get how it works. From my testing |
@stavros-k for apps which are already present in Where are we doing the chown? |
We chown |
And this happens only once on install? |
Currently is at every startup, that was because I had to fix permissions before the init-config container runs. But permissions container was running after. But with a little change I did in common before we merge it, I can now run it once at installation. |
I think it should be once on installation as chown can be expensive.. |
Agreed. |
{{- include "ix.v1.common.app.permissions" (dict "containerName" "01-permissions" | ||
"UID" .Values.ipfsRunAs.user | ||
"GID" .Values.ipfsRunAs.group | ||
"type" "install") | nindent 8 }} |
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.
Do you think having another workload which only targets the install time workload makes more sense?
It feels weird that we have a workload defined which will be actually running ipfs and then we have under init container some metadata which says that this is only applicable on installatino of chart?
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.
So the 01-permissions
container is marked as type: install
. Which common puts it between an if block of .Release.IsInstall
.
Meaning it will only render at installation, upgrades will not render this at all.
ipfs container does not run as root, so it won't be able to do any chown.
The 02-init-config
is type: init
, meaning it will get rendered (and run on every start of the app).
Which in this case is needed as it configures the ports.
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 see..i was seeing this differently as being a pre-install job or something but obviously that is not the case
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.
Nop, it's just containers in the same Deployment.
Opted to not go for jobs in this case, as it's quick actions. And spinning a whole extra pod would require more configuration
kubo
oripfs
? Recently renamed to kubo (Minimal rename of go-ipfs in 2022Q2 ipfs/kubo#8959)