Re: [Engine-devel] [vdsm] RFC: New Storage API
- Original Message -
> From: "Shu Ming"
> To: "Saggi Mizrahi"
> Cc: "Adam Litke" , "engine-devel" ,
> "VDSM Project Development"
>
> Sent: Monday, December 10, 2012 10:33:23 PM
> Subject: Re: [vdsm] RFC: New Storage API
>
> 2012-12-11 4:36, Saggi Mizrahi:
> >
> > - Original Message -
> >> From: "Adam Litke"
> >> To: "Saggi Mizrahi"
> >> Cc: "Shu Ming" , "engine-devel"
> >> , "VDSM Project Development"
> >>
> >> Sent: Monday, December 10, 2012 1:39:51 PM
> >> Subject: Re: [vdsm] RFC: New Storage API
> >>
> >> On Thu, Dec 06, 2012 at 11:52:01AM -0500, Saggi Mizrahi wrote:
> >>>
> >>> - Original Message -
> From: "Shu Ming"
> To: "Saggi Mizrahi"
> Cc: "VDSM Project Development"
> , "engine-devel"
>
> Sent: Thursday, December 6, 2012 11:02:02 AM
> Subject: Re: [vdsm] RFC: New Storage API
>
> Saggi,
>
> Thanks for sharing your thought and I get some comments below.
>
>
> Saggi Mizrahi:
> > I've been throwing a lot of bits out about the new storage API
> > and
> > I think it's time to talk a bit.
> > I will purposefully try and keep implementation details away
> > and
> > concentrate about how the API looks and how you use it.
> >
> > First major change is in terminology, there is no long a
> > storage
> > domain but a storage repository.
> > This change is done because so many things are already called
> > domain in the system and this will make things less confusing
> > for
> > new-commers with a libvirt background.
> >
> > One other changes is that repositories no longer have a UUID.
> > The UUID was only used in the pool members manifest and is no
> > longer needed.
> >
> >
> > connectStorageRepository(repoId, repoFormat,
> > connectionParameters={}):
> > repoId - is a transient name that will be used to refer to the
> > connected domain, it is not persisted and doesn't have to be
> > the
> > same across the cluster.
> > repoFormat - Similar to what used to be type (eg. localfs-1.0,
> > nfs-3.4, clvm-1.2).
> > connectionParameters - This is format specific and will used to
> > tell VDSM how to connect to the repo.
>
> Where does repoID come from? I think repoID doesn't exist before
> connectStorageRepository() return. Isn't repoID a return value
> of
> connectStorageRepository()?
> >>> No, repoIDs are no longer part of the domain, they are just a
> >>> transient handle.
> >>> The user can put whatever it wants there as long as it isn't
> >>> already taken by another currently connected domain.
> > disconnectStorageRepository(self, repoId)
> >
> >
> > In the new API there are only images, some images are mutable
> > and
> > some are not.
> > mutable images are also called VirtualDisks
> > immutable images are also called Snapshots
> >
> > There are no explicit templates, you can create as many images
> > as
> > you want from any snapshot.
> >
> > There are 4 major image operations:
> >
> >
> > createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
> > userData={}, options={}):
> >
> > targetRepoId - ID of a connected repo where the disk will be
> > created
> > size - The size of the image you wish to create
> > baseSnapshotId - the ID of the snapshot you want the base the
> > new
> > virtual disk on
> > userData - optional data that will be attached to the new VD,
> > could
> > be anything that the user desires.
> > options - options to modify VDSMs default behavior
> >
> > returns the id of the new VD
> I think we will also need a function to check if a a VirtualDisk
> is
> based on a specific snapshot.
> Like: isSnapshotOf(virtualDiskId, baseSnapshotID):
> >>> No, the design is that volume dependencies are an implementation
> >>> detail.
> >>> There is no reason for you to know that an image is physically a
> >>> snapshot of another.
> >>> Logical snapshots, template information, and any other
> >>> information
> >>> can be set by the user by using the userData field available for
> >>> every image.
> >> Statements like this make me start to worry about your userData
> >> concept. It's a
> >> sign of a bad API if the user needs to invent a custom metadata
> >> scheme for
> >> itself. This reminds me of the abomination that is the 'custom'
> >> property in the
> >> vm definition today.
> > In one sentence: If VDSM doesn't care about it, VDSM doesn't manage
> > it.
> >
> > userData being a "void*" is quite common and I don't understand why
> > you would thing it's a sign of a bad API.
> > Further more, giving the user choice about how to represent it's
> > own metadata and what fields it want to keep seems reasonable to
> > me.
> > Especially given the fact that VDSM never reads it.
> >
> > The
Re: [Engine-devel] Request power-user status for mom project in jenkins
On Tue, Dec 11, 2012 at 11:24:07AM -0500, Eyal Edri wrote: > [adding engine-devel] > > usually there is an official vote on each new power user for jenkins, > and as long as there are no objections it is approved. > > since i know you're a mom maintainer and familiar with jenkins, i vote +1. I trust Adam (who is mom's maintainer), and trust that he is capable of becoming familiar with jenkins without causing pain to other users. +1 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] another datamodel cleanup
Hi, Another datamodel cleanup patch is waiting for review: http://gerrit.ovirt.org/9824 Thx, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Request power-user status for mom project in jenkins
[adding engine-devel] usually there is an official vote on each new power user for jenkins, and as long as there are no objections it is approved. since i know you're a mom maintainer and familiar with jenkins, i vote +1. Eyal. - Original Message - > From: "Adam Litke" > To: in...@ovirt.org > Cc: ee...@redhat.com > Sent: Tuesday, December 11, 2012 6:11:45 PM > Subject: Request power-user status for mom project in jenkins > > Hi all, > > I am the maintainer of the mom sub-project. Recently we upgraded the > mom build > process to use autotools. Unfortunately this has broken the Jenkins > build for > the project. Rather than asking here whenever I need an update to > the build > job, I think it makes sense for me to administer that myself. If > there is > agreement about this, could someone help me to acquire the relavent > permissions? > > Thanks! > > -- > Adam Litke > IBM Linux Technology Center > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Trusted Compute Pools
Oved Ourfalli wrote on 2012-12-11: > >> A dummy question: where is the engine config file? >> > The engine configuration is in the database, in the vdc_options table. > You can edit it manually. > > In an installed environment we also have the engine-config utility, which > allows > to modify existing configuration entries. Thanks for the information. It seems necessary for me to setup a installed environment to get more familiar with oVirt configuration & usage. Jimmy smime.p7s Description: S/MIME cryptographic signature ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] compatibility version
- Original Message - > From: "Livnat Peer" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Tuesday, December 11, 2012 2:35:13 PM > Subject: Re: [Engine-devel] compatibility version > > On 11/12/12 15:26, Laszlo Hornyak wrote: > > Hi, > > > > When I install an ovirt engine from scratch, the Default DC is set > > to Compatibility version 3.1, but when I create a new DC, it's > > Compatibility version is set to 3.2 by default. Is this > > intentional? Why? > > > > Looks like a bug. Ok, sent a patch: http://gerrit.ovirt.org/9844 > I think that when we added 3.2 support we did not change the > pre-defined > DC to match it (BTW - I guess it should be fixed for default cluster > as > well). yes, the same is true for cluster. > > > > Laszlo > > ___ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] compatibility version
On 11/12/12 15:26, Laszlo Hornyak wrote: > Hi, > > When I install an ovirt engine from scratch, the Default DC is set to > Compatibility version 3.1, but when I create a new DC, it's Compatibility > version is set to 3.2 by default. Is this intentional? Why? > Looks like a bug. I think that when we added 3.2 support we did not change the pre-defined DC to match it (BTW - I guess it should be fixed for default cluster as well). > Laszlo > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] compatibility version
Hi, When I install an ovirt engine from scratch, the Default DC is set to Compatibility version 3.1, but when I create a new DC, it's Compatibility version is set to 3.2 by default. Is this intentional? Why? Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Trusted Compute Pools
- Original Message - > From: "Gang Wei" > To: "Itamar Heim" > Cc: engine-devel@ovirt.org, "James Rankin" , "Oved > Ourfalli" , "Barak > Azulay" , "Michal Skrivanek" , > "Buddy Cao" , "Jeff > Ruby" , "Gang Wei" > Sent: Tuesday, December 11, 2012 1:35:59 PM > Subject: RE: [Engine-devel] Trusted Compute Pools > > Itamar Heim wrote on 2012-11-30: > > for a POC patch i suggest: > > 1. use vm custom level property as simpler for first phase then > > changing > the db scheme. > > 2. use bare minimum engine config support for service > location/authentication. > > A dummy question: where is the engine config file? > The engine configuration is in the database, in the vdc_options table. You can edit it manually. In an installed environment we also have the engine-config utility, which allows to modify existing configuration entries. Oved > Jimmy > > > 3. assume no plugins and just add the code to the relevant part in > > RunVM > which filters the > > relevant hosts: > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Trusted Compute Pools
Itamar Heim wrote on 2012-11-30: > for a POC patch i suggest: > 1. use vm custom level property as simpler for first phase then changing the db scheme. > 2. use bare minimum engine config support for service location/authentication. A dummy question: where is the engine config file? Jimmy > 3. assume no plugins and just add the code to the relevant part in RunVM which filters the > relevant hosts: smime.p7s Description: S/MIME cryptographic signature ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Inherited Permissions from System
- Original Message - > From: "Ravi Nori" > To: engine-devel@ovirt.org > Sent: Monday, December 10, 2012 5:05:33 PM > Subject: [Engine-devel] Inherited Permissions from System > > I am currently working on a bug to show the inherited permissions on > an > object. > > So if the user has permissions assigned on a Cluster, the user should > have permissions on the VMs in the cluster. > > My question is if the user has permissions on the System, should the > permissions be inherited to all the entities? In a word: yes. > > Link to the bug > > https://bugzilla.redhat.com/show_bug.cgi?id=871365 > > Thanks > > Ravi > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
