Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Extend the mega-watcher to report opened port changes. #1588
Conversation
voidspace
commented
Feb 11, 2015
|
LGTM |
rogpeppe
reviewed
Feb 11, 2015
| - var compatiblePorts []network.Port | ||
| + // For backward compatibility, if there are no ports opened, return an | ||
| + // empty slice rather than a nil slice. | ||
| + compatiblePorts := make([]network.Port, 0) |
rogpeppe
Feb 11, 2015
Owner
or, given that port ranges are usually single numbers in practice make([]network.Port, 0, len(portRanges))
dimitern
Feb 11, 2015
Contributor
Commonly yes, but the whole point of having ranges is the ability to open e.g. a 1000 ports by specifying a single 5000-6000/tcp range, but OTOH having len(portRanges) as capacity by default is will perhaps be slightly more efficient and requiring less reallocations in 80% of the cases.
rogpeppe
reviewed
Feb 11, 2015
| + return nil | ||
| + case *multiwatcher.MachineInfo: | ||
| + // Retrieve the machine. | ||
| + m, err := st.Machine(info.Id) |
rogpeppe
Feb 11, 2015
Owner
It might be worth investigating if we can reasonably avoid this round-trip,
as all Machine.Units actually requires is the machine id, which we already have.
dimitern
Feb 11, 2015
Contributor
We could, if we had st.UnitsFor(machineId) hiding that dirty return &Machine{st:st, doc:machineDoc{Id:machineId}}}.Units() to save the round-trip into the state package where it belongs.
rogpeppe
reviewed
Feb 11, 2015
| + return errors.Trace(err) | ||
| + } | ||
| + } | ||
| + default: |
rogpeppe
reviewed
Feb 11, 2015
| + return nil | ||
| + } | ||
| + info0 := store.Get(parentId) | ||
| + switch info := info0.(type) { |
rogpeppe
Feb 11, 2015
Owner
just:
switch info := store.Get(parentId).(type) {
should be fine, I think.
rogpeppe
reviewed
Feb 11, 2015
| + return errors.New("cannot retrieve entity id for unit") | ||
| + } | ||
| + info0 := store.Get(eid) | ||
| + switch oldInfo := info0.(type) { |
dimitern
reviewed
Feb 11, 2015
| +// backingEntityIdForOpenedPortsKey returns the entity id for the given | ||
| +// openedPorts key. Any extra information in the key is discarded. | ||
| +func backingEntityIdForOpenedPortsKey(key string) (multiwatcher.EntityId, bool) { | ||
| + i := strings.Index(key, "#n") |
dimitern
Feb 11, 2015
Contributor
Since you're in the state package, how about this instead?
machineId, err := extractPortsIdParts(key)
if err != nil {
logger.Debugf("cannot parse ports key %q: %v", key, err)
return multiwatcher.EntityId{}, false
}
return backingEntityIdForGlobalKey(machineGlobalKey(machineId))
dimitern
reviewed
Feb 11, 2015
| + err = u.OpenPort("tcp", 4242) | ||
| + c.Assert(err, jc.ErrorIsNil) | ||
| + | ||
| + return testCase{ |
dimitern
Feb 11, 2015
Contributor
FWIW, this test is becoming huge and unmanageable, we should split it to smaller (saner?) blocks.
frankban
Feb 12, 2015
Member
I'd leave this for another branch, focused on refactoring this long test.
frankban
added some commits
Feb 12, 2015
|
Thanks for the reviews! |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
frankban commentedFeb 11, 2015
This fixes a regression causing opened ports not being
reported by the mega-watcher for units. A change in the
ports now generates a change in the unitInfo as expected
by the Juju API clients.
Also fix another backward incompatible API change in the way
empty ports are reported in the mega-watcher JSON: legacy
clients (e.g. python-jujuclient) expect an empty list, not
the null value resulting from marshaling a nil slice.
QA:
report an empty list in both ports and port ranges;
a started state, the mega-watcher API should correctly
report the juju-gui unit opened ports (80 and 443).
(Review request: http://reviews.vapour.ws/r/919/)