----- Original Message ----- > On 22/01/12 10:05, Eduardo Warszawski wrote: > > > > > > ----- Original Message ----- > >> On 22/01/12 09:39, Eduardo Warszawski wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> On 22/01/12 08:28, Eduardo Warszawski wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> On Wed, Jan 18, 2012 at 06:17:53AM -0500, Ayal Baron wrote: > >>>>>>>> Can we broaden the scope and also allow passing createVG > >>>>>>>> partitioned devices with an override flag or something? > >>>>>>>> (we'd > >>>>>>>> need > >>>>>>>> to check the devices and run "kpartx -d" and fdisk to clean > >>>>>>>> the > >>>>>>>> devices before calling pvcreate). > >>>>>>> > >>>>>>> We can, and we should. My initial patch is just the bare > >>>>>>> minimum; > >>>>>>> I'd > >>>>>>> like > >>>>>>> Douglas to carry it on, and I am still waiting to meet his > >>>>>>> Engine > >>>>>>> counterpart. > >>>>>>> Currently, a LUN that was once used as a raw hard disk cannot > >>>>>>> be > >>>>>>> used > >>>>>>> by RHEV; > >>>>>>> that's sad. > >>>>>>> > >>>>>>> How about this for API: > >>>>>>> > >>>>>>> createVG(self, vgname, devlist, > >>>>>>> options={trashpart_devlist: > >>>>>>> []}) > >>>>>> > >>>>>> No, stop using options as a trash can. > >>>>>> If we're changing the API, it should already be just passing a > >>>>>> LUNs > >>>>>> dictionary to createStorageDomain and start deprecating > >>>>>> createVG > >>>>> > >>>>> Was agreed that createVG and all vg-uuid aware functions will > >>>>> be > >>>>> removed shortly. > >>>>> Use only createStorageDomain. > >>>>> > >>>> > >>>> When you write 'removed'? you don't actually mean remove, right? > >>> Yes, I do. > >>> The flows are simpler from the RHEV-M and VDSM sides. > >> > >> I agree. > >> > >>> VG's can be created, removed, etc. using lvm tools. > >>> VDSM is only about Storage Domains and not a VG manager. > >> > >> I agree > >> > >>> What's the point of creating a VG using VDSM if not for building > >>> a > >>> SD? > >> > >> Backwards compatibility. > > For backwards compatibility we don't need to develop further the > > createVG interface. > > If the API is changed createStorageDomain should receive the device > > dict > > (as Ayal said), and then we can mockup the createVG part, as we > > already do with the > > formatStorageDomain-removeVG functions. > > I don't expect you to further develop the createVG verb only not to > remove it. > In addition you should take into consideration that the engine is > going > to keep using the current createVG flow, not because we like it > simply > because making the change for running another flow is not prioritized > ATM, so please make sure everything is working the same.
You're asking the wrong question hence getting the wrong answers. vdsm is committed to backward compatibility of 1 version, hence no verb will be actually 'removed' from vdsm API until a new verb has been introduced and used side by side for at least 1 version. This is *always* true and if this is broken it is a bug that will be fixed. Now that we've got that out of the way, wrt the current flow - no changes should be made in createVG, only in createStorageDomain. > > > > > >> > >>> Therefore it should be a unique operation in the API. > >>> > >>>> > >>>> > >>>>>> > >>>>>>> > >>>>>>> createVG would honor an optional list of devices (subset of > >>>>>>> devlist) > >>>>>>> whose > >>>>>>> partition tables should be trashed. > >>>>>>> > >>>>>>> Dan. > >>>>>>> > >>>>>> > >>>> > >>>> > >> > >> > > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel