Extend the mega-watcher to report opened port changes. #1588

Merged
merged 4 commits into from Feb 12, 2015

Conversation

Projects
None yet
5 participants
Member

frankban commented Feb 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:

  • bootstrap an environment;
  • deploy and expose the juju-gui charm;
  • while the unit is installed, the mega-watcher should
    report an empty list in both ports and port ranges;
  • when the deployment completes and the unit is in
    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/)

LGTM

state/megawatcher.go
- 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

rogpeppe Feb 11, 2015

Owner

or, given that port ranges are usually single numbers in practice make([]network.Port, 0, len(portRanges))

@dimitern

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.

state/megawatcher.go
+ return nil
+ case *multiwatcher.MachineInfo:
+ // Retrieve the machine.
+ m, err := st.Machine(info.Id)
@rogpeppe

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

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.

state/megawatcher.go
+ return errors.Trace(err)
+ }
+ }
+ default:
@rogpeppe

rogpeppe Feb 11, 2015

Owner

Looks like this default case can be removed.

@frankban

frankban Feb 12, 2015

Member

Indeed, done.

state/megawatcher.go
+ return nil
+ }
+ info0 := store.Get(parentId)
+ switch info := info0.(type) {
@rogpeppe

rogpeppe Feb 11, 2015

Owner

just:

 switch info := store.Get(parentId).(type) {

should be fine, I think.

state/megawatcher.go
+ return errors.New("cannot retrieve entity id for unit")
+ }
+ info0 := store.Get(eid)
+ switch oldInfo := info0.(type) {
@rogpeppe

rogpeppe Feb 11, 2015

Owner
switch oldInfo := store.Get(eid).(type) {
state/megawatcher.go
+// 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

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))
@frankban

frankban Feb 12, 2015

Member

Done in a way similar to what you suggested.

+ err = u.OpenPort("tcp", 4242)
+ c.Assert(err, jc.ErrorIsNil)
+
+ return testCase{
@dimitern

dimitern Feb 11, 2015

Contributor

FWIW, this test is becoming huge and unmanageable, we should split it to smaller (saner?) blocks.

@frankban

frankban Feb 12, 2015

Member

I'd leave this for another branch, focused on refactoring this long test.

Contributor

dimitern commented Feb 11, 2015

@frankban #1560 is soon to be reverted by #1589 to unblock master, you'll need to integrate the original fix into this PR as well.

Member

frankban commented Feb 12, 2015

Thanks for the reviews!
$$merge$$

Contributor

jujubot commented Feb 12, 2015

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

jujubot added a commit that referenced this pull request Feb 12, 2015

Merge pull request #1588 from frankban/megawatcher-ports-null
Extend the mega-watcher to report opened port changes.

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:
- bootstrap an environment;
- deploy and expose the juju-gui charm;
- while the unit is installed, the mega-watcher should
  report an empty list in both ports and port ranges;
- when the deployment completes and the unit is in
  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/)

@jujubot jujubot merged commit 679ca6f into juju:master Feb 12, 2015

frankban added a commit to frankban/juju that referenced this pull request Feb 12, 2015

jujubot added a commit that referenced this pull request Feb 12, 2015

Merge pull request #1594 from frankban/megawatcher-ports-null-backpor…
…t-1.22

Extend the mega-watcher to report opened port changes.

This is a backport for #1588

(Review request: http://reviews.vapour.ws/r/924/)

frankban added a commit to frankban/juju that referenced this pull request Feb 12, 2015

jujubot added a commit that referenced this pull request Feb 12, 2015

Merge pull request #1595 from frankban/megawatcher-ports-null-backpor…
…t-1.21

Extend the mega-watcher to report opened port changes.

This is a backport for #1588

(Review request: http://reviews.vapour.ws/r/925/)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment