RFE can we get Kompose to have a --redeploy option

[kbsingh]

I would expect a --redeploy option that allows me to redeploy the entire app into openshift, without needing to instantiate a new project and do migrations ( as a way to keep the dev write code -> dev deploy code cycle going ).

[kbsingh]

Its also worth walking through what the 'Kompose up' workflow and implementation might look like when compared with the specific demand to 'Kompose --redeploy'; In my view 'up' might be a superset of the functionality provided by 'redeploy'.

One key differentiator would be that the 'up' workflow should destory the existing app/project space and regenerate from scratch/scaffolding - whereas the 'redeploy' should only consider the service/container level metadata and initiate a refresh for those when things have changed.

as an example: a "Kompose redeploy --force-rebuild" might be functionally similar to 'Kompose up" where the --force option will rebuild the entire service, and all containers/pods inside it - regardless of change or not.

[surajssd]

One key differentiator would be that the 'up' workflow should destory the existing app/project space and regenerate from scratch/scaffolding - whereas the 'redeploy' should only consider the service/container level metadata and initiate a refresh for those when things have changed.

Is it necessary that we delete all the resources and bring them back up again using kompose, because openshift and kubernetes clients support a directive called as apply (as @kadel mentioned yesterday)

$ kubectl apply -h
Apply a configuration to a resource by filename or stdin.
The resource will be created if it doesn't exist yet. 
To use 'apply', always create the resource initially with either 'apply' or 'create --save-config'.

JSON and YAML formats are accepted.

Usage:
  kubectl apply -f FILENAME [flags]

Examples:
# Apply the configuration in pod.json to a pod.
kubectl apply -f ./pod.json

# Apply the JSON passed into stdin to a pod.
cat pod.json | kubectl apply -f -

Why this won't be a fix to redeploy problem, kompose can make calls to similar APIs here to re-deploy updated artifacts?

[kbsingh]

@surajssd there are 2 different goals there : the 'up' directive -should- do a fresh app deployment where as the 'redeploy' should refresh changed content into the existing app and service deployment.

there is an assumption here that the openshift interface is slightly abstracted away from the user, and have Kompose complete that piece rather than just be a connector in the process.

[dustymabe]

@surajssd there are 2 different goals there : the 'up' directive -should- do a fresh app deployment where as the 'redeploy' should refresh changed content into the existing app and service deployment.

I think that is what he was trying to say that apply should give us that:

The resource will be created if it doesn't exist yet. 
To use 'apply', always create the resource initially with either 'apply' or 'create --save-config'.

[sebgoa]

taking a clue from docker-compose:

-up -> builds and creates containers.
-down -> stops, removes containers and images
-rm -> removes stopped containers (does not delete images)

So the gotchas that one falls into, is to docker-compose stop a service and then up it. Since the container is created it will just restart it and not trigger new builds or use new image...

For use we have:

• up -> kubectl create
• down -> kubectl delete

I think we can add a kompose apply which would do a kubectl apply, the redeploy mentioned by KB.

we need to think carefully about the workflow if new builds are made, and could make use of the ImagePullPolicy.

[kadel]

Agreed, we should start with adding kompose apply.

If we want kompose apply for redeploy it should set imagePullPolicy to Always.
Otherwise its default value depends on how image is specified. (if image tag tag is latest - defaults to Always. Otherwise defaults to IfNotPresent.).

[ngtuna]

I'm not sure if it's out of scope of this discussion but it recalled me a great feature of kubectl that I've used frequently. Whenever I would like to change something in k8s svc, I would prefer to edit directly by kubetctl edit then save, kubectl takes care of updating/applying immediately.

[kbsingh]

@ngtuna agree; thats how i am using it in as well, but the edit/save workflow is hard to automate against. Specially in areas where the deployed endpoint would be abstracted away from the developer / coder

[concaf]

Goal

To introduce a top level command which will patch/update the already deployed resources with the newer updated configuration

Issue

If the docker compose file is updated after the application is deployed using kompose up, the only way to deploy the updated artifacts using kompose is to either undeploy - deploy the application again using kompose up, or create another namespace for the new project and delete the older one. This breaks the development workflow.

It would be nice to have a kompose apply/redeploy/patch command which takes the updated configuration and patches the already deployed one.

This new command should -

• convert the docker compose file to the provider artifacts
• be able to check if the newer artifacts are different from the already deployed application
• patch the deployed application based on the decision made

Proposed solution

• The kubectl apply way
  kubectl apply checks all the above boxes and performs a strategic merge PATCH operation, however there is no endpoint for Apply like List, Get, Delete, Create, etc.
  e.g. check out the fields in type DeploymentInterface interface

So, in order to implement this we either need to replicate or use the RunApply function from kubectl's cmd package.

This will not be very straightforward.

• The kubectl update/replace way
kubectl replace (kubectl update is now deprecated) replaces the resources instead of patching them with newer configuration. This is a PUT operation, not a PATCH operation.

This does have an Update endpoint for all resources and will be easier to implement, however this will also mean that the resources go down and come back up again (very quickly though), but it might interfere with availability of the application more than apply.

What should be the best way forward with this?
apply or replace? Or something else I might not have thought about till now?

Thoughts?
CC: @kadel @surajssd

[kadel]

There is also another option. Don't do it at all. Let users do it manually like using something like this kompose convert --stdout | kubectl apply -f -

But if we do it I would go with something simple like replace. It is not Kompose job to cover whole workflow.

[concaf]

@kadel even replace will mean that changes made might be discarded, or connection to the current endpoints might be disrupted, since the resources are being created again.

That is why Kubernetes refuses to do a replace because spec.ClusterIP is set as an immutable field as it might cause issues to be unset and set again, unless we pass a --force with it. Not sure if replace is the best way forward.

However, +1 for maybe not doing this at all, since this just means re-implementing the behavior already done in kubectl client which is a superior tools wrt features.

kompose convert --stdout | kubectl apply -f - LGTM.

@kbsingh thoughts about this? Does piping to oc apply work for you?

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale