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 < [email protected]> 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 <[email protected]> > wrote: > >> Yes, absolutely. >> >> On Tue, Aug 5, 2014 at 8:33 PM, Domas Monkus <[email protected]> >> 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 >> > <[email protected]> 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 >> >> <[email protected]> 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 < >> [email protected]> >> >>> 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) >> >>>> <[email protected]> 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 >> >>>> > <[email protected]> >> >>>> > 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 >> >>>> >> [email protected] >> >>>> >> Modify settings or unsubscribe at: >> >>>> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >>>> >> >> >>>> > >> >>>> > >> >>>> > -- >> >>>> > Juju-dev mailing list >> >>>> > [email protected] >> >>>> > Modify settings or unsubscribe at: >> >>>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >>>> > >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> >> >>>> gustavo @ http://niemeyer.net >> >>>> >> >>>> -- >> >>>> Juju-dev mailing list >> >>>> [email protected] >> >>>> Modify settings or unsubscribe at: >> >>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >>> >> >>> >> >>> >> >>> -- >> >>> Juju-dev mailing list >> >>> [email protected] >> >>> Modify settings or unsubscribe at: >> >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >>> >> >> >> >> >> >> -- >> >> Juju-dev mailing list >> >> [email protected] >> >> Modify settings or unsubscribe at: >> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> >> > >> > >> > -- >> > Juju-dev mailing list >> > [email protected] >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > >> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
