Yes sorry, it used to be in the migrations.
Anyways, I can certainly see a requirement for both cases here.
Although I think in the first point, seeds.rb does not have to be explicitly
used for things that would otherwise break the WUI. We could certainly
add some initial defaults in there too, in particular Front End HWP's since
these are now completely independent.
So thinking on the same lines as sseago, I think a good idea is to add a small
x86_64 and small i386 as a bare minimum. Then at a later date if we add support
for configuration, this would certainly be best placed in some config file. But
I feel the most straight forward way to add this atm, is same way as we add default
pool / quota etc... through the seeds. Then maybe change it later.
Cheers
Martyn
From: "Mo Morsi" <mmorsi(a)redhat.com>
To: "Martyn Taylor" <mtaylor(a)redhat.com>
Cc: aeolus-devel(a)lists.fedorahosted.org
Sent: Tuesday, 15 March, 2011 2:08:12 PM
Subject: Re: [deltacloud-devel] Post Installation: New HWP Model
On 03/15/2011 07:00 AM, Martyn Taylor wrote:
Hey Mo,
I think the idea here is to add some default values, for HWPs. Since we now have the
notion
of front end HWPs which are completey independent of any particular provider. We could
add these
default values in the same way add default pool, default quota etc... which I believe is
in
the migrations.
Cheers
Martyn
Well the default pool / quota / etc are currently in the database seeds
not the migrations. The thing is, this data is required for the
conductor to work properly, eg the db seeds need to be setup to create
the permissions and the initial / default objects which those
permissions will be applied on, else the Conductor WUI will be broken
and throw errors.
By contrast, I'm talking about adding optional data to the conductor db
via configure. Things such as setting up new additional core providers
and creating the necessary entities in the providers table. This isn't
strictly needed for the conductor WUI to work properly, but will lead to
a much richer and more accessible aeolus experience right off the bat.
This all can be optional / configurable of course. We should be able to
have it so we can select the amount of data which is initially used
(from the bare minimum which we have now, to a full blown dataset, ready
to be used to launch an instance with one or two clicks).
-Mo