Project

General

Profile

Actions

Feature #10669

closed

Forbid actions with irrelevant types of Klever deployments

Added by Evgeny Novikov almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
High
Category:
Deployment
Target version:
Start date:
01/18/2021
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

Users can easily forbid types ("development", "production", etc.) of Klever deployments they installed. After all this can cause very unpleasant consequences, e.g. whey somebody will try to update a production instance as a development one. I suggest to forbid corresponding actions.

In principle, deployment scripts can require types of Klever deployments just once during initial installation. All subsequent actions can determine these types automatically on the basis of some data stored during it.

Actions #1

Updated by Evgeny Novikov almost 4 years ago

  • Target version set to 3.1

Let's do this in Klever 3.1.

Actions #2

Updated by Ilya Shchepetkov almost 4 years ago

  • Status changed from New to Resolved

Implemented in feature-10669 branch, but in a slightly different way. Instead of warning user that they are using wrong mode ("production" instead of "development", and vice versa), now deployment scripts automatically determine and use correct mode.

Old workflow:

$ klever-deploy-local install production
$ klever-deploy-local update production
$ klever-deploy-local update production
$ klever-deploy-local update development // by accident, wrong!
$ klever-deploy-local uninstall production

New workflow:

$ klever-deploy-local install production
$ klever-deploy-local update
$ klever-deploy-local update
$ klever-deploy-local update production // old style commands are still supported
$ klever-deploy-local update development // production mode will be used instead
$ klever-deploy-local uninstall

If required, it is easy to make scripts to fail with error if incorrect mode is specified, but I don't really think it's necessary.

Actions #3

Updated by Evgeny Novikov almost 4 years ago

  • Status changed from Resolved to Closed

I tested these changes manually since our CI does not deal with OpenStack stuff. Everything seems to work well, so, I merged the branch to master in 49da729c2. Let's enjoy sky.

Actions

Also available in: Atom PDF