[10:07] <fwereade_> BradCrittenden, do you know offhand whether the GUI makes use of the magical NumUnits conversion in ServiceDeploy?
[10:07] <fwereade_> BradCrittenden, ie, if you request 0 units, you get 1
[10:07] <fwereade_> BradCrittenden, because I'm pretty sure this is crack, and I'm about to kill it
[10:09] <BradCrittenden> fwereade_: and a happy saturday morning to you!  :)
[10:09] <bac> fwereade_: no, the GUI will always make a reasonable request
[10:09] <fwereade_> bac, awesome, tyvm
[10:10] <bac> fwereade_: so you will return an error if 0 requested?
[10:11] <fwereade_> bac, I *think* it's legitimate, if odd -- there's nothing inconsistent about state if we honour that requst
[10:11] <fwereade_> bac, apart from anything else, you always get 0 units if you deploy a subordinate service
[10:12] <fwereade_> bac, I could maybe be convinced to error on 0, but it feels like extra code for little benefit
[10:13] <fwereade_> bac, medium-term I don't think that ServiceDeploy is sane anyway
[10:13] <fwereade_> bac, "deploy" is a ui nicety only
[10:14] <fwereade_> bac, it's at last 3 conceptually distinct operations
[10:14] <fwereade_> bac, add-charm, add-service, add-units
[10:14] <fwereade_> bac, (and add-units is questionable anyway as you know)
[10:16] <bac> fwereade_: the case for subordinates was not considered for requesting 0 units.
[10:16] <fwereade_> bac, I can't remember offhand if we error or if we ignore that in Conn
[10:17] <bac> the requirement we were working with was that a deployed service had to have >= 1 unit.
[10:17] <fwereade_> bac, I'm pretty sure we barf in cmd/juju if -n > 0
[10:18] <bac> so setting the number of units for a running service had that restriction too as that would effectively remove the service.
[10:20] <fwereade_> bac, my mental model is that a service can legitimately exist without units; I accept that's not a user-centric perspective but I think it's the job of the CLI/GUI layers to enforce that
[10:21] <fwereade_> bac, does that sound reasonable?
[10:23] <fwereade_> bac, (whereas the api and state layers should be concerned with internal consistency, and make every attempt to satisfy client requests that don't break that)
[10:24] <fwereade_> bac, (there's some tedium in that the outer layers may also want some sort of consistency checks if only to save on pointless roundtrips, but that's just a performance optimization)
[13:00] <fwereade_> bac, if you're around, how about magical inference of service name from charm name in ServiceDeploy? I'll be making a missing service name an error, I think