7:11 a.m.
Hello everyone,
I am currently thinking about how CIAT's build/deploy behaviour should
be configured; these thoughts are fairly woolly but I would like to get
more opinions before I continue.
CIAT needs to know what to build and deploy. One way I have thought to
do this would be to have a list of the clusters one wants to monitor.
This list could then be parsed to determine which systems should be
built and which strata should be integrated with Firehose. perhaps
Firehose configurations should be predefined rather than generated. This
assumes that clusters are what users ultimately cares about; I would
like to know if this is the case. Building a system that is not wanted
can be very expensive in terms of time and resource so this needs to
thought about.
There is also a question of where this configuration should live. It
seems to me like it should be in Definitions because it defines the
behaviour of a tool relating to the Baserock project. Another option
would be that it has it's own repo.
Peoples thoughts on this would be much appreciated.
Thanks
Will
7:38 a.m.
On 28/09/15 12:11, Will Holland wrote:
Hello everyone,
I am currently thinking about how CIAT's build/deploy behaviour should
be configured; these thoughts are fairly woolly but I would like to get
more opinions before I continue.
CIAT needs to know what to build and deploy. One way I have thought to
do this would be to have a list of the clusters one wants to monitor.
This list could then be parsed to determine which systems should be
built and which strata should be integrated with Firehose. perhaps
Firehose configurations should be predefined rather than generated. This
assumes that clusters are what users ultimately cares about; I would
like to know if this is the case. Building a system that is not wanted
can be very expensive in terms of time and resource so this needs to
thought about.
There is also a question of where this configuration should live. It
seems to me like it should be in Definitions because it defines the
behaviour of a tool relating to the Baserock project. Another option
would be that it has it's own repo.
Peoples thoughts on this would be much appreciated.
My thinking is that the Firehose configuration is going to be large, and
people running their own CIAT instance will need to carefully tweak it
to suit their needs. So probably needs to go in its own repo, in the way
that Lorry Controller configuration does now:
http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.gi...
In general, I don't like adding new repos to the set of things people
need to know about -- people use Baserock and run their own
infrastructure already have to deal with upstream definitions, their
project's definitions, their local infrastructure.git repo, and their
local-config/lorries.git repo. So if it can be placed into
definitions.git cleanly, then that would be nice. But I can't imagine
how it would work without seeing it.
One thing I really *don't* want is for a CIAT instance to have a fixed
config set at the moment you run `morph deploy`. It's fine to allow
specifying a config there, but it needs to be configurable after
deployment as well. We made this mistake with Trove and distbuild
initially and had to spend time making it possible to 'generic'
instances later on. The 'generic' ones (where you can edit a file in the
system named /etc/trove/trove.conf, rerun trove-setup.service and the
configuration is then updated) are way more convenient.
Given that, if you have a file named /etc/ciat/ciat.conf with a setting
of 'where do I get all the instructions from', then we don't have to
decide right now where they should live. If we decide to keep them in
definitions.git we could set:
config-repo = git://git.baserock.org/baserock/baserock/definitions
config-path = ciat-config/
If we decide to keep them in a different repo we could set:
config-repo = git://git.baserock.org/local-config/ciat-config.git
config-path = ./
Hope this makes sense
Sam
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
7:42 a.m.
On 28/09/15 12:38, Sam Thursfield wrote:
In general, I don't like adding new repos to the set of things
people
need to know about -- people use Baserock and run their own
people *who* use
Baserock ...
infrastructure already have to deal with upstream definitions, their
project's definitions, their local infrastructure.git repo, and their
local-config/lorries.git repo. So if it can be placed into
definitions.git cleanly, then that would be nice. But I can't imagine
how it would work without seeing it.
One thing I really *don't* want is for a CIAT instance to have a fixed
config set at the moment you run `morph deploy`. It's fine to allow
specifying a config there, but it needs to be configurable after
deployment as well. We made this mistake with Trove and distbuild
initially and had to spend time making it possible to 'generic'
possible to
*build* ...
instances later on. The 'generic' ones (where you can edit a
file in the
system named /etc/trove/trove.conf, rerun trove-setup.service and the
configuration is then updated) are way more convenient.
Sam
Sam
I've sacked my email proofreader.
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
2799
days inactive
2799
days old
2 comments
2 participants
participants (2)
-
Sam Thursfield -
Will Holland