Skip to content
This repository was archived by the owner on Jul 24, 2019. It is now read-only.

Conversation

@intlabs
Copy link
Contributor

@intlabs intlabs commented Feb 15, 2017

What is the purpose of this pull request?: To replace ansible with PyMySQL for DB Creation

What issue does this pull request address?: This is part of the effort to become image agnostic.

Notes for reviewers to consider: This PR is intended to supersede #140

Specific reviewers for pull request: @alanmeadows, @srwilkers, @v1k0d3n

@intlabs intlabs changed the title [wip] 0.2.0/db jobs native client [wip] Replace Ansible with SQLAlchemy/PyMySQL for database creation. Feb 15, 2017
@intlabs intlabs changed the title [wip] Replace Ansible with SQLAlchemy/PyMySQL for database creation. Replace Ansible with SQLAlchemy/PyMySQL for database creation. Feb 15, 2017
Copy link
Contributor

@alanmeadows alanmeadows left a comment

Choose a reason for hiding this comment

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

Good start Pete. A few comments below.

@@ -0,0 +1,12 @@
{{- define "helm-toolkit.secret_db_root" }}
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not named after the file that contains it.

@@ -0,0 +1,2 @@
{{- $envAll := . }}
{{- include "helm-toolkit.secret_db_root" $envAll }}
Copy link
Contributor

Choose a reason for hiding this comment

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

Because this toolkit script leverages only values from .Values.database I would recommend that is what we pass. We have a mix between passing macros $envAll or . and the leafs that contain the data they need. We should standardize on one. I prefer leafs (.Values.database as its clear what input we are passing the macro but I'm flexible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That approach works for me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This work (and comments) have been made moot by: https://github.com/att-comdev/openstack-helm/pull/262/files#diff-728a997bda2af0665cbf1fde10e4231fR153, which is a better approach. For now I'll adopt this method verbatim, to allow work to continue on this PR.

ip_address: "0.0.0.0"

database:
secret:
Copy link
Contributor

Choose a reason for hiding this comment

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

It's not clear to me how this differs from the root_password below

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the name of the secret, rather than the actual password. I'll try to make this clearer in a follow-up commit.

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes much more sense. I think just secret_name vs secret would of made me realize this.

Copy link
Contributor Author

@intlabs intlabs Mar 16, 2017

Choose a reason for hiding this comment

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

This will be refactored to match the style here: https://github.com/alanmeadows/aic-helm/blob/b40a7bf3be5bcc9960452b0ad72c6db9932f101e/keystone/values.yaml#L303. I'll insert the key k8s_secret_name as appropriate within this to define the name of the secret that will hold the derived SQLAlchemy connection string.

secretKeyRef:
name: {{ .Values.database.secret.root }}
key: DB_CONNECTION
- name: OPENSTACK_CONFIG_FILE
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like this will keep growing, maybe our checker-helpers needs its own oslo config file which is just a config map? This may grow to unwieldy proportions. Understandably could be future work.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The idea here is to consume the same config file as the service will consume, the job itself is what defines the scope here I think. Unless we are across purposes?

mountPath: /tmp/db-create.py
subPath: db-create.py
readOnly: true
- name: pod-etc-service
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a minor nit, not sure I fully grasp the naming conventions here... pod-etc-service really is an emptyDir, service-config is keystone.conf... I had to look down below two or three times - which either represents my own senility or the need to make this clearer

Copy link
Contributor Author

@intlabs intlabs Mar 16, 2017

Choose a reason for hiding this comment

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

I've used the naming conventions from harbor here:

  • Prefixes:
    • pod: represents a volume that is local to the pod, almost always an emptyDir
    • service: a volume that is common the service, almost always a configMap, but may be a shared volume
  • Suffixes:
    • The mount location of the volume if only used once.
    • If a configmap, just configmap (unless several are used, in which case I added a further suffix with some brief indicator of the contents)

Of course this comment contradicts reality, unless there is objection I'll update to make the above true.

@v1k0d3n v1k0d3n added this to the 0.3.0 milestone Mar 15, 2017
@intlabs
Copy link
Contributor Author

intlabs commented Mar 16, 2017

To resume work on this PR we should merge the following:

As they make changes to the job layout that will cause conflicts with this work.

@intlabs
Copy link
Contributor Author

intlabs commented Mar 16, 2017

Superseded by #289

@intlabs intlabs closed this Mar 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants