Skip to content
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

Refine deployment docs, add advanced strategies #2890

Closed
wants to merge 1 commit into from
Closed

Refine deployment docs, add advanced strategies #2890

wants to merge 1 commit into from

Conversation

0xmichalis
Copy link

deployment configurations are propagated appropriately. If the existing
deployment strategies are not suited for your use-case and you have the
need to run manual steps during the lifecycle of your deployment, then you
should consider creating a custom strategy. See the section below on custom
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add link to that section here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -99,46 +105,47 @@ spec:
<4> An xref:image-change-trigger[image change trigger] trigger causes a new replication controller to be
created each time a new version of the `origin-ruby-sample:latest` image stream tag is available.
<5> The xref:rolling-strategy[Rolling strategy] is the default way of deploying your pods. May be omitted.
<6> The existing running deployment will not be paused. Pod template or image changes cover the full spectrum of changes on which deployments currently run.
<7> Revision history limit is the limit of old replication controllers you want to keep around for rolling back. May be omitted. If omitted, old replication controllers will not be cleaned.
<6> Pause a deployment configuration. This allows for multiple changes on the pod template before actually rolling it out.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe describe that this will mute the ConfigChange trigger and ImageChange trigger?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


----
$ oc deploy --latest dc/<name>
----

[NOTE]
====
If a deployment is already in progress, the command will display a
If a deployment process is already in progress, the command will display a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe mention --cancel here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already display the suggestion when somebody hits this.

====

[[retrying-a-deployment]]

== Retrying a Deployment

To retry the last failed deployment:
If the current revision of your deployment configuration failed to deploy, you can
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe worth to describe how to debug failures? (maybe worth to add a section dedicated for that)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will open a follow-up issue since this is out of scope for this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm ok with follow up

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

====

[[deployment-triggers-using-the-command-line]]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reminder for future me: describe the oc set image here (it will trigger deployment and maybe used to manually controller what image will be deployed)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want to intermingle set image with triggers. This will push users to use set image which is 1) not needed and 2) will get us into pretty weird states if we bypass triggers.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the very least we need to identify why would somebody use set image while using a trigger and need to sort out if we can fix any weirdness that comes along with bypassing triggers.

=== When to use a recreate deployment?

* When you must run migrations or other data transformations before your new code starts
* When you don't support having new and old versions of your application code running at the same time
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe add the RWO volume here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


=== Blue-Green Deployment

Blue-Green deployments involve running two versions of an application at the same time and moving production traffic from the old version to the new version ([more about blue-green deployments](http://martinfowler.com/bliki/BlueGreenDeployment.html)). There are several ways to implement a blue-green deployment in {product-title}.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

point to example below?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't point from the description of the strategy to its example in any of the other descriptions and I don't think we need to (you just need to scroll down and finish reading about the strategy you are reading:))

Blue-Green deployments involve running two versions of an application at the same time and moving production traffic from the old version to the new version ([more about blue-green deployments](http://martinfowler.com/bliki/BlueGreenDeployment.html)). There are several ways to implement a blue-green deployment in {product-title}.


=== When to use a blue-green deployment?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blue-Green for consistency

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

1. Create two copies of the example application

---
$ oc new-app openshift/deployment-example:v1 --name=bluegreen-example-old
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe the name should be example-blue and example-green ? ;-)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

$ oc edit route/bluegreen-example
---

Change `spec.to.name` to `bluegreen-example-new` and save and exit the editor.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you provide a patch command for this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@mfojtik
Copy link
Contributor

mfojtik commented Sep 26, 2016

LGTM @openshift/team-documentation ship it :-)

@adellape adellape self-assigned this Sep 30, 2016
@0xmichalis
Copy link
Author

@adellape ping

@0xmichalis
Copy link
Author

@mfojtik re https://trello.com/c/oAlPryPh/793-3-need-to-document-how-to-use-upstream-deployments I guess we want a section in our docs that compares DCs vs D, is that right? Would you say that this PR blocks the Trello card?

@mfojtik
Copy link
Contributor

mfojtik commented Oct 6, 2016

@Kargakis it does not, the trello card is about documenting the upstream deployments and comparing them with Origin deployments.

@0xmichalis
Copy link
Author

@adellape ping

@0xmichalis
Copy link
Author

@adellape note that all these changes are effective in 3.3 - not sure why this has the 3.4 flag

@0xmichalis
Copy link
Author

@vikram-redhat ^

@0xmichalis
Copy link
Author

I would like to move forward with this so I can lay on top some minor changes for 3.4. Thanks.

@vikram-redhat
Copy link
Contributor

@ahardin-rh - PTAL.

@bfallonf
Copy link

@adellape @ahardin-rh Might be worth looking at this issue and putting in that info in the followup (or in a separate followup):

#2930

@0xmichalis
Copy link
Author

@ahardin-rh can you have a look?

@ahardin-rh
Copy link
Contributor

ahardin-rh commented Nov 2, 2016

continuing work in #3149

@ahardin-rh ahardin-rh closed this Nov 2, 2016
@0xmichalis 0xmichalis deleted the deployment-docs branch November 2, 2016 17:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants