[10:07] BradCrittenden, do you know offhand whether the GUI makes use of the magical NumUnits conversion in ServiceDeploy? [10:07] BradCrittenden, ie, if you request 0 units, you get 1 [10:07] BradCrittenden, because I'm pretty sure this is crack, and I'm about to kill it [10:09] fwereade_: and a happy saturday morning to you! :) === BradCrittenden is now known as bac [10:09] fwereade_: no, the GUI will always make a reasonable request [10:09] bac, awesome, tyvm [10:10] fwereade_: so you will return an error if 0 requested? [10:11] bac, I *think* it's legitimate, if odd -- there's nothing inconsistent about state if we honour that requst [10:11] bac, apart from anything else, you always get 0 units if you deploy a subordinate service [10:12] bac, I could maybe be convinced to error on 0, but it feels like extra code for little benefit [10:13] bac, medium-term I don't think that ServiceDeploy is sane anyway [10:13] bac, "deploy" is a ui nicety only [10:14] bac, it's at last 3 conceptually distinct operations [10:14] bac, add-charm, add-service, add-units [10:14] bac, (and add-units is questionable anyway as you know) [10:16] fwereade_: the case for subordinates was not considered for requesting 0 units. [10:16] bac, I can't remember offhand if we error or if we ignore that in Conn [10:17] the requirement we were working with was that a deployed service had to have >= 1 unit. [10:17] bac, I'm pretty sure we barf in cmd/juju if -n > 0 [10:18] so setting the number of units for a running service had that restriction too as that would effectively remove the service. [10:20] 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] bac, does that sound reasonable? [10:23] 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] 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] 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