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

Expose trust key when exporting bundles #10289

Merged

Conversation

Projects
None yet
3 participants
@achilleasa
Copy link
Contributor

commented Jun 5, 2019

Description of change

This PR ensures that we correctly set the trust key for each application that the operator has explicitly trusted when exporting bundles via juju export-bundle. This PR is split in two parts.

The first part patches the server API so that we populate the RequiresTrust field of the BundleData type when exporting the bundle. It also bumps the Bundle API to V3. This change is needed to allow the client code to figure out if it can expect the trust flag to be included by the call to ExportBundle or whether it needs to use a fall-back approach (see below).

In order to be backwards-compatible with older controllers, the second part of the PR patches the client so that when it connects to an older controller it will first grab the exported bundle and then locally patch it to set the trust flag for the applications. To achieve this, the client will first unmarshal the yaml blob returned by the server and then proceed to iterate the list of applications included in the bundle. For each application, the client attempts to fetch its configuration from the server and checks whether the appropriate trust key is set. If that happens to be the case it will set the RequiresTrust key in the appropriate ApplicationSpec entry. Finally, the patched BundleData is marshaled back to yaml and returned back to the operator as usual.

QA steps

$ juju bootstrap lxd test --no-gui

$ export JUJU_DEV_FEATURE_FLAGS=trusted-bundles

# Deploy a bundle with a single app requiring trust
$ juju deploy testcharms/charm-repo/bundle/aws-integrator-trust-single/bundle.yaml --trust

$ juju export-bundle
applications:
  aws-integrator:
    charm: cs:~containers/aws-integrator-10
    num_units: 1
    to:
    - "2"
    trust: true      <- this is what you are looking for
  ubuntu-lite:
    charm: cs:~jameinel/ubuntu-lite-7
    num_units: 1
    to:
    - "3"
machines:
  "2": {}
  "3": {}
series: bionic

## Try against an older controller (2.5, 2.6 etc)
$ unset JUJU_DEV_FEATURE_FLAGS
$ juju bootstrap lxd older-controller --no-gui

# NOTE: older deploy does not support --trust
$ juju deploy testcharms/charm-repo/bundle/aws-integrator-trust-single/bundle.yaml
$ juju trust aws-integrator

# The following invocation will cause the juju client to locally patch the exported bundle
# NOTE: make sure to use the juju client from this PR
$ juju export-bundle
applications:
  aws-integrator:
    charm: cs:~containers/aws-integrator-10
    num_units: 1
    to:
    - "2"
    trust: true      <- this is what you are looking for
  ubuntu-lite:
    charm: cs:~jameinel/ubuntu-lite-7
    num_units: 1
    to:
    - "3"
machines:
  "2": {}
  "3": {}
series: bionic

achilleasa added some commits Jun 5, 2019

Bump Bundle API version to V3
This bump allows the CLI code to check whether the server exposes the
trust flag for exported bundles or whether the client needs to query the
configuration of each application and patch the returned yaml code
locally.
Patch exportbundle output to include trust flag for older controllers
The previous commit added server-side support for including the trust
flag in exported bundles. However, to maintain compatibility with older
controllers that don't expose the flag, the client uses API version
sniffing to decide whether it needs to patch the exported bundle yaml
to include the trust flags.

The client-side path fallback simply unpacks the yaml blob, fetches the
configuration settings for each application in the bundle and toggles
the trust flags for the applications whose configuration indicates that
they have been trusted by the operator. Finally, the patched bundle is
marshaled again and returned to the caller.
@manadart
Copy link
Member

left a comment

Code and QA look good here.

@achilleasa

This comment has been minimized.

Copy link
Contributor Author

commented Jun 5, 2019

$$merge$$

@jujubot jujubot merged commit c9ccaa9 into juju:2.6 Jun 5, 2019

1 of 2 checks passed

merge-multi-juju CI Run in progress
Details
check-multi-juju Build finished.
Details

@achilleasa achilleasa deleted the achilleasa:expose-trust-key-when-exporting-bundles branch Jun 5, 2019

jujubot added a commit that referenced this pull request Jun 6, 2019

Merge pull request #10290 from achilleasa/remove-trusted-bundles-feat…
…ure-flag

#10290

## Description of change

Now that all the moving parts of the trusted bundles feature are in place and we cannot break any future release, we can safely remove the feature flag introduced by #10262.

NOTE: this PR should not be merged before #10289 lands.

## Documentation changes

@pmatulis this change will allow us to ship this feature with the next 2.6.x release so we should ensure that any relevant docs are updated before that time.

@manadart manadart referenced this pull request Jun 6, 2019

Merged

Merge 2.6 into develop #10294

jujubot added a commit that referenced this pull request Jun 6, 2019

Merge pull request #10294 from manadart/2.6-into-develop
#10294

## Description of change

Merge 2.6 into develop bringing forward:
- #10293 from manadart/2.5-into-2.6
- #10290 from achilleasa/remove-trusted-bundles-feature-flag
- #10291 from wallyworld/agent-suicide
- #10292 from howbazaar/2.6-fix-metrics
- #10289 from achilleasa/expose-trust-key-when-exporting-bundles
- #10286 from howbazaar/2.6-clock-dependency
- #10285 from achilleasa/support-trust-flag-when-deploying-bundles
- #10279 from achilleasa/allow-operators-to-force-override-deployment-of-non-trusted-bundles
- #10268 from wallyworld/cloud-cli-feature-flag
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.