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

[Gustavo Niemeyer]

FWIW, *"open-ports --close-others"* feels pretty simple and
uncontroversial, even more when it comes from a core developer that
apparently would be implementing the feature himself to solve his own pain
points. Golden case.



On Sat Nov 01 2014 at 2:58:42 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.
>
> 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/20141103/5db57ee6/attachment.html>