hi,
i'm trying to setup foreman using our current puppetdb schema. but running
RAILS_ENV=production bundle exec rake db:migrate
fails with
PG::Error: ERROR: integer out of range
: INSERT INTO "schema_migrations" ("version") VALUES (20090714132448)
looking at the table definition within puppetdb shows that version is
defined as an integer:
\d schema_migrations;
Table "public.schema_migrations"
Column | Type | Modifiers
···
---------+-----------------------------+-----------
version | integer | not null
time | timestamp without time zone | not null
Indexes:
"schema_migrations_pkey" PRIMARY KEY, btree (version)
i’ve got a second environment where we used a dedicated schema for forman
and there version is defined as a varchar(255):
\d schema_migrations;
Table "public.schema_migrations"
Column | Type | Modifiers
------------±----------------------------±----------
version | character varying(255) | not null
created_at | timestamp without time zone |
Indexes:
“unique_schema_migrations” UNIQUE, btree (version)
whats the exact advantage of sharing the db schema with puppetdb?
should i open a bug report?
thanks
toni
Don’t forget, there is no security | toni at stderr dot at
– Wulfgar | Toni Schmidbauer
Foreman doesn't support db-sharing with puppetdb I'm afraid (and we're
deprecating db-sharing entirely from 1.1 onwards). Set Foreman up with it's
own database, it's more robust in the long term anyway.
Greg
···
On 26 March 2013 08:24, Toni Schmidbauer wrote:
hi,
i’m trying to setup foreman using our current puppetdb schema. but running
thanks for the clarification. the documentation on this subject is a
little bit confusing:
···
At Tue, 26 Mar 2013 10:15:01 +0000, Greg Sutcliffe wrote:
> Foreman doesn't support db-sharing with puppetdb I'm afraid (and we're
> deprecating db-sharing entirely from 1.1 onwards). Set Foreman up with it's
> own database, it's more robust in the long term anyway.
3.5 Configuration
Foreman uses a database, this database can be shared with Puppet
store-configs (they are compatible, as Foreman extends the puppet
database schema).
puppet storeconfig via activerecord is deprecated and you should/have
to use puppetdb. so i assumed sharing the schema with puppetdb would
be ok.
thanks
toni
Don’t forget, there is no security | toni at stderr dot at
– Wulfgar | Toni Schmidbauer
Are there any good docs on how best to migrate from a shared storeconfig db
to separate dbs without losing functionality?
Thanks,
Greg
···
On Tuesday, March 26, 2013 7:00:45 AM UTC-4, Toni Schmidbauer wrote:
>
> At Tue, 26 Mar 2013 10:15:01 +0000, > Greg Sutcliffe wrote:
> > Foreman doesn't support db-sharing with puppetdb I'm afraid (and we're
> > deprecating db-sharing entirely from 1.1 onwards). Set Foreman up with
> it's
> > own database, it's more robust in the long term anyway.
>
> thanks for the clarification. the documentation on this subject is a
> little bit confusing:
>
> ---
> 3.5 Configuration
>
> Foreman uses a database, this database can be shared with Puppet
> store-configs (they are compatible, as Foreman extends the puppet
> database schema).
> ---
>
> puppet storeconfig via activerecord is deprecated and you should/have
> to use puppetdb. so i assumed sharing the schema with puppetdb would
> be ok.
>
> thanks
> toni
> --
> Don't forget, there is no security | toni at stderr dot at
> -- Wulfgar | Toni Schmidbauer
>
It's pretty easy, and there are a few ways to do it. The easiest is to use
the fact that puppet will completely recreate it's db over the course of a
run-interval. So you just point puppet at an empty db and let foreman
continue using the old one.
If thats not acceptable, we also provide a rake task for shifting data
between dbs (convert:prod2dev). That's covered in the manual.
You'll also need to update your ENC processor and set facts=true,
storeconfigs=false.
That's about it.
Greg
···
On 27 March 2013 13:19, Greg Etling wrote:
Are there any good docs on how best to migrate from a shared storeconfig
db to separate dbs without losing functionality?
dunno, in our current testing environment we started with a separate
foreman database schema.
i think you will not loose any functionality if you
-
add foreman.rb to the puppet reports directory and add
reports = foreman
to puppet.conf so that foreman receives the puppet reports (see the
docs)
-
use the foreman node.rb ENC to upload facts to foreman (or
the cronjob as mentioned in the docs).
i'm still in learning mode, so this is just a guess. maybe someone
with more insight/experience is willing to comment on these points.
toni
···
At Wed, 27 Mar 2013 06:19:19 -0700 (PDT), Greg Etling wrote:
> Are there any good docs on how best to migrate from a shared storeconfig db
> to separate dbs without losing functionality?
–
Don’t forget, there is no security | toni at stderr dot at
– Wulfgar | Toni Schmidbauer
(resurrecting an old thread)
As far as I can tell, using the rake task to split the foreman db out from
the puppet db would involve the following steps:
setup new empty db for foreman
#service apache stop(foreman & puppetmaster rack)
#rake db:migrate RAILS_ENV=production
Configure new foreman database as 'development' in settings.yml
#rake db:migrate RAILS_ENV=development
#rake db:convert:prod2dev
Configure new foreman database as 'production' and remove puppet database
settings in settings.yml
Edit /etc/puppet/node.rb (from foreman-installer external_node.rb.erb):
Set - :storeconfigs => false,
(:facts is already => true)
#service apache start(foreman & puppetmaster rack)
1 - Is this complete?
2 - I would be leaving storeconfigs=true in my puppet.conf (not moving to
PuppetDB yet)…or is there no reason for storeconfigs at all with the
separate db?
3 - Is there a way to safely clean out the foreman tables from the
resulting puppet-only database?
Thanks,
Greg
···
On Wednesday, March 27, 2013 9:59:55 AM UTC-4, Greg Sutcliffe wrote:
>
> On 27 March 2013 13:19, Greg Etling <get...@stern.nyu.edu >wrote:
>
>> Are there any good docs on how best to migrate from a shared storeconfig
>> db to separate dbs without losing functionality?
>
>
> It's pretty easy, and there are a few ways to do it. The easiest is to use
> the fact that puppet will completely recreate it's db over the course of a
> run-interval. So you just point puppet at an empty db and let foreman
> continue using the old one.
>
> If thats not acceptable, we also provide a rake task for shifting data
> between dbs (convert:prod2dev). That's covered in the manual.
>
> You'll also need to update your ENC processor and set facts=true,
> storeconfigs=false.
>
> That's about it.
> Greg
>
Heya,
> As far as I can tell, using the rake task to split the foreman db out from
> the puppet db would involve the following steps:
>
> setup new empty db for foreman
>
> #service apache stop(foreman & puppetmaster rack)
> #rake db:migrate RAILS_ENV=production
>
> Configure new foreman database as 'development' in settings.yml
>
> #rake db:migrate RAILS_ENV=development
> #rake db:convert:prod2dev
>
> Configure new foreman database as 'production' and remove puppet database
> settings in settings.yml
>
> Edit /etc/puppet/node.rb (from foreman-installer external_node.rb.erb):
>
> Set - :storeconfigs => false,
>
> (:facts is already => true)
>
>
> #service apache start(foreman & puppetmaster rack)
>
>
> 1 - Is this complete?
>
Almost, you also need to update node.rb if you're using our ENC. If you're
downtime-sensitive, you can create the dev db before stopping apache, as
you don't need to freeze things until you start copying data out of
production.
2 - I would be leaving storeconfigs=true in my puppet.conf (not moving to
> PuppetDB yet)…or is there no reason for storeconfigs at all with the
> separate db?
>
My comment about storeconfigs=false appiles to node.rb, not puppet.conf.
Whther you need it in puppet.conf is up to you, Foreman doesn't care once
the dbs are separate, although I don't see much point to an ActiveRecord db
without it 
> 3 - Is there a way to safely clean out the foreman tables from the
> resulting puppet-only database?
>
The old AR db, as I recall, is ephemeral - puppet recreates the data as
each host checks in, and no historical data is kept. Thus, when I migrated
my db, i just pointed puppet at an entirely new, clean database and let it
recreate the data. You mileage may vary, of course - I wouldn't advocate
dropping a db until you've tested this
HTH
Greg
···
On 11 July 2013 22:19, Greg Etling wrote:
