DB MUST not be updated in content for application update

[gioppoluca]

If we release a new version of the manager we get the DB overwritten with the old content. We need to prevent this problem. Existing data need to be preserved. We need to be able to select what we want to update in the DB being able to do alter on tables if needed but not substituting the DB content. Please check the behaviour of the DB management part and fix

[cpopsa]

What was the spring active profile of the new release?

[xeviscc]

I used docker.

[ciprianpavel]

And when you have used docker, what was the active spring profiles?

[xeviscc]

I used this configuration: https://github.com/CloudOpting/cloudopting-manager/blob/master/rest-component/src/main/resources/config/application-docker.yml

[ciprianpavel]

If you have used docker it means that you have used either https://github.com/CloudOpting/cloudopting-manager/blob/master/dev-compose.yml or https://github.com/CloudOpting/cloudopting-manager/blob/master/prod-compose.yml Those two Docker Compose are using DEV or PROD Spring Profiles. The profile mentioned above (application-docker.yml) is not used in any Docker Compose file.

[xeviscc]

Wrong. I used docker as I told you before.

Check the pom.xml from the project: https://github.com/CloudOpting/cloudopting-manager/blob/master/pom.xml

        <profile>
            <id>docker</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.springframework.boot</groupId>
                        <artifactId>spring-boot-maven-plugin</artifactId>
                        <configuration>
                            <arguments>
                                <argument>--spring.profiles.active=docker</argument>
                            </arguments>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
            <properties>
                <!-- log configuration -->
                <logback.loglevel>INFO</logback.loglevel>
            </properties>
            <dependencies>
                <dependency>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-tomcat</artifactId>
                </dependency>
            </dependencies>
        </profile>

[xeviscc]

@ciprianpavel I do not use this yml's to do the deployment. I compile the code manually and then I create the proper dockerfile.

[ciprianpavel]

In the Flyway scripts there are no delete/update commands that would overwrite the existing data. Flyway will run only the scripts that were not run, according to content of the table public.schema_version.

Could you share the docker compose file used in production? Is the database container set to use volumes?

[xeviscc]

If flyway does not overwrite the database some other problem occurred- What I can tell is that the environment was not very stable when the release was performed.

The steps I follow to do the deploy are:

>mvn clean install -Dmaven.test.skip=true -U -Pdocker
>docker build -t cloudopting/manager:X.X.X .

The dockerfile is the following: https://github.com/CloudOpting/deploy-cloudopting/blob/master/manager/Dockerfile

# more info https://registry.hub.docker.com/_/tomcat/
FROM tomcat:7.0.63-jre8

RUN rm -fr /usr/local/tomcat/webapps/*
# Obtain cloudopting.war from https://github.com/CloudOpting/cloudopting-manager using the script build-war.sh
ADD ./cloudopting.war /usr/local/tomcat/webapps/ROOT.war

And the yml used is: https://github.com/CloudOpting/deploy-cloudopting/blob/master/cloudopting.yml But with correct tags and correct passwords/credentials

[xeviscc]

The release plan with the backup of the database will solve this issue.