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 <j...@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.bent...@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@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
