Re: build-debian-cloud : raw and open nebula support
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.
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.
Reply to: