+1 also:
close ports 90-110 -> error (cannot close part of a port range) close ports 80-110 -> error (mismatched port range?) On 5 August 2014 13:51, Domas Monkus <domas.mon...@canonical.com> wrote: > Ok, so the behavior would have to be: > opened ports : 80-100 > > close ports 60-70 -> no error (noop) > close ports 60-90 -> error (cannot close part of a port range) > close ports 80-100 -> no error > > I'm starting to think this scenario is preferrable, especially with respect > to the idempotency of charm hooks. > > Domas > > > On Tue, Aug 5, 2014 at 2:45 PM, Kapil Thangavelu > <kapil.thangav...@canonical.com> wrote: >> >> 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 > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
