On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
On Tue, Jul 08, 2014 at 10:45:11PM +0000, "Jóhann B. Guðmundsson" wrote:
>
>On 07/08/2014 10:45 PM, Josh Triplett wrote:
> >[Responding to this version because the latest thread hasn't appeared in
> >the mbox archives yet.  The comments apply equally well to the latest
> >version, "Add DEPLOYMENT to hostnamectl".]
> >
> >On Tue, Jul 08, 2014 at 12:38:50AM +0000, Jóhann B. Guðmundsson wrote:
> >>+static bool valid_environment(const char *environment) {
> >>+
> >>+        assert(environment);
> >>+
> >>+        return nulstr_contains(
> >>+                        "development\0"
> >>+                        "staging\0"
> >>+                        "production\0",
> >>+                        environment);
> >>+}
> >Can we please*not*  attempt to limit or "standardize" this particular
> >set of machine roles?  As already demonstrated in the previous thread,
> >people have all sorts of staged deployment strategies.  Furthermore,
> >the concept of a machine role shouldn't be limited to service deployment
> >strategies.
> >
>
>Roles != the environment they run in.
I'm not trying to bikeshed over the naming of the variable itself.  I'm
arguing that standardizing this particular bit of metadata won't work
well when so many different deployment strategies exist.  Thus, rather
than having a fixed set of keywords, I'd propose simply saying "this
contains keywords", and leaving the specific keywords up to the admin.
If you attempt to standardize production/development/staging, you'll
either end up with a model that only works for a small subset of
deployments, or you'll end up adding twelve more keywords, at which
point you might as well have just said "use whatever keyword you like".

The 4 tier covers the majority of the models since more or less the entire internet recommend three tier model including M$ [1] Anyone wanting to extend that further can do so using the "PRETTY_HOSTNAME="

This patch is very specific to deployment environment and to solve a very specific long standing problem and to achieve that we need to a standardize, if we dont we can just as well drop this patch since in the long run we cannot introduce something like "ConditionDeployment=" like David mentioned and it kinda defeat's my purpose working in this in the firsplace...

1. http://msdn.microsoft.com/en-US/library/cc982570%28v=bts.10%29.aspx
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to