Added support for ExtraBindings in Meta #191

Merged
merged 6 commits into from Mar 1, 2016

Conversation

Projects
None yet
4 participants

dimitern commented Mar 1, 2016

Added an optional extra-bindings metadata section, with the following format:

...
extra-bindings:
   name1:
   other-name2:
   ...

None of the names in the extra-bindings map can match existing provided/required/peer relation
names, as relations are already bindable. Extra bindings provide a way to declare named endpoints,
which the charm needs (bound) addresses for, but which are not relations otherwise.

Extra bindings will be accepted in $ juju deploy --bind ... when declared, in a follow-up.

Also added a Meta.CombinedRelations() helper, fixing http://pad.lv/1520623 bug as a result.

From a UX POV, it would be better to accumulate all errors cases.

Owner

dimitern replied Mar 1, 2016

I didn't want to complicate the code further, but fair enough - will do as you suggest, as good UX is precious ;)

+ bindingsMap := data.(map[interface{}]interface{})
+ result := make(map[string]ExtraBinding)
+ for name, _ := range bindingsMap {
+ stringName := name.(string)
@jameinel

jameinel Mar 1, 2016

Owner

is it ok to do blind casts like this? Doesn't that cause a panic if it isn't a string?

@dimitern

dimitern Mar 1, 2016

Yes, because parseMetaExtraBindings (like other similar helpers for resources, payloads, storage, etc.) are called once the top-level charm schema has been Coerce()d, which guarantees "extra-bindings" will be a schema.Map() (as defined above, including having non-empty string keys) or else parseMeta() and this func won't be even called. There is also a test for a non-map extra-bindings.

Owner

jameinel commented Mar 1, 2016

I had one comment, but otherwise LGTM

"that is not a relation."

Owner

dimitern replied Mar 1, 2016

Will do.

"may" or "should". If "may" what's supported?

Owner

dimitern replied Mar 1, 2016

Neither - just forgot to update this doc comment. It should be "must not match..."

typo "valueLabel"

Owner

dimitern replied Mar 1, 2016

Will fix this.
EDIT: No longer used actually, now part of the schema package.

Seems to read better as "missing binding name"

Owner

dimitern replied Mar 1, 2016

Sure, sounds better.

Do these values help trigger/test all the type.(string) assertions?

Owner

dimitern replied Mar 1, 2016

Actually, this test is no longer needed, as the same thing is more extensively tested in schema.Nil() tests.
As I replied earlier, I think the type assertions are quite safe, as charmSchema.Coerce() called before parsing the values ensures at least the types match.

Any reason not to assign to meta.extraBindings because if there's an error we return err. (On reflection maybe not possible with the ':=').

Owner

dimitern replied Mar 1, 2016

Indeed - the := makes it awkward as it's either this or the equivalent:

var err error
meta.ExtraBindings, err = parseMetaExtraBindings(m["extra-bindings"])
if err != nil {
    return nil, err
}

Perhaps the above is better though, will change.

Some cosmetic quibbles/typos, but LGTM.

dimitern commented Mar 1, 2016

Thanks for the reviews! All issues fixed, setting to $$merge$$.

Contributor

jujubot commented Mar 1, 2016

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju-charm

jujubot added a commit that referenced this pull request Mar 1, 2016

Merge pull request #191 from dimitern/v6-unstable-extra-bindings
Added support for ExtraBindings in Meta

Added an optional `extra-bindings` metadata section, with the following format:
```yaml
...
extra-bindings:
   name1:
   other-name2:
   ...
```
None of the names in the extra-bindings map can match existing provided/required/peer relation
names, as relations are already bindable. Extra bindings provide a way to declare named endpoints,
which the charm needs (bound) addresses for, but which are not relations otherwise.

Extra bindings will be accepted in $ juju deploy --bind ... when declared, in a follow-up.

Also added a Meta.CombinedRelations() helper, fixing http://pad.lv/1520623 bug as a result.

@jujubot jujubot merged commit 8edb23e into juju:v6-unstable Mar 1, 2016

@dimitern dimitern deleted the dimitern:v6-unstable-extra-bindings branch Mar 1, 2016

jujubot added a commit that referenced this pull request Mar 2, 2016

Merge pull request #192 from dimitern/v6-unstable-extra-bindings-bund…
…ledata

Added support for extra-bindings within BundleData

Following up on #191, this PR allows extra-bindings
to work when deploying bundles containing charm with extra-bindings in their metadata.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment