supplement open--port/close-port with ensure-these-and-only-these-ports?

[Kapil Thangavelu]

On Sat, Nov 1, 2014 at 12:58 PM, John Meinel <john at arbash-meinel.com> wrote:

> I believe there is already "opened-ports" to tell you what ports Juju is
> currently tracking.
>

That's cool and news to me, it looks like it landed in trunk earlier on
october 2nd (ie 1.21) and hasn't made release notes or docs yet. Especially
for charm environment changes we really need corresponding docs as charm
env changes are not easily discover-able otherwise. Really great to see
that land as its been a common issue for charms and one that previously
forced them into state management.

cheers,

Kapil


> As for the rest, "open-port" only takes a single port (or range), which
> means that if you wanted only 80 and 8080 open, you would need a different
> syntax. (something that lets you specify multiple ports/ranges to be
> opened).
>
> I can see a point to it, but we do already have "opened-ports" if you're
> looking for the behavior you want.
>
> John
> =:->
>
> On Sat, Nov 1, 2014 at 6:13 PM, Aaron Bentley <aaron.bentley at canonical.com
> > wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi all,
>>
>> I take a stateful approach to writing charms.  That is, my charms
>> determine what the target state is, then take whatever actions are
>> needed to get the unit into that state, paying as little attention to
>> the current state as is possible.
>>
>> open-port / close-port require knowledge of the current state; if I
>> know that I want only port 314 open, then I need to know whether any
>> other ports are open and close them.  In most cases, a charm only
>> opens specific ports, so I know which ports to close.
>>
>> Right now, I'm writing an update to the Apache2 charm that would allow
>> the user to specify which ports to serve http on, which means that
>> when a user changes the port, I may need to close the old port and
>> open the new one.  If I want to use close-port / open-port, I need to
>> track what ports are open.  But juju already knows this, so I
>> shouldn't have to track it separately-- that violates DRY.
>>
>> The smallest change would be to provide a way to list the open ports,
>> so that charms can close any open ports they no longer want open.  But
>> that leaves a bunch of work for a stateful charm author.  What they
>> actually want is a command that ensures specific ports are open and
>> closes all others.
>>
>> ensure-these-and-only-these-ports was the first thing I thought of,
>> but we could extend open-port instead.  open-port would need to accept
>> multiple ports, not just ranges, and it would need to accept a
>> - --close-all-others flag, that would close all open ports not listed.
>>
>> Does that seem like a sensible change?
>>
>> Aaron
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJUVOo3AAoJEK84cMOcf+9h2acIAL5ogJIy4O23TKa/RiWUcv0E
>> wX9NHpNj9r7P8LoEHwUN/0nIeLi0UPQtDMN/w2orKGK01oXsPvvoVy/SPmMH+8G+
>> yjOWQY1ppjB42vFsdLlP1d6VFutI94hiLEFgfT1ss9JSbPZXteakoKmhG3Og+W4e
>> pZSrvVjccZPp3IhSsGclfVxVJLD+lMYxXL7NA/x4ji74YMiUE8pH3OCbCeOjderw
>> oHlDMPClItugqvgAtCiHpr/n79yB75y1FARalsbXelXullgBLpiRxTQHgBq/yfn+
>> o22d1uCmp+xqIveyUS433RffEzMDDt61UaZTuyui8ZG9n4/Jy9xOpKN9wGDhhvE=
>> =gzrL
>> -----END PGP SIGNATURE-----
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141101/1e245b6a/attachment.html>