fuel-dev team mailing list archive

[Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>]

Arbitrary scripts, yes, but there is a limit to what is proper in RPM world
to run during %pre and %post. One simple guideline to meet is you should be
able to install and run the entire script during anaconda install from CD
with no networking. This means no network access, knowledge of system
hostname, IP, user folders, input from a user, or expectation of a robust
RNG for generating hashes (can be improvised).
The blocker in our case, however, is you cannot run posgresql as a daemon
or expect it to be running. If you can ship binary copies of the db initial
state, you could simply install them in place like a backup.

Really, all enterprise vendors try to avoid this 100% unattended install
mode from packaging. It is more common to bundle a script with sane
defaults and support an answerfile. That doesn't quite line up with our
model today, but I believe we could improve Fuel Setup to support setup on
already installed nodes and do necessary checks we handle in Anaconda. I
always wanted to see package installs, custom repo selection, and puppet
run inside Fuel Setup to give the user a better experience
On Mar 15, 2014 12:47 AM, "Vladimir Kozhukalov" <vkozhukalov@xxxxxxxxxxxx>
wrote:

> Matt,
>
> Great to know that at least one person (except me) thinks it is a viable
> idea to make user able to deploy master node not depending on ISO.
>
> AFAIK, both deb and rpm packages can run arbitrary scripts during
> post-installation stage. And I remember when Ubuntu came out with their
> Juju based openstack deployment scheme they used to rely totally on deb
> post install scripts during deployment their Cobbler+Juju master node.
> Besides, at least when you use deb packages it is possible to interact with
> user using debconf dialog.
>
> Anyway, Docker containers seem to be an appropriate solution for this use
> case, at least in a short term perspective.
>
>
>
>
>
>
>
>
> Vladimir Kozhukalov
>
>
> On Fri, Mar 14, 2014 at 7:34 AM, Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>wrote:
>
>> Vladimir,
>>
>> This may be achievable as part of my work with moving Fuel master node
>> services into individual Docker containers. See my blueprint here:
>>
>> https://blueprints.launchpad.net/fuel/+spec/fuel-containerization-of-services
>>
>> One big advantage of using these containers is you could use any Linux
>> OS (with network namespaces support) to host these containers.
>>
>> The only concern I have with trying to install on an existing server
>> is to make sure that there are no services listening on the ports we
>> need to use for Fuel master (such as an existing web server).
>>
>> Installing Fuel from packages, however, would be really great for
>> upstream distributions who think our code is cool enough to ship in
>> mainstream OSes. The biggest drawback is we tune and apply changes to
>> lots of services (Cobbler, rabbitMQ, postgres) in ways that really
>> should never be done from a package manager. Instead, we would need to
>> distribute a big script that an admin runs after install to apply the
>> needed configuration. This script could be still in puppet, of course.
>>
>> On Fri, Mar 14, 2014 at 5:00 AM, Vladimir Kozhukalov
>> <vkozhukalov@xxxxxxxxxxxx> wrote:
>> > All,
>> >
>> > There is an interesting use case we do not cover at the moment. What if
>> > someone wants to deploy master node on a server which is already in use
>> and
>> > has OS installed on it. Would it be great to have the possibility to
>> deploy
>> > master node from packages just running a script?
>> >
>> >
>> > What do you think about it?
>> >
>> >
>> > Vladimir Kozhukalov
>> >
>> > --
>> > Mailing list: https://launchpad.net/~fuel-dev
>> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~fuel-dev
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>
>