Add offer info to status #7698

Merged
merged 2 commits into from Aug 4, 2017

Conversation

Projects
None yet
3 participants
Owner

wallyworld commented Aug 2, 2017

Description of change

When run on the offering model, juju status now displays information about offers and what connections there are to those offers.
We also add to the offer connection entity in state the source model uuid so that can be passed to status also.

QA steps

Run a cmr scenario and run status on the offering model.
Model Controller Cloud/Region Version SLA
default ian localhost/localhost 2.3-alpha1.1 unsupported

App Version Status Scale Charm Store Rev OS Notes
mysql 5.7.19 active 1 mysql jujucharms 57 ubuntu

Unit Workload Agent Machine Public address Ports Message
mysql/0* active idle 0 10.200.103.104 3306/tcp Ready

Machine State DNS Inst id Series AZ Message
0 started 10.200.103.104 juju-e593b5-0 xenial Running

Offer User Relation id Status Endpoint Interface Role
mysql admin 1 active db mysql provider
mysql admin 2 active db mysql provider

Relation Provides Consumes Type
cluster mysql mysql peer

Looks good - just a couple of questions.

- units map[string]map[string]*state.Unit
- latestCharms map[charm.URL]*state.Charm
- leaders map[string]string
+ consumerRemoteApplications map[string]*state.RemoteApplication
@babbageclunk

babbageclunk Aug 4, 2017

Member

I don't understand what consumerRemoteApplications means. Or rather, I can see two possible opposite meanings. Is it remote applications that represent the consumer (ie we're on the offering side of the CMR)? Or remote applications that consume an offer (so we're on the consuming side, and the remote application is a proxy for an offered application)?

(I have the same problem with isConsumerProxy actually.)

@wallyworld

wallyworld Aug 4, 2017

Owner

consumerRemoteApplications are the RemoteApplication entities in the consuming model. These correspond to the act of consuming an offer.
isConsumerProxy is true in the RemoteApplication entity in the offering model, ie a proxy for a consuming app in the consumer's model.

-// fetchRemoteApplications returns a map from application name to remote application.
-func fetchRemoteApplications(st Backend) (map[string]*state.RemoteApplication, error) {
+// fetchConsumerRemoteApplications returns a map from application name to remote application.
+func fetchConsumerRemoteApplications(st Backend) (map[string]*state.RemoteApplication, error) {
@babbageclunk

babbageclunk Aug 4, 2017

Member

Actually, based on this definition I don't know why it's called that - isn't it all remote applications?

@wallyworld

wallyworld Aug 4, 2017

Owner

Both offering and consuming models have remote application entities. But we don't show these in the offering model as they are meaningless to the user. They are just the glue and have made up names.

// fetchRelations returns a map of all relations keyed by application name.
//
// This structure is useful for processApplicationRelations() which needs
// to have the relations for each application. Reading them once here
// avoids the repeated DB hits to retrieve the relations for each
// application that used to happen in processApplicationRelations().
-func fetchRelations(st Backend) (map[string][]*state.Relation, error) {
+func fetchRelations(st Backend) (map[string][]*state.Relation, map[int]*state.Relation, error) {
@babbageclunk

babbageclunk Aug 4, 2017

Member

Should update the doc comment to indicate what the other return is.

+ isRemote := false
+ for _, ep := range relation.Endpoints() {
+ if app, err := st.RemoteApplication(ep.ApplicationName); err == nil {
+ if app.IsConsumerProxy() {
@babbageclunk

babbageclunk Aug 4, 2017

Member

So would a better name for this be IsOfferingSide? (Also, is it possible for an app to participate in two different CMRs, one on the offering side and one on the consuming side?)

Sorry, these are quite Friday-afternoon review questions. :)

@wallyworld

wallyworld Aug 4, 2017

Owner

The idea of calling it a ConsumerProxy is because it directly represents a proxy to an app on the consuming side. But IsOfferingSide() works too. Maybe as a drive by next time? Yes, an app can relate to both something on the offering side (eg a subordinate or other collaborating app) and something remote (typically via different endpoints).

@@ -148,6 +150,39 @@ func (s remoteApplicationStatus) MarshalYAML() (interface{}, error) {
return remoteApplicationStatusNoMarshal(s), nil
}
+type offerStatusNoMarshal offerStatus
@babbageclunk

babbageclunk Aug 4, 2017

Member

Oh, is it because it's not embedded then it hides the Marshal* methods? Expanding a bit I can see it's all through the package, so I guess that's just how we do this?

@wallyworld

wallyworld Aug 4, 2017

Owner

Yep, that's the trick we use to stop infinite recursion.

Owner

wallyworld commented Aug 4, 2017

$$merge$$

Contributor

jujubot commented Aug 4, 2017

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

@jujubot jujubot merged commit 8c0b4ed into juju:develop Aug 4, 2017

1 check passed

continuous-integration/jenkins/pr-merge This commit looks good
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment