Port ranges - restricting opening and closing ranges

[Domas Monkus]

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.thangavelu at 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.cheney at canonical.com>
> wrote:
>
>> Yes, absolutely.
>>
>> On Tue, Aug 5, 2014 at 8:33 PM, Domas Monkus <domas.monkus at 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.williams at 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.reade at 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 <
>> gustavo at 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-christensen at 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.monkus at 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 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
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>> gustavo @ http://niemeyer.net
>> >>>>
>> >>>> --
>> >>>> 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
>> >>>
>> >>
>> >>
>> >> --
>> >> 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
>> >
>>
>> --
>> 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/20140805/eb1c4e6a/attachment.html>