imo, no, its a no-op. the end state is still the same. if its an error, and now we have partial failure modes to consider against ranges.
On Tue, Aug 5, 2014 at 1:25 PM, David Cheney <david.che...@canonical.com> wrote: > Yes, absolutely. > > On Tue, Aug 5, 2014 at 8:33 PM, Domas Monkus <domas.mon...@canonical.com> > wrote: > > A follow-up question: should closing a port that was not opened previous > to > > that result in an error? > > > > Domas > > > > > > On Fri, Jun 27, 2014 at 2:13 PM, Matthew Williams > > <matthew.willi...@canonical.com> wrote: > >> > >> +1 on an opened-ports hook tool, I've added it to the task list > >> > >> > >> On Fri, Jun 27, 2014 at 9:41 AM, William Reade > >> <william.re...@canonical.com> wrote: > >>> > >>> Agreed. Note, though, that we'll want to give charms a way to know what > >>> ports they have already opened: I think this is a case where > >>> look-before-you-leap maybe beats > easier-ask-forgiveness-than-permission (and > >>> the consequent requirement that error messages be parsed...). An > >>> opened-ports hook tool should do the trick. > >>> > >>> > >>> On Thu, Jun 26, 2014 at 9:18 PM, Gustavo Niemeyer < > gust...@niemeyer.net> > >>> wrote: > >>>> > >>>> +1 to Mark's point. Handling exact matches is much easier, and does > >>>> not prevent a fancier feature later, if there's ever the need. > >>>> > >>>> On Thu, Jun 26, 2014 at 3:38 PM, Mark Ramm-Christensen (Canonical.com) > >>>> <mark.ramm-christen...@canonical.com> wrote: > >>>> > My belief is that as long as the error messages are clear, and it is > >>>> > easy to > >>>> > close 8000-9000 and then open 8000-8499 and 8600-9000, we are fine. > >>>> > Of > >>>> > course it is "nicer" if we can do that automatically for you, but I > >>>> > don't > >>>> > see why we can't add that later, and I think there is a value in > >>>> > keeping a > >>>> > port-range as an atomic data-object either way. > >>>> > > >>>> > --Mark Ramm > >>>> > > >>>> > > >>>> > On Thu, Jun 26, 2014 at 2:11 PM, Domas Monkus > >>>> > <domas.mon...@canonical.com> > >>>> > wrote: > >>>> >> > >>>> >> Hi, > >>>> >> me and Matthew Williams are working on support for port ranges in > >>>> >> juju. > >>>> >> There is one question that the networking model document does not > >>>> >> answer > >>>> >> explicitly and the simplicity (or complexity) of the implementation > >>>> >> depends > >>>> >> greatly on that. > >>>> >> > >>>> >> Should we only allow units to close exactly the same port ranges > that > >>>> >> they > >>>> >> have opened? That is, if a unit opens the port range [8000-9000], > can > >>>> >> it > >>>> >> later close ports [8500-8600], effectively splitting the previously > >>>> >> opened > >>>> >> port range in half? > >>>> >> > >>>> >> Domas > >>>> >> > >>>> >> -- > >>>> >> 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 > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> gustavo @ http://niemeyer.net > >>>> > >>>> -- > >>>> 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 > >> > > > > > > -- > > 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
