dy-sidecar pulls inputs before starting service (for certain services)

[GitHK]

• dy-sidecar changes ownership on states, inputs and outputs (that allows everyone to access them write/read) -> inputs should only be readonly not write, like we currently have them
• user service no longer touches permissions of these folders

Acceptance criteria:

• inputs pulling has to work after user services starts
• inputs must not be writable by user services
• outputs must still be writable by user services
• outputs must be upload able by dy-sidecar

[sanderegg]

@GitHK I would prefer we do not start doing it "only for certain services" but in general (aka no spaghetti)

[GitHK]

@GitHK I would prefer we do not start doing it "only for certain services" but in general (aka no spaghetti)

That means we have to deprecate all the services in the platform. Nothing can prohibit a container, which runs as root to change ownership of a folder or file.

[mrnicegyu11]

@GitHK : Can you please confirm or deny that the first approach for this is to simply have the dy-sidecar pull the inputs before being marked as ready, so effectively delaying the start-up time [yes or no]? Can you comment if this ticket touches at all the scenario when inputs change while the two connected services are already running?

Also, I dont understand your last comment, I cant follow :( ...

[GitHK]

@mrnicegyu11

Let's have a recap on how (at the date of writing this post) new style dynamic-sidecars start a dynamic-service (below is an ordered sequence top to bottom of events):

NOTE: this doesn't contain every single step in detail, just an overview of the steps required to comprehend this ticket

1. director-v2 creates a docker 2 swarm services: dy-sidecar and dy-proxy
2. director-v2 waits for the dy-sidecar to be ready
3. director-v2 in parallel || (pulls states (aka: workspace) and outputs (aka: content of the output ports)
4. director-v2 runs "docker compose up":
   1. user services' containers are pulled
   2. user services' containers are created
   3. user services' containers are started
   4. NOTE: with no exception that I am aware of each user service container changes the permissions of the inputs directory (which currently is empty)
   5. user services' start their respective applications
5. director-v2 waits for all user services to be in "running" state
6. director-v2 configures dy-proxy to accept incoming traffic
7. FRONTEND_IN_THE_BROWSERS displays the iframe -> users see the content of the service
8. FRONTEND_IN_THE_BROWSERS somehow figures out that the service is ready and it pulls the inputs (this is the call sequence generated: browser -> webserver -> director-v2 -> dy-sidecar)

---

What was I truing to say in my ticket's description?

• move step 8. to step 3. and pull in parallel states, inputs, outputs
• this has repercussions, step 4. -> v. is no longer valid, inputs directory's content is now owned by one of the user services' (whatever container was the last one to change permissions on the folder)
• from now onwards it is no longer possible for the dy-sidecar to pull inputs, since it no longer has permissions on the folder to write data

How to avoid this?

• when a service is build a new label should be added where the service "promises" that it does not touch the inputs folder's permissions
• this allows to avoid the above situation where inputs can be pulled by the dy-sidecar before the user services start

Questions and answers rewritten in short:

• SAN I would prefer we do not start doing it "only for certain services" but in general
  • solution: release all new style-dynamic services and deprecate all existing ones
  • this one sounds difficult to me!
• Dustin Q1: does this solution delay the startup time?
  • Yes, if size_of(inputs_folder) > size_of(outputs_folder)
  • Yes, if size_of(inputs_folder) > size_of(states_folders)
  • No, otherwise
• Dustin Q2 Can you comment if this ticket touches at all the scenario when inputs change while the two connected services are already running?
  • it will not
  • if it were to interfere, it means that the ports can no longe be pulled via the dy-sidecar after the service boots -> which breaks the platform. So the answer is NO.

[sanderegg]

As discussed today with ANE:

• upgrading the integration-version of the services will allow to tackle backwards compatibility

[GitHK]

As discussed today with ANE:

• upgrading the integration-version of the services will allow to tackle backwards compatibility

I think it's also possible (but I need to check), to pull inputs as soon as the the user services containers are reported as ready by docker. Afterward the UI will be allowed to load the iframe. This can be done with the existing services.

[sanderegg]

again, it is about pulling the inputs before the services are started, which would be logical. that is what you said was tricky for old services.