Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Add offer info to status #7698
Conversation
babbageclunk
approved these changes
Aug 4, 2017
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
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
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
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
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) { |
| + isRemote := false | ||
| + for _, ep := range relation.Endpoints() { | ||
| + if app, err := st.RemoteApplication(ep.ApplicationName); err == nil { | ||
| + if app.IsConsumerProxy() { |
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
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
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?
|
$$merge$$ |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
wallyworld commentedAug 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