Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On Tue, Jul 08, 2014 at 06:44:19PM -0700, Josh Triplett wrote:
On Wed, Jul 09, 2014 at 01:16:04AM +, Jóhann B. Guðmundsson wrote:
On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
On Tue, Jul 08, 2014 at 10:45:11PM +, 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 +, 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=
PRETTY_HOSTNAME does not equate to description, and in any case is
not the same thing as a deployment environment.
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...
Distribution unit files will never use ConditionDeployment; only
admin-created or admin-modified unit files will. Given that, it will
work perfectly without a standardized set of names. Just specify that
DEPLOYMENT contains a keyword *such as* (but not limited to)
production or development, and then state that ConditionDeployment
can specify a keyword. That will work perfectly without limiting the
set of possible keywords.
+1
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
[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 +, 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.
Debian has a file /etc/debian_chroot, used to describe the nature of a
chroot environment, such as i386 cross for a 32-bit build chroot, or
similar. The default prompt then incorporates that string. This seems
quite similar, and I'd love to see a standardized mechanism for that
kind of string.
Rather than limiting this list to a few specific tokens, could we just
provide a MachineRole or similar, which accepts a short freeform text
string? Then, a staged deployment system could use this for
development/staging/production/validation/replication/blue/whatever,
while another type of system can use its own tokens here.
As general guidance, we could say something like MachineRole should
consist of a space-separated series of printable tokens, such as
'production' or 'staging'.. This also allows MachineRole to contain
something like staging foobranch, for instance, which indicates a
staging server that's part of the experimental parallel foobranch
infrastructure.
This would still allow the role string to serve its primary functions:
querying it to check for particular values used within an organization,
or inserting it into prompts, window titles, and similar.
- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
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 +, 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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
On Tue, Jul 08, 2014 at 10:45:11PM +, 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 +, 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
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On Wed, Jul 09, 2014 at 01:16:04AM +, Jóhann B. Guðmundsson wrote:
On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
On Tue, Jul 08, 2014 at 10:45:11PM +, 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 +, 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=
PRETTY_HOSTNAME does not equate to description, and in any case is
not the same thing as a deployment environment.
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...
Distribution unit files will never use ConditionDeployment; only
admin-created or admin-modified unit files will. Given that, it will
work perfectly without a standardized set of names. Just specify that
DEPLOYMENT contains a keyword *such as* (but not limited to)
production or development, and then state that ConditionDeployment
can specify a keyword. That will work perfectly without limiting the
set of possible keywords.
- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
