On 1 August 2013 10:29, olivier sallou <[email protected]> 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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/camcogxesfc7pdpo9rf5rw0e6tcfrntle15fgqw6pzbvgtoz...@mail.gmail.com
