Re: build-debian-cloud : raw and open nebula support

2013/8/1 Anders Ingemann <anders@ingemann.de>

On 1 August 2013 10:29, olivier sallou <olivier.sallou@gmail.com> wrote:
> Hi Anders,
> my modifications (in my github clone) are done now to create a raw image
> that could be used for a basic virtualization and integrated with OpenNebula
> with the opennebula plugin.
> It also supports virtio disk virtualization.
>
> I tested images in my Open Nebula private cloud and it works fine.
>
> Would you like I create a pull request so that you integrate my plugins and
> my new provider (raw) in your repository, or should we first start to move
> some tasks to a *common* tasks directory.
>
> As I said in a previous email, we need to get common tasks to use plugins as
> they refer some provider tasks for the moment. This means that my new
> plugins (opennebula and user_packages) can only work with my provider for
> the moment.
>
> Basically, for my new provider, I only modified filesystem, boot and
> packages.
>
> I also modified security to give the possibility to the root user to connect
> via SSH with a user defined password. If it is not defined in manifest, then
> no password is generated and ssh access is denied. This could be integrated
> in a common security task.
>
> For info, I created a README.md in providers/raw to describe specific
> manifest file options. It would indeed be fine to get a small doc for each
> provider.
>
>
> Regards
>
> Olivier
>
> --
>
> gpg key id: 4096R/326D8438 (keyring.debian.org)
>
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438

This is great news!

> Would you like I create a pull request so that you integrate my plugins and
> my new provider (raw) in your repository, or should we first start to move
> some tasks to a *common* tasks directory.

No, lets merge first and optimize later. This way we always have a
common ancestor to fall back to if anything goes awry.

> This means that my new plugins (opennebula and user_packages)
> can only work with my provider for the moment.

I addressed some of this in the other mail, but we will certainly need
some indicator that prevents plugins from being used with incompatible
providers (or rather: with providers for which a plugin has not yet
been tested)

> I also modified security to give the possibility to the root user to connect
> via SSH with a user defined password. If it is not defined in manifest, then
> no password is generated and ssh access is denied. This could be integrated
> in a common security task.

This is made specifically for private images I suppose? Because it
does not make much sense for public ones.

Yes, this is for private images but it makes sense for private clouds or end user willing to create his own image for his sole use.

Olivier

I guess this is a simple feature which can be easily integrated into
the generic security task, yes.

> It would indeed be fine to get a small doc for each provider.

Yes, yes it would :-) But there was no sense in documenting a moving
target. I think we are getting closer to something stable though, so
documenting things starts making sense.

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438