dshcherb

import sqlite3


def init_db():
    TEST_DB_FILE = 'testdb.sqlite'
    db = sqlite3.connect(TEST_DB_FILE, isolation_level="EXCLUSIVE")
    c = db.execute("BEGIN")
    c.execute("SELECT count(name) FROM sqlite_master WHERE type='table' AND name='snapshot'")
    if c.fetchone()[0] == 0:
      # Using TEXT colums is not a good idea because SQL expressions will have undefined result per sqlite3 documentation:

dshcherb

Manual functional test environment (localhost):

juju model-config cloudinit-userdata
ca-certs:
  trusted:
  - |
    -----BEGIN CERTIFICATE-----
    # juju tools mirror certificate here
    -----END CERTIFICATE-----
preruncmd:

dshcherb

// kubernetes tree: c005b9d0ab6cd963abf66a9a12fb8ad5e48121ad

enforcedNodeAddresses = append(enforcedNodeAddresses, v1.NodeAddress{Type: v1.NodeHostName, Address: kl.GetHostname()})
				node.Status.Addresses = enforcedNodeAddresses
				return nil
			}

dshcherb

For verification, applications that use openssl would create an openssl context with either default or specific directories used for verification. Note that some packages (e.g. openldap) use gnutls instead of openssl and gnutls has a compatibility layer (includes/gnutls/openssl.h) which includes common functions like setting verification paths so you may rely on using a single code base for configuration to some extent.

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_load_verify_locations.html
SSL_CTX_load_verify_locations - set default locations for trusted CA certificates
int SSL_CTX_load_verify_locations(SSL_CTX *ctx, const char *CAfile,
  const char *CApath)
{   return (X509_STORE_load_locations(ctx->cert_store, CAfile, CApath));

int X509_STORE_load_locations(X509_STORE *ctx, const char *file,
  const char *path)

dshcherb

  **OpenStack Releases and template loading**

  When the object is instantiated, it is associated with a specific OS
  release. This dictates how the template loader will be constructed.

  The constructed loader attempts to load the template from several places
  in the following order:
  - from the most recent OS release-specific template dir (if one exists)
  - the base templates_dir
  - a template directory shipped in the charm with this helper file.

dshcherb

https://gnu-linux.org/building-ubuntu-rootfs-for-arm.html
"2) Extract the downloaded image with ‘sudo’ to allow ‘mknod’ commands to work"

# get a cloud image from here
# https://cloud-images.ubuntu.com/daily/server/xenial/
# https://cloud-images.ubuntu.com/daily/server/xenial/current/

# based on https://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/bin/img2squashfs#L161
# extract a cloud image rootfs to a directory, sudo is needed for `mknod`s to work
# doesn't have to be .tar.gz - could well unsquashfs an existing squashfs

dshcherb

# this is an example of how to use aliases to avoid making yaml too large
# just by using language features of yaml and a parser support without
# relying on juju at all

# this was done for charm-helpers, see:
# charmhelpers/fetch/__init__.py
# def configure_sources
# and
# charmhelpers/fetch/ubuntu.py
# def add_source