CMR concepts and scenarios #2248

pmatulis · 2017-10-20T18:37:50Z

This is presented in an unorthodox manner.
- One page has concepts and simplified command syntax.
- Two pages present scenarios that give more practical usage.
- Once stuff settles down I'm willing to refactor.
Another pass of the commands (and their outputs) will be necessary prior to 2.3 release. If the model or controller names are too long I can change them at this time.
The links to the scenarios are not obvious. Is this another style fail?
Another scenario should be added soon (TODO).

evilnick

Just some initial comments, I will have more!

evilnick · 2017-10-23T08:55:14Z

src/en/models-cmr-scene-1.md

 juju add-model wordpress-model
 juju deploy wordpress
 juju expose wordpress
 juju relate wordpress:db admin/cmr-model.mysql


we don't use relate, it is an alias

Do we keep juju status everywhere? It's an alias for juju show-status.

What is an alias vs not isn't that obvious to the user and I think that defaulting to the shortest commands is reasonable.

evilnick · 2017-10-23T09:04:01Z

src/en/charms-relations.md


 ```bash
-juju add-relation mediawiki:db mysql
+juju add-relation mysql mediawiki:db


why is the order reversed? I mean, it shouldn't matter, but we have always used order in the examples

To mirror the previous command: juju add-relation mysql wordpress.

What "order" are you talking about when you say "we have always used order in the examples"?

From the thing doing the giving, to the consumer. wordpress consumes mysql, as does mediawiki

So doesn't my new order follow your policy? You said the giver comes first. I've changed it so that mysql, the giver (doing the giving), comes first.

Yes, sorry it does now

evilnick · 2017-10-23T09:05:13Z

src/en/charms-relations.md

-relation interface identifier. In this case, we want MySQL to provide the 
-backend database for mediawiki ('db' relation), so this is what we need to 
-enter:
+The solution is to be explicit when referring to an *endpoint*, where the


If we are going to start calling these objects 'endpoints', I think we should actually introduce them a bit more than that

Right, I made this change minimal because it's not strictly a CMR thing, but it really needed changing. I didn't want to get caught in a rabbit hole. You want more of this here or do you want this done in another PR?

Maybe we should tack this on in a different pr when we have nailed down the CMR content

OK. I've left this text commented.

evilnick · 2017-10-23T09:08:24Z

src/en/models-cmr-scene-1.md


 This scenario describes a MediaWiki deployment, based within the same (LXD)
 controller; used by the admin user, and consumed by multiple models.



Maybe explain the cmr aspect of this in some way first. it is a bit confusing to go straight from this statement to creating a controller...

OK, but it is an example scenario, and I do refer to the main page for background information.

After re-reading it looks OK. The very first sentence says the scenario pertains to CMR (link). Do you really want me to re-defined what CMR is?

No, I just think this doesn't start well - it mentions mediawiki briefly and then suddenly you are building a controller (or actually, bizarrely, adding credentials).
I think the whole thing would work a lot better if we actually set out what we were going to do, and lay out some requirements (e.g. In this example we have a controller called xxx and a model called yyy. Nobody cares that it is on aws. Then you can start the actual tutorial with something that matters, like adding mysql.

OK, I thought your comment was for scenario 2. It makes more sense now.

evilnick · 2017-10-23T09:16:33Z

src/en/models-cmr-scene-1.md

 ```

-The output to `juju status` should eventually look similar to:
+!!! Note:


I don't think this note is very noteworthy

OK, but I wanted to make clear that a special CMR model is not required.

I'm not actually sure that is helped by showing people the steps to create a controller and a model. We could just state that we have started with a model called whatever, and leave it to the reader to set up whatever model/controller they want.

I feel that due to the various contexts (what controller, what model) it is important to be explicit.

I just think the note is distracting. If it is felt to be important to mention you can use any model, you could just mention that when you create the ones above. It isn't a big deal, it just feels like a big interruption for the reader for something minor(is)

I removed the Note.

evilnick · 2017-10-24T12:04:55Z

src/en/models-cmr-scene-2.md

 ```bash
-juju find-offers admin/default
-juju find-offers ian:admin/default
+juju find-offers lxd-cmr-1:admin/cmr-model-1


is it always necessary, when targeting a model, to include the user name too? I mean, it seems to be from my experiments, but is that really true?

I guess what I am saying is that I would assume

juju find-offers lxd-cmr-1:cmr-model-1

would work. It doesn't. Am I missing something?

The username pertains to the offering side and I don't see how the consuming side can guess what it is.

Sorry, I misunderstood.
So what you say makes sense and I tried it and it works for me. 🐰

juju find-offers lxd-cmr-1:cmr-model-1 Store URL Access Interfaces lxd-cmr-1 admin/cmr-model-1.mysql admin mysql:db

That is even more worrying! I will try again tomorrow

evilnick · 2017-10-24T12:47:30Z

src/en/models-cmr-scene-2.md

-
-In this case, the relate --via option is used to inform the offering side so
-that the correct firewall rules can be set up.
+This will work providing the offering side did not previously set up a


I find this paragraph confusing. Does this mean that it will work if no whitelist has been set?

I agree I can make it clearer. The answer to your question is yes, without a whitelist any request for a firewall rule will be accepted.

This is done, and with less words.

evilnick · 2017-10-24T13:00:31Z

src/en/models-cmr.md


 [`consume`][commands-consume]
-: Adds a remote offer to a model.
+: Adds a remote offer to a model without relating to it.


This is the most confusing one by far. IIUC, this is like a reverse offer, as in this case it is the 'consumer' saying, I would be happy for someone to provide me with this interface.

In which case:

I don't understand why this can't be done with the offer command anyhow - as far as anyone is concerned the relation is just a pipe and it doesn't matter what you label the ends

if we are doing it this way, the description needs to be a lot clearer (the help for this command also needs work)

Okay, having read some more I think I understand this better now. 'consume' is like, take up the offer, but don't attach it to anything, save it for later? How do you attach to it later? How do you know it exists?

The comments about the description still stand (this is a problem with ad-hoc gerunds).

Suggestions welcome 😺

How about : "Accepts an offer from a different model without immediately adding a relation to it. The offered application will subsequently appear as an application in the current model (e.g. in juju status) and a relation can made as with any other native application."

Or something

That's awfully long!

Adds is a word I had difficulty with here - it could be read as the user is "adding" (creating) the offer rather than consuming it. Also, I don't see why the explanation needs to be one line?

Because all the other commands have short descriptors. I'd like to avoid long lines here. I agree that it comes off as abrupt since these commands are listed from the outset, before the reader has a chance to digest anything. This is the same approach I took with storage. I asked for the team's opinion on that and the consensus was that it was fine.

What about "Links an offer to a model..."

It also doesn't help that the consume command is the very first one (due to the alphabetical order).

What is wrong with "accepts"?

It is fine when the descriptions actually work.

evilnick · 2017-10-24T13:05:05Z

src/en/models-cmr.md

 the same controller.

-`juju relate <application> <offer url>`
+`juju relate <application>[:<application endpoint>] <offer url>[:<offer endpoint>]`


add-relation

I suppose in the sense that offers are external objects, doing things this way around feels correct. I wonder if it would then make sense to change every other add-relation command in the docs

I'm not sure how it is more correct by using relate. I would like to stay consistent by not using aliases. Maybe I'm missing your point.

I meant the order of the application / offer url. Normally we do add-relation <provider> <consumer>

we should definitely use add-relation

evilnick · 2017-10-24T13:12:52Z

src/en/models-cmr.md

+An offer can be consumed without relating to it. This workflow sets up the
+proxy application in the consuming model and creates a user-defined alias for
+the offer. This latter is what's used to relate to. Having an offer alias can
+avoid a namespsce conflict with a pre-existing application.


pmatulis · 2017-10-25T16:22:17Z

I believe all your concerns have been addressed.

evilnick · 2017-10-26T13:38:33Z

Okay, we can probably merge this and continue to refine it.

One thing I think we ought to address is the use (maybe overuse) of CMR as an acronym to define what is going on here. We may call this feature CMR internally, but I'm not sure it makes sense to the user.

Peter Matulis added 10 commits October 13, 2017 03:28

scenario #1

113d3af

mostly scenario 2

9596094

ongoing

bd1c41e

continue review

91d7857

concepts

4c83aec

finish

7d49980

add set-firewall-rule; TODOs

3f0e5d9

s/interface/endpoint

42ba388

reword endpoint

4f9d37e

trivial

1091400

pmatulis requested a review from evilnick October 20, 2017 18:38

trivial

4147e7d

evilnick reviewed Oct 23, 2017

View reviewed changes

edits based on GH review

03bb49d

evilnick reviewed Oct 24, 2017

View reviewed changes

Peter Matulis added 4 commits October 24, 2017 15:29

edits based on GH review

b551846

trivial

eb0bee6

edits based on GH review

8505903

edits based on GH review

763ab8a

redefine show-offer; trivial cleanup

0d08fc3

evilnick approved these changes Oct 26, 2017

View reviewed changes

pmatulis merged commit 7942cf4 into juju:master Oct 26, 2017

pmatulis deleted the 2225-cmr-scenarios branch October 26, 2017 14:45


		This scenario describes a MediaWiki deployment, based within the same (LXD)
		controller; used by the admin user, and consumed by multiple models.

CMR concepts and scenarios #2248

CMR concepts and scenarios #2248

Uh oh!

Conversation

pmatulis commented Oct 20, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

evilnick left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pmatulis Oct 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evilnick Oct 24, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pmatulis commented Oct 20, 2017 •

edited

Loading

pmatulis Oct 25, 2017 •

edited

Loading

evilnick Oct 24, 2017 •

edited

Loading