2013/8/1 Anders Ingemann <[email protected]> > 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. >
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
