[vdsm] Fedora, udev and nic renaming

Hi, We are currently working on stabilizing the networking part of vdsm in Fedora 18 and, to achieve that purpose, we decided to test in in both physical hosts and, for extra convenience and better support, also in VMs. Due to the move of Fedora 17 and 18 to systemd and newer udev versions, we en

Re: [vdsm] Fedora, udev and nic renaming

Thanks for this verbose description. I don't think using libguestfs is the solution for this. Fixing qemu to accept BIOS interface name at -net parameter is preferable. I don't think we should expose the interface a PCI device as it will have some drawbacks, but attempt to use the onboard conv

[vdsm] API.py validation

Hi all, I am currently working in adding a new feature to vdsm which requires a new entry point in vdsm, thus requiring: - Parameter definitions in vdsm_api/vdsmapi-schema.json - Implementation and checks in vdsm/API.py and other modules. Typically, we check for presence absence of required/optio

[vdsm] VDSM tasks, the future

Because I started hinting about how VDSM tasks are going to look going forward I thought it's better I'll just write everything in an email so we can talk about it in context. This is not set in stone and I'm still debating things myself but it's very close to being done. - Everything is asynch

[vdsm] link state semantics

Hi list! We are working on the new 3.2 feature for adding support for updating VM devices, more specifically at the moment network devices. There is one point of the design which is not yet consensual and we'd need to agree on a proper and clean design that would satisfy us all: My current prop

Re: [vdsm] Back to future of vdsm network configuration

- Original Message - > From: "Itamar Heim" > To: "Dan Kenigsberg" > Cc: "Alon Bar-Lev" , "VDSM Project Development" > , "Simon > Grinberg" , "Andrew Cathrow" > Sent: Monday, December 3, 2012 10:56:53 PM > Subject: Re: [vdsm] Back to future of vdsm network configuration > > On 12/03/2

Re: [vdsm] object instancing in the new VDSM API

Thanks for your detailed response... On Mon, Dec 03, 2012 at 09:26:34PM -0500, Saggi Mizrahi wrote: > So from what I gather the only thing that is bothering you is that storage > operations require a lot of IDs. I get that, I hate that to. It doesn't > change the point that it was designed that w

Re: [vdsm] Back to future of vdsm network configuration

On 12/04/2012 07:49 PM, Simon Grinberg wrote: - Original Message - From: "Itamar Heim" To: "Dan Kenigsberg" Cc: "Alon Bar-Lev" , "VDSM Project Development" , "Simon Grinberg" , "Andrew Cathrow" Sent: Monday, December 3, 2012 10:56:53 PM Subject: Re: [vdsm] Back to future of vdsm ne

Re: [vdsm] VDSM tasks, the future

On Tue, Dec 04, 2012 at 10:35:01AM -0500, Saggi Mizrahi wrote: > Because I started hinting about how VDSM tasks are going to look going forward > I thought it's better I'll just write everything in an email so we can talk > about it in context. This is not set in stone and I'm still debating thing

Re: [vdsm] API.py validation

On Tue, Dec 04, 2012 at 08:43:11AM -0500, Antoni Segura Puimedon wrote: > Hi all, > > I am currently working in adding a new feature to vdsm which requires a new > entry point in vdsm, thus requiring: > - Parameter definitions in vdsm_api/vdsmapi-schema.json > - Implementation and checks in vdsm/A

Re: [vdsm] link state semantics

On Tue, Dec 04, 2012 at 12:32:34PM -0500, Antoni Segura Puimedon wrote: > Hi list! > > We are working on the new 3.2 feature for adding support for updating VM > devices, more specifically at the moment network devices. > > There is one point of the design which is not yet consensual and we'd >

[vdsm] RFC: New Storage API

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

Re: [vdsm] VDSM tasks, the future

As the only subsystem to use asynchronous tasks until now is the storage subsystem I suggest going over how I suggest tackling task creation, task stop, task remove and task recovery. Other subsystem can create similar mechanisms depending on their needs. There is no way of avoiding it, different

Re: [vdsm] RFC: New Storage API

Thanks for sharing this. It's nice to have something a little more concrete to think about. Just a few comments and questions inline to get some discussion flowing. On Tue, Dec 04, 2012 at 04:52:40PM -0500, Saggi Mizrahi wrote: > I've been throwing a lot of bits out about the new storage API and

Re: [vdsm] RFC: New Storage API

- Original Message - > From: "Adam Litke" > To: "Saggi Mizrahi" > Cc: "VDSM Project Development" , > "engine-devel" > Sent: Tuesday, December 4, 2012 6:08:25 PM > Subject: Re: [vdsm] RFC: New Storage API > > Thanks for sharing this. It's nice to have something a little more > concre