Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
cmr: Add remote spaces and bindings to remote applications #7319
Conversation
babbageclunk
added some commits
May 4, 2017
wallyworld
requested changes
May 9, 2017
Some initial concerns about layering to be fixed.
| @@ -1146,9 +1147,7 @@ func (s *MigrationExportSuite) newResource(c *gc.C, appName, name string, revisi | ||
| func (s *MigrationExportSuite) TestRemoteApplications(c *gc.C) { | ||
| // NOTE: the key 'c#<name>' isn't overly useful for someone looking |
babbageclunk
May 9, 2017
Member
It was a comment that Tim added about the global key for remote applications - I guess he found leftover rows in the status collection and was trying to work out what collection they belonged to. Should I change the global key prefix for remote applications to something a bit easier to search for?
wallyworld
May 9, 2017
Owner
Ah sorry, my mistake. We use c# since metawatcher requires a single char global key and 'a' and 'r' are taken. We should look into that.
| - c.Skip("the remote application needs to export the assocated status " + | ||
| - "document for the remote application 'c#grave-rainbow'.") | ||
| - _, err := s.State.AddRemoteApplication(state.AddRemoteApplicationParams{ | ||
| + sApp, err := s.State.AddRemoteApplication(state.AddRemoteApplicationParams{ |
| + | ||
| +// RemoteSpace represents a space in another model that endpoints are | ||
| +// bound to. | ||
| +type RemoteSpace struct { |
wallyworld
May 9, 2017
Owner
Is there a reason why this isn't remoteSpaceDoc?
And remoteSubnetDoc below?
To match what's done for remoteEndpointDoc.
And there'd be a separate struct used for public use outside of state package. We want to layer mongo/state data structs separately from structs used outside of state. That's either done via embedding the fooDoc in a Foo struct, or using a help func to map between the unexported state struct doc and the exported public struct.
babbageclunk
May 9, 2017
Member
Ok - so we'd keep RemoteSpace and RemoteSubnet, but they'd just be what gets returned from RemoteApplication.Spaces(), and remoteSpaceDoc and remoteSubnetDoc (with the same attributes, respectively) would be what's stored in the remoteApplicationDoc?
| +} | ||
| + | ||
| +// RemoteSubnet represents a subnet in another model. Unfortunately we | ||
| +// can't reuse state.Subnet - it's tied to the subnets collection. |
wallyworld
May 9, 2017
Owner
We don't need this last sentence. We would not want to re-use state.Subnet regardless as that would be a layer violation.
|
$$merge$$ |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
|
Build failed: Tests failed |
|
Looks like a spurious failure in APIContextSuite.TestDomainCookie on Windows. $$merge$$ |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
|
Build failed: Tests failed |
|
Another one: DebugHooksServerSuite.TestRunHook :( $$merge$$ |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
babbageclunk commentedMay 9, 2017
Description of change
We need to capture provider-specific information about the spaces that remote application endpoints are bound to, so that we can use that information to decide whether we can use cloud-local addresses for units in cross-model relations.
Add
state.RemoteApplication.Spacesand.Bindings- these will be stored when a remote application is created. This information can then be used to decide what address should be used.Since these details won't change and don't need to be queried separately from the remote application they're stored in the remote application document rather than in a separate collection.
QA Steps
None at the moment - the space information won't be populated until a follow-up PR.