search

irods / irods_demo

BSD 3-Clause "New" or "Revised" License
6 stars 14 forks source link

[40] add s3 plugin configuration and default demobucket #84

Closed trel closed 1 month ago

trel commented 2 months ago

docker compose up will now have s3resc configured and ready to receive files.

also updated the minio version to latest.

the client container is being used to run the iadmin mkresc command... open to better solutions.

trel commented 2 months ago

agreed - but this was the best place that 'already existed' after the provider is stood up and running.

the entrypoint for the provider just runs setup, and then restarts the server - nowhere to slip in more additional steps against a running server.

i suppose we could setup, then standup, then steps, then stop, then start for 'real'... but that could confuse other services awaiting a server that is 'up'... since it will actually stand up three times before it's 'ready'.

trel commented 2 months ago

i'm considering creating a firstrun.sh inside the provider that can run between 'setup' and 'start server for real'.

this will give us a generic 'home' for administrative work (mostly iadmin commands) that may need to be run.

trel commented 2 months ago

also declare a dependency on minio container from provider.

alanking commented 2 months ago

Sounds good. Will await said changes

trel commented 2 months ago

changes landed with firstrun.sh

only thing i don't like is the forced killing of agents (graceful didn't work) at end of setup... gotta be a hostname glitch... please eyeball / try it and see for yourself...

docker compose up irods-catalog-provider

korydraughn commented 2 months ago

Will give it a try now.

alanking commented 2 months ago

Was the (dis)graceful shutdown after setup observed before these changes?

trel commented 2 months ago

I believe so - my best guess at the moment is that controller.py is matching against full paths to the server binaries, and since we're standing it up directly with irodsServer -u... it may not be matching / killing correctly.

alanking commented 2 months ago

The setup script is responsible for (and, as far as I can tell, the only one) shutting down the server here, so I would guess that it is not related to the irodsServer -u usage given that this doesn't happen until after the server has been shut down by the setup script. Unless you're saying that the (dis)graceful shutdown also occurs when stopping the server in general (and not just after setup)?

trel commented 2 months ago

Okay, further investigation shows that even using /var/lib/irods/irodsctl start and stop directly... it cannot gracefully stop the things. So it's not just setup.

I think I have to edit controller.py to print more things out to see why we're not matching...

trel commented 2 months ago

It's matching correctly. the server_proc.terminate() never gets past 'sleeping' status...

Not sure what's going on...

trel commented 2 months ago

okay, so... it's healed, but i don't really understand why. kory, can you explain why this works now? and why it would have made irods-grid unhappy prior? SIGTERM wasn't

I changed graceful to wait for 100 seconds, thinking that perhaps the host mapping was just 'wrong' and if I waited for the irods-grid TCP timeout at 30 seconds... but that didn't affect anything, it counted to 100 seconds and then SIGKILL was still used.

korydraughn commented 2 months ago

I've reproduced the situation. I'm now trying to brain out what causes it.

korydraughn commented 1 month ago

Given this is for demo purposes, the solution presented by @trel is perfectly fine. I think all we need is an issue that captures the problems and then we squash/merge this.

alanking commented 1 month ago

Yes, please squash.

trel commented 1 month ago

squashed