From wudxw at linux.vnet.ibm.com  Wed Aug  1 12:59:14 2012
From: wudxw at linux.vnet.ibm.com (Mark Wu)
Date: Wed, 01 Aug 2012 20:59:14 +0800
Subject: Host network management roadmap inquiry
Message-ID: <50192822.9030309@linux.vnet.ibm.com>

Sorry for cross-posting!

I would like to inquiry about the roadmap of host network management in 
oVirt in order to
make sure the ideas to be worked on are welcomed by community.

I did some initial investigation on the following topics. I am not very 
familiar with them, so the information may contain some inaccuracies or 
errors.

netcf:

     It provides cross-platform network configuration library/tool by 
converting the XML definition of an interface into local config file. 
It's already used by libvirt to manage host network interfaces.It 
supports all network entities including bridge, vlan, bond, nic. And it 
also supports configuration rollback.  The benefit for vdsm is making 
host network stack configuration easy to port to other distros.

Problems found:
     It doesn't restore interface live state during config transaction 
now. There's a feature request submit for it.
     There're some advanced settings not supported in netcf, like 
'NM_CONTROLLED' and some less used bonding options.

     It doesn't provide python binding officially. But we can use 
libvirt API to integrate it into vdsm. It shouldn't have any impact on 
engine side.


IEEE 802.1Qbg(VEPA)

      It can offload network switching from server to external physical 
switch. It makes all VMs' traffic visible to physical switch, and 
therefore the existing switch functions (firewall, QoS etc) can be 
applied to VM immediately. The offload also frees up the server resource 
used by switching.
      Now libvirt supports it by using macvtap as vif and working with 
lldpad, which registers vif's mac/vlan information to the physical 
switch. We can just add a 'virtualport' element to an interface XML 
definition to add a VEPA interface. Probably, to support it in oVirt we 
still need configure lldpad  and query available VSI types for 
virtualport profile.


quantum

    Both the plugins openvswitch and linuxbridge stores abstract network 
entities (network, port) in database and create bridge/vlan via the tool 
ip/brctl or ovs-vsctl on demand. Only one bridge is created on one 
server and one vlan is created for each virtual network. That means that 
only one nic can be configured for vm network.  It doesn't configure nic 
or bond even if openvswitch also supports bond. Both of traditional 
network stack configuration and quantum will be supported oVirt for 
different purpose, right?

    Any comments? Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120801/36ed3a7c/attachment.html>

From acathrow at redhat.com  Wed Aug  1 13:56:54 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Wed, 1 Aug 2012 09:56:54 -0400 (EDT)
Subject: Host network management roadmap inquiry
In-Reply-To: <50192822.9030309@linux.vnet.ibm.com>
Message-ID: <414527091.1747093.1343829414123.JavaMail.root@redhat.com>


----- Original Message ----- 

> From: "Mark Wu" <wudxw at linux.vnet.ibm.com>
> To: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>,
> arch at ovirt.org
> Sent: Wednesday, August 1, 2012 8:59:14 AM
> Subject: Host network management roadmap inquiry

> Sorry for cross-posting!

> I would like to inquiry about the roadmap of host network management
> in oVirt in order to
> make sure the ideas to be worked on are welcomed by community.

> I did some initial investigation on the following topics. I am not
> very familiar with them, so the information may contain some
> inaccuracies or errors.

> netcf:

> It provides cross-platform network configuration library/tool by
> converting the XML definition of an interface into local config
> file. It's already used by libvirt to manage host network
> interfaces.It supports all network entities including bridge, vlan,
> bond, nic. And it also supports configuration rollback. The benefit
> for vdsm is making host network stack configuration easy to port to
> other distros.

> Problems found:
> It doesn't restore interface live state during config transaction
> now. There's a feature request submit for it.
> There're some advanced settings not supported in netcf, like
> 'NM_CONTROLLED' and some less used bonding options.

> It doesn't provide python binding officially. But we can use libvirt
> API to integrate it into vdsm. It shouldn't have any impact on
> engine side.

> IEEE 802.1Qbg(VEPA)

> It can offload network switching from server to external physical
> switch. It makes all VMs' traffic visible to physical switch, and
> therefore the existing switch functions (firewall, QoS etc) can be
> applied to VM immediately. The offload also frees up the server
> resource used by switching.
> Now libvirt supports it by using macvtap as vif and working with
> lldpad, which registers vif's mac/vlan information to the physical
> switch. We can just add a 'virtualport' element to an interface XML
> definition to add a VEPA interface. Probably, to support it in oVirt
> we still need configure lldpad and query available VSI types for
> virtualport profile.

> quantum

> Both the plugins openvswitch and linuxbridge stores abstract network
> entities (network, port) in database and create bridge/vlan via the
> tool ip/brctl or ovs-vsctl on demand. Only one bridge is created on
> one server and one vlan is created for each virtual network. That
> means that only one nic can be configured for vm network. It doesn't
> configure nic or bond even if openvswitch also supports bond. Both
> of traditional network stack configuration and quantum will be
> supported oVirt for different purpose, right?

good place to start : https://fedoraproject.org/wiki/Quantum_and_oVirt

> Any comments? Thanks!

> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch


From oschreib at redhat.com  Wed Aug  1 15:06:13 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 1 Aug 2012 11:06:13 -0400 (EDT)
Subject: oVirt 3.1 Release meeting - 2012-08-06
In-Reply-To: <822406079.3696561.1343833139938.JavaMail.root@redhat.com>
Message-ID: <537262635.3701270.1343833573919.JavaMail.root@redhat.com>

Hey,

We will have a release go/no go meeting on the upcoming Monday.

Meeting Time and Place:
 * Sunday, August 6th @ 15:00 UTC 
   * To see in your timezone date -d 'MONDAY 1000 EDT'
 * On IRC: #ovirt on irc.oftc.net

Feel free to join us.

---
Ofer Schreiber
oVirt Release Manager


From fabiand at redhat.com  Wed Aug  1 15:34:08 2012
From: fabiand at redhat.com (Fabian Deutsch)
Date: Wed, 01 Aug 2012 17:34:08 +0200
Subject: Host network management roadmap inquiry
In-Reply-To: <414527091.1747093.1343829414123.JavaMail.root@redhat.com>
References: <414527091.1747093.1343829414123.JavaMail.root@redhat.com>
Message-ID: <1343835248.2211.26.camel@fdeutsch-laptop.local>

Am Mittwoch, den 01.08.2012, 09:56 -0400 schrieb Andrew Cathrow:
> > From: "Mark Wu" <wudxw at linux.vnet.ibm.com>
> > Sent: Wednesday, August 1, 2012 8:59:14 AM
> > Subject: Host network management roadmap inquiry

<snip/>

> > quantum
> 
> > Both the plugins openvswitch and linuxbridge stores abstract network
> > entities (network, port) in database and create bridge/vlan via the
> > tool ip/brctl or ovs-vsctl on demand. Only one bridge is created on
> > one server and one vlan is created for each virtual network. That
> > means that only one nic can be configured for vm network. It doesn't
> > configure nic or bond even if openvswitch also supports bond. Both
> > of traditional network stack configuration and quantum will be
> > supported oVirt for different purpose, right?
> 
> good place to start :
> https://fedoraproject.org/wiki/Quantum_and_oVirt 

Hey,
besides these Quantum specific informations I'd also like to discuss
where oVirt is going wrt to networking.
Quantum is sure a nice solution for a project wide solution, but how can
or should this be integrated into the underlying components like vdsm or
node?

From a Node pov (feature as well as implementation wise) it is quite
interesting if we should switch to openvswitch (which can then in turn
used by quantum [via vdsm?]) or keep the linux bridge stuff.

There are also efforts on it's way (like teaming, the F17 feature) which
we should keep an eye on, as this seems to land in network manager as an
alternative(?) to the default bonding. It's also interesting how this
performs with openvswitch.

Many changes on many sides and we should lay out the path a bit to find
a direction where to go.
There is already

http://wiki.ovirt.org/wiki/Networking

which we could use to summarize the needed features, potential
techniques and an over all plan.

Greetings
fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120801/761445ed/attachment.sig>

From robert at middleswarth.net  Thu Aug  2 13:17:34 2012
From: robert at middleswarth.net (Robert Middleswarth)
Date: Thu, 02 Aug 2012 09:17:34 -0400
Subject: Moving Jenkins master ASAP
In-Reply-To: <312635177.6979553.1343821923529.JavaMail.root@redhat.com>
References: <312635177.6979553.1343821923529.JavaMail.root@redhat.com>
Message-ID: <501A7DEE.80108@middleswarth.net>

On 08/01/2012 07:52 AM, Eyal Edri wrote:
>
> ----- Original Message -----
>> From: "Robert Middleswarth" <robert at middleswarth.net>
>> To: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
>> Cc: infra at ovirt.org
>> Sent: Wednesday, August 1, 2012 6:02:06 AM
>> Subject: Re: Moving Jenkins master ASAP
>>
>> On 07/31/2012 07:12 PM, Ewoud Kohl van Wijngaarden wrote:
>>> On Tue, Jul 31, 2012 at 02:57:56PM -0400, Robert Middleswarth
>>> wrote:
>>>> On 07/31/2012 02:16 PM, Ewoud Kohl van Wijngaarden wrote:
>>>>> On Tue, Jul 31, 2012 at 07:52:25AM -0700, Karsten 'quaid' Wade
>>>>> wrote:
>>>>>> On 07/31/2012 07:44 AM, Karsten 'quaid' Wade wrote:
>>>>>>> We need to pick a new hosting solution for jenkins.ovirt.org.
>>>>>>>
>>>>>>> One idea is for us to throw out some favorite hosting providers
>>>>>>> here, and see if we can sort out what would be a good solution.
>>>>>> This post is what made me aware that EC2 would be a dead-end for
>>>>>> us
>>>>>> for now:
>>>>>>
>>>>>> http://blog.carlmercier.com/2012/01/05/ec2-is-basically-one-big-ripoff/
>>>>>>
>>>>>> In that post, the author used this host for comparison testing:
>>>>>>
>>>>>> http://joesdatacenter.com/
>>>>> My employer is a hosting provider so I'm somewhat biased here.
>>>> It not just about the provider.  I would need to see the bandwidth
>>>> charts on the current Jenkins but I assume Just about any provider
>>>> can handle it bandwidth needs.  But the server Jenkins Master
>>>> needs
>>>> to run on.  EC2 isn't cutting it.  My testing box is a basic Sata
>>>> drive and it is running much faster but there is no user load on
>>>> the
>>>> box.  We really need a box with raid 10 drives in it to handle the
>>>> high IO needs.
>>> http://jenkins.ekohl.nl/munin/ekohl.nl/jenkins.ekohl.nl/index.html
>>> are
>>> the stats of the jenkins slave we (my employer) provide. This is a
>>> production load. Quick analysis shows that IO is limiting at times,
>>> but
>>> the high IO peaks correlate to the swap. So adding more than 8GB
>>> RAM
>>> would lessen the requirement on the IO. Note that it is currently
>>> running on our SATA SAN, but I don't know the RAID config from the
>>> top
>>> of my head.
>> Slave boxes are diff from the master.  Jenkins copies all the files
>> over
>> from the master to the slave then back up to the master.  Using a
>> good
>> chunk of bandwidith and disk IO on both the slaves and the master.
>> Every job requires IO on the master and a lot of it.  As the number
>> of
>> slaves goes up so does the IO on the master.  The current EC2
>> instance
>> isn't holding it own with load.  Spikes can literately take it
>> offline
>> and even when it is idle it still is showing a ton of IO from the
>> people
>> visiting the site.  The question is with the limited budget what can
>> we do.
>>
>> What we really want for the master is a dedicated machine with a sas
>> /
>> ssd raid 10 controller aka the profile of a database server.  What we
>> can get away with for now is the real question.  I can offer up my
>> boxes
>> they are just running on Sata drives and currently running behind my
>> 70/35 Verizon FiOS connection ( Jenkins.ovirt.info ).  We could move
>> them to a local co-lo for about $40.00 a U per month a friend of mine
>> runs.
>>
>> What does everyone else think?
> we can look at jenkins master load on jenkins.ovirt.org/monitoring (you need to be jenkins administrator to see it).
That is only monitoring the web traffic and not the actual build process 
and 3/4 of the data being pushed is archive.zip files for the node-iso 
builds.  Although part of the build process it is the only part that 
shows up in the monitoring.

And with nightly getting pushed to www.ovirt.org sometime this week the 
traffic should drop even lower.

So far the only options I have seen talked about are.

1) limit what Jenkins can do by leaving it as is until hardware becomes 
available though *Red Hat in a few months.  I don't think Jenkins will 
be able to make use of any more slaves since it is having a hard time 
even keeping up with the current number of slaves.
2) We build a 2nd master on EC2 and break the load up some.
3) Move to another VPS provider and see if Jenkins Master will run 
better on one of those services.  Or if we can get the budget for it a 
dedicated box.
4) We find someone else who will donate hardware I would say 16G of Ram 
and either local storage or 10G storage network is pretty much min 
requirement
5) We use my hardware on ovirt.info and migrate the slaves over to it.  
Either using my current ISP that is fast but not on a static IP or Co-lo 
the boxes (About $80 a month).  My boxes are dual quad core's with 16G 
of ram each but only have sata drives and no raid controller.

*Since my understanding is Red Hat has promised hardware in the 2012 
4th/2013 1st qtr we are looking to get by until then.

-- 
Thanks
Robert Middleswarth
@rmiddle (twitter/IRC)



From gkotton at redhat.com  Fri Aug  3 10:48:44 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Fri, 03 Aug 2012 13:48:44 +0300
Subject: Host network management roadmap inquiry
In-Reply-To: <1343835248.2211.26.camel@fdeutsch-laptop.local>
References: <414527091.1747093.1343829414123.JavaMail.root@redhat.com>
	<1343835248.2211.26.camel@fdeutsch-laptop.local>
Message-ID: <501BAC8C.5060406@redhat.com>

On 08/01/2012 06:34 PM, Fabian Deutsch wrote:
> Am Mittwoch, den 01.08.2012, 09:56 -0400 schrieb Andrew Cathrow:
>>> From: "Mark Wu"<wudxw at linux.vnet.ibm.com>
>>> Sent: Wednesday, August 1, 2012 8:59:14 AM
>>> Subject: Host network management roadmap inquiry
> <snip/>
>
>>> quantum
>>> Both the plugins openvswitch and linuxbridge stores abstract network
>>> entities (network, port) in database and create bridge/vlan via the
>>> tool ip/brctl or ovs-vsctl on demand. Only one bridge is created on
>>> one server and one vlan is created for each virtual network. That
>>> means that only one nic can be configured for vm network. It doesn't
>>> configure nic or bond even if openvswitch also supports bond. Both
>>> of traditional network stack configuration and quantum will be
>>> supported oVirt for different purpose, right?

More than one virtual NIC can be assigned to a VM. The Quantum agents 
are tune to assign the virtual NIC to the correct network. The NIC 
bonding is something that is not addressed by Quantum. Each agent hsa 
its own configuration file that indicates the physical network 
connectivity.
>> good place to start :
>> https://fedoraproject.org/wiki/Quantum_and_oVirt
> Hey,
> besides these Quantum specific informations I'd also like to discuss
> where oVirt is going wrt to networking.
> Quantum is sure a nice solution for a project wide solution, but how can
> or should this be integrated into the underlying components like vdsm or
> node?

If Quantum was integrated into oVirt then oVirt would receive all of the 
support from Quantum. For example in Folsom there has been a lot of 
activity in Quantum to provide address management. In the wiki it is 
written that forman supports tis. I am not exactly sure in what context. 
In Folsom-3 of Quantum one or more IP addresses can be assigned in a 
network (from a predefined subnet). A DHCP agent ensures that the VM's 
will receive the assigned IP address.

>  From a Node pov (feature as well as implementation wise) it is quite
> interesting if we should switch to openvswitch (which can then in turn
> used by quantum [via vdsm?]) or keep the linux bridge stuff.
>
> There are also efforts on it's way (like teaming, the F17 feature) which
> we should keep an eye on, as this seems to land in network manager as an
> alternative(?) to the default bonding. It's also interesting how this
> performs with openvswitch.
>
> Many changes on many sides and we should lay out the path a bit to find
> a direction where to go.
> There is already
>
> http://wiki.ovirt.org/wiki/Networking

Can you please clarify what you mean by network permissions. Quantum has 
permissions for the management of networks.

> which we could use to summarize the needed features, potential
> techniques and an over all plan.
>
> Greetings
> fabian
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120803/6cfc8fbe/attachment.html>

From gkotton at redhat.com  Fri Aug  3 10:54:48 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Fri, 03 Aug 2012 13:54:48 +0300
Subject: Host network management roadmap inquiry
In-Reply-To: <50192822.9030309@linux.vnet.ibm.com>
References: <50192822.9030309@linux.vnet.ibm.com>
Message-ID: <501BADF8.9080803@redhat.com>

On 08/01/2012 03:59 PM, Mark Wu wrote:
> Sorry for cross-posting!
>
> I would like to inquiry about the roadmap of host network management 
> in oVirt in order to
> make sure the ideas to be worked on are welcomed by community.
>
> I did some initial investigation on the following topics. I am not 
> very familiar with them, so the information may contain some 
> inaccuracies or errors.
>
> netcf:
>
>     It provides cross-platform network configuration library/tool by 
> converting the XML definition of an interface into local config file. 
> It's already used by libvirt to manage host network interfaces.It 
> supports all network entities including bridge, vlan, bond, nic. And 
> it also supports configuration rollback.  The benefit for vdsm is 
> making host network stack configuration easy to port to other distros.
>
> Problems found:
>     It doesn't restore interface live state during config transaction 
> now. There's a feature request submit for it.
>     There're some advanced settings not supported in netcf, like 
> 'NM_CONTROLLED' and some less used bonding options.
>
>     It doesn't provide python binding officially. But we can use 
> libvirt API to integrate it into vdsm. It shouldn't have any impact on 
> engine side.
>
>
> IEEE 802.1Qbg(VEPA)
>
>      It can offload network switching from server to external physical 
> switch. It makes all VMs' traffic visible to physical switch, and 
> therefore the existing switch functions (firewall, QoS etc) can be 
> applied to VM immediately. The offload also frees up the server 
> resource used by switching.
>      Now libvirt supports it by using macvtap as vif and working with 
> lldpad, which registers vif's mac/vlan information to the physical 
> switch. We can just add a 'virtualport' element to an interface XML 
> definition to add a VEPA interface. Probably, to support it in oVirt 
> we still need configure lldpad  and query available VSI types for 
> virtualport profile.
>
>
> quantum
>
>    Both the plugins openvswitch and linuxbridge stores abstract 
> network entities (network, port) in database and create bridge/vlan 
> via the tool ip/brctl or ovs-vsctl on demand. Only one bridge is 
> created on one server and one vlan is created for each virtual 
> network. That means that only one nic can be configured for vm 
> network.  It doesn't configure nic or bond even if openvswitch also 
> supports bond. Both of traditional network stack configuration and 
> quantum will be supported oVirt for different purpose, right?

Please not that there are a large amount of suported plugins. Please 
look at http://wiki.openstack.org/Quantum to see a list of plugins. In 
addition to this there is a meta plugin which is currently in review - 
this is a plugin that can support more than one plugin :) (At the moment 
Quantum only supports one plugin)
>
>    Any comments? Thanks!
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120803/f5295749/attachment.html>

From lpeer at redhat.com  Sat Aug  4 17:06:28 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sat, 04 Aug 2012 20:06:28 +0300
Subject: Host network management roadmap inquiry
In-Reply-To: <50192822.9030309@linux.vnet.ibm.com>
References: <50192822.9030309@linux.vnet.ibm.com>
Message-ID: <501D5694.7090103@redhat.com>

On 01/08/12 15:59, Mark Wu wrote:
> Sorry for cross-posting!
> 
> I would like to inquiry about the roadmap of host network management in
> oVirt in order to
> make sure the ideas to be worked on are welcomed by community.
> 
> I did some initial investigation on the following topics.  I am not very
> familiar with them, so the information may contain some inaccuracies or
> errors.
> 

Hi Mark,

My name is Livnat Peer, I'm focused on Networking in oVirt.
I am wondering if there is an interest for a monthly meeting on
networking in oVirt. I think we can discuss the current status in
networking features/bugs and the road map for future oVirt versions.

> netcf:
>     
>     It provides cross-platform network configuration library/tool by
> converting the XML definition of an interface into local config file.
> It's already used by libvirt to manage host network interfaces.It
> supports all network entities including bridge, vlan, bond, nic. And it
> also supports configuration rollback.  The benefit for vdsm is making
> host network stack configuration easy to port to other distros.
>     
> Problems found:
>     It doesn't restore interface live state during config transaction
> now. There's a feature request submit for it.
>     There're some advanced settings not supported in netcf, like
> 'NM_CONTROLLED' and some less used bonding options.
> 
>     It doesn't provide python binding officially. But we can use libvirt
> API to integrate it into vdsm. It shouldn't have any impact on engine side.
> 

Making it easy to consume vdsm in other distros has great value for the
ovirt project, I don't see a reason why not to do that.
I think we should start with mapping the gaps of the functionality
currently used by vdsm and see what is missing for us to use netcf.
I think there was a proposal to use Network Manager in Fedora that also
was supposed to work with netcf but I don't have more details on that,

danken  - do you recall something more specific?

BTW - Can you please send the link to the feature request for netcf to
support restore?


> 
> IEEE 802.1Qbg(VEPA)
> 
>      It can offload network switching from server to external physical
> switch. It makes all VMs' traffic visible to physical switch, and
> therefore the existing switch functions (firewall, QoS etc) can be
> applied to VM immediately. The offload also frees up the server resource
> used by switching.
>      Now libvirt supports it by using macvtap as vif and working with
> lldpad, which registers vif's mac/vlan information to the physical
> switch. We can just add a 'virtualport' element to an interface XML
> definition to add a VEPA interface. Probably, to support it in oVirt we
> still need configure lldpad  and query available VSI types for
> virtualport profile.
> 

when discussing the modeling of 802.1Qbg we should also look into
802.1Qbh, the modeling of the two should have a lot in common.

We looked into modeling the above two in the past but did not get a
chance to actually work on it yet.

When adding support for a new technology in ovirt, especially in the
modeling phase I think it is important to understand how ovirt users are
going to use this technology and how the engine and vdsm together are
going to provide a complete solution for our users.


> 
> quantum
> 
>    Both the plugins openvswitch and linuxbridge stores abstract network
> entities (network, port) in database and create bridge/vlan via the tool
> ip/brctl or ovs-vsctl on demand. Only one bridge is created on one
> server and one vlan is created for each virtual network. That means that
> only one nic can be configured for vm network.  It doesn't configure nic
> or bond even if openvswitch also supports bond. Both of traditional
> network stack configuration and quantum will be supported oVirt for
> different purpose, right?
> 

We had some discussions on integration with Quntum which included a few
upstream calls to discuss the gaps we have in order to use quantum in
ovirt. We had Gary that is working on quantum in these sessions and the
link to the summary of our work so far was sent earlier on this thread.



Other than the above I maintain a wiki page with all the gaps we are
aware of for networking in Ovirt -

http://wiki.ovirt.org/wiki/Networking

There you can see that there was a proposal to use Network-Manager in VDSM.

I see that Fabian split the page to features and technologies, thanks
Fabian :)


Livnat



>    Any comments? Thanks!
> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 



From jbrooks at redhat.com  Sat Aug  4 18:21:38 2012
From: jbrooks at redhat.com (Jason Brooks)
Date: Sat, 4 Aug 2012 14:21:38 -0400 (EDT)
Subject: [Users] Looking for help: Demo videos
In-Reply-To: <5005A4C5.20409@redhat.com>
Message-ID: <2005779743.85826.1344104498773.JavaMail.root@redhat.com>

Hey everyone:

I've made a screencast of creating VMs in oVirt 3.1: http://www.youtube.com/watch?v=C4gayV6dYK4

I wrote a blog post about the tools and process I used: http://blog.jebpages.com/archives/screencasting-ovirt/

Now that I have the process down (and my oVirt 3.1 rig in shape), I'll do a few more of these before the 3.1 launch.

Regards, Jason

----- Original Message -----
> From: "Dave Neary" <dneary at redhat.com>
> To: "arch" <arch at ovirt.org>, "users" <users at ovirt.org>
> Sent: Tuesday, July 17, 2012 10:45:41 AM
> Subject: [Users] Looking for help: Demo videos
> 
> Hi everyone,
> 
> Last week I pitched the idea of having some demo videos (I called
> them
> "screencasts" although that's not quite accurate) ready before the
> 3.1
> release next week.
> 
> I don't have the domain knowledge to do this myself, so I need your
> help!
> 
> What is there to do?
> 
> 1. Go to http://wiki.ovirt.org/wiki/Screencasts - have a look at the
> features I've proposed for the first round of videos. If you really
> think one of them shouldn't be there, or there's a really important
> feature you'd like to see a demo for, please reply here and we'll
> discuss it. You can always add a proposed feature with the skeleton
> template to the Screencasts page also, but there's no guarantee we'll
> have a video by the time the release comes around. It would helkp me
> prioritise if we could gather feedback here.
> 
> 2. For each feature, we should have a scenario/script for the demo,
> including:
>   * Required pre-requisites and set-up (what do I need to do before I
> start the demo)
>   * A step by step description of how to show the feature being
>   demoed
> 
> Right now, only two features are described, and those descriptions
> may
> need work.
> 
> If you see a feature which is not yet described, and you know how to
> use
> it, please add a little script following the template. If you see a
> feature which is not described well enough, please update the
> description.
> 
> 3. For each feature with a script, we need a video. I have started a
> page to help people record videos of their screen, for the systems I
> know about: http://wiki.ovirt.org/wiki/Recording_video - the videos
> (without sound) can, I think, be attached to the wiki page - ogv or
> webm
> format preferably, please!
> 
> 4. For each video, we will need a sound-track. I'm happy to voice
> over
> some of the videos, but again, it would be nice to spread the load.
> We're not even here yet, though.
> 
> Thanks everyone for your help! It will be greatly appreciated.
> 
> Regards,
> Dave.
> 
> --
> Dave Neary
> Community Action and Impact
> Open Source and Standards Team, Red Hat
> Phone: +33 9 50 71 55 62
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From robert at middleswarth.net  Mon Aug  6 02:19:02 2012
From: robert at middleswarth.net (Robert Middleswarth)
Date: Sun, 05 Aug 2012 22:19:02 -0400
Subject: Jenkins IRC Bot.
Message-ID: <501F2996.4080202@middleswarth.net>

I setup a test Jenkins bot.  It is for notices only no control. It's IRC 
channel is #ovirt-jenkins we can test this and see if it is useful and 
decide of we want to keep it running or not.

-- 
Thanks
Robert Middleswarth
@rmiddle (twitter/IRC)



From wudxw at linux.vnet.ibm.com  Mon Aug  6 07:16:06 2012
From: wudxw at linux.vnet.ibm.com (Mark Wu)
Date: Mon, 06 Aug 2012 15:16:06 +0800
Subject: Host network management roadmap inquiry
In-Reply-To: <501D5694.7090103@redhat.com>
References: <50192822.9030309@linux.vnet.ibm.com> <501D5694.7090103@redhat.com>
Message-ID: <501F6F36.5000009@linux.vnet.ibm.com>


Hi Livnat,

Many thanks for your reply!  Please see my inline comments.

On 08/05/2012 01:06 AM, Livnat Peer wrote:
> On 01/08/12 15:59, Mark Wu wrote:
>> Sorry for cross-posting!
>>
>> I would like to inquiry about the roadmap of host network management in
>> oVirt in order to
>> make sure the ideas to be worked on are welcomed by community.
>>
>> I did some initial investigation on the following topics.  I am not very
>> familiar with them, so the information may contain some inaccuracies or
>> errors.
>>
> Hi Mark,
>
> My name is Livnat Peer, I'm focused on Networking in oVirt.
> I am wondering if there is an interest for a monthly meeting on
> networking in oVirt. I think we can discuss the current status in
> networking features/bugs and the road map for future oVirt versions.
Sure,  I am glad to join.  Thanks for your invitation.
>
>> netcf:
>>
>>      It provides cross-platform network configuration library/tool by
>> converting the XML definition of an interface into local config file.
>> It's already used by libvirt to manage host network interfaces.It
>> supports all network entities including bridge, vlan, bond, nic. And it
>> also supports configuration rollback.  The benefit for vdsm is making
>> host network stack configuration easy to port to other distros.
>>
>> Problems found:
>>      It doesn't restore interface live state during config transaction
>> now. There's a feature request submit for it.
>>      There're some advanced settings not supported in netcf, like
>> 'NM_CONTROLLED' and some less used bonding options.
>>
>>      It doesn't provide python binding officially. But we can use libvirt
>> API to integrate it into vdsm. It shouldn't have any impact on engine side.
>>
> Making it easy to consume vdsm in other distros has great value for the
> ovirt project, I don't see a reason why not to do that.
> I think we should start with mapping the gaps of the functionality
> currently used by vdsm and see what is missing for us to use netcf.
I am going to implement a prototype for it. Probably, we can find more 
what's missing in netcf during the prototype development.
> I think there was a proposal to use Network Manager in Fedora that also
> was supposed to work with netcf but I don't have more details on that,
>
> danken  - do you recall something more specific?
>
> BTW - Can you please send the link to the feature request for netcf to
> support restore?
Here's the feature request, and I have added you to the cc list :)
https://bugzilla.redhat.com/show_bug.cgi?id=737149
>
>> IEEE 802.1Qbg(VEPA)
>>
>>       It can offload network switching from server to external physical
>> switch. It makes all VMs' traffic visible to physical switch, and
>> therefore the existing switch functions (firewall, QoS etc) can be
>> applied to VM immediately. The offload also frees up the server resource
>> used by switching.
>>       Now libvirt supports it by using macvtap as vif and working with
>> lldpad, which registers vif's mac/vlan information to the physical
>> switch. We can just add a 'virtualport' element to an interface XML
>> definition to add a VEPA interface. Probably, to support it in oVirt we
>> still need configure lldpad  and query available VSI types for
>> virtualport profile.
>>
> when discussing the modeling of 802.1Qbg we should also look into
> 802.1Qbh, the modeling of the two should have a lot in common.
>
> We looked into modeling the above two in the past but did not get a
> chance to actually work on it yet.
>
> When adding support for a new technology in ovirt, especially in the
> modeling phase I think it is important to understand how ovirt users are
> going to use this technology and how the engine and vdsm together are
> going to provide a complete solution for our users.
>
Make sense.  We need collect more customer use case of them before 
modelling it.
>
>
>> quantum
>>
>>     Both the plugins openvswitch and linuxbridge stores abstract network
>> entities (network, port) in database and create bridge/vlan via the tool
>> ip/brctl or ovs-vsctl on demand. Only one bridge is created on one
>> server and one vlan is created for each virtual network. That means that
>> only one nic can be configured for vm network.  It doesn't configure nic
>> or bond even if openvswitch also supports bond. Both of traditional
>> network stack configuration and quantum will be supported oVirt for
>> different purpose, right?
>>
> We had some discussions on integration with Quntum which included a few
> upstream calls to discuss the gaps we have in order to use quantum in
> ovirt. We had Gary that is working on quantum in these sessions and the
> link to the summary of our work so far was sent earlier on this thread.
>
>
>
> Other than the above I maintain a wiki page with all the gaps we are
> aware of for networking in Ovirt -
>
> http://wiki.ovirt.org/wiki/Networking
>
> There you can see that there was a proposal to use Network-Manager in VDSM.
>
> I see that Fabian split the page to features and technologies, thanks
> Fabian :)
>
>
> Livnat
>
>
>
>>     Any comments? Thanks!
>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120806/1bf7e673/attachment.html>

From lpeer at redhat.com  Mon Aug  6 07:53:52 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 06 Aug 2012 10:53:52 +0300
Subject: Host network management roadmap inquiry
In-Reply-To: <501F6F36.5000009@linux.vnet.ibm.com>
References: <50192822.9030309@linux.vnet.ibm.com> <501D5694.7090103@redhat.com>
	<501F6F36.5000009@linux.vnet.ibm.com>
Message-ID: <501F7810.6090408@redhat.com>

On 06/08/12 10:16, Mark Wu wrote:
> 
> Hi Livnat,
> 
> Many thanks for your reply!  Please see my inline comments.
> 
> On 08/05/2012 01:06 AM, Livnat Peer wrote:
>> On 01/08/12 15:59, Mark Wu wrote:
>>> Sorry for cross-posting!
>>>
>>> I would like to inquiry about the roadmap of host network management in
>>> oVirt in order to
>>> make sure the ideas to be worked on are welcomed by community.
>>>
>>> I did some initial investigation on the following topics.  I am not very
>>> familiar with them, so the information may contain some inaccuracies or
>>> errors.
>>>
>> Hi Mark,
>>
>> My name is Livnat Peer, I'm focused on Networking in oVirt.
>> I am wondering if there is an interest for a monthly meeting on
>> networking in oVirt. I think we can discuss the current status in
>> networking features/bugs and the road map for future oVirt versions.
> Sure,  I am glad to join.  Thanks for your invitation. 

An invite was sent to the lists.

>>
>>> netcf:
>>>     
>>>     It provides cross-platform network configuration library/tool by
>>> converting the XML definition of an interface into local config file.
>>> It's already used by libvirt to manage host network interfaces.It
>>> supports all network entities including bridge, vlan, bond, nic. And it
>>> also supports configuration rollback.  The benefit for vdsm is making
>>> host network stack configuration easy to port to other distros.
>>>     
>>> Problems found:
>>>     It doesn't restore interface live state during config transaction
>>> now. There's a feature request submit for it.
>>>     There're some advanced settings not supported in netcf, like
>>> 'NM_CONTROLLED' and some less used bonding options.
>>>
>>>     It doesn't provide python binding officially. But we can use libvirt
>>> API to integrate it into vdsm. It shouldn't have any impact on engine side.
>>>
>> Making it easy to consume vdsm in other distros has great value for the
>> ovirt project, I don't see a reason why not to do that.
>> I think we should start with mapping the gaps of the functionality
>> currently used by vdsm and see what is missing for us to use netcf.
> I am going to implement a prototype for it. Probably, we can find more
> what's missing in netcf during the prototype development.
>> I think there was a proposal to use Network Manager in Fedora that also
>> was supposed to work with netcf but I don't have more details on that,
>>
>> danken  - do you recall something more specific?
>>
>> BTW - Can you please send the link to the feature request for netcf to
>> support restore?
> Here's the feature request, and I have added you to the cc list :)
> https://bugzilla.redhat.com/show_bug.cgi?id=737149

thank you

>>
>>> IEEE 802.1Qbg(VEPA)
>>>
>>>      It can offload network switching from server to external physical
>>> switch. It makes all VMs' traffic visible to physical switch, and
>>> therefore the existing switch functions (firewall, QoS etc) can be
>>> applied to VM immediately. The offload also frees up the server resource
>>> used by switching.
>>>      Now libvirt supports it by using macvtap as vif and working with
>>> lldpad, which registers vif's mac/vlan information to the physical
>>> switch. We can just add a 'virtualport' element to an interface XML
>>> definition to add a VEPA interface. Probably, to support it in oVirt we
>>> still need configure lldpad  and query available VSI types for
>>> virtualport profile.
>>>
>> when discussing the modeling of 802.1Qbg we should also look into
>> 802.1Qbh, the modeling of the two should have a lot in common.
>>
>> We looked into modeling the above two in the past but did not get a
>> chance to actually work on it yet.
>>
>> When adding support for a new technology in ovirt, especially in the
>> modeling phase I think it is important to understand how ovirt users are
>> going to use this technology and how the engine and vdsm together are
>> going to provide a complete solution for our users.
>>
> Make sense.  We need collect more customer use case of them before
> modelling it.
>>
>>
>>> quantum
>>>
>>>    Both the plugins openvswitch and linuxbridge stores abstract network
>>> entities (network, port) in database and create bridge/vlan via the tool
>>> ip/brctl or ovs-vsctl on demand. Only one bridge is created on one
>>> server and one vlan is created for each virtual network. That means that
>>> only one nic can be configured for vm network.  It doesn't configure nic
>>> or bond even if openvswitch also supports bond. Both of traditional
>>> network stack configuration and quantum will be supported oVirt for
>>> different purpose, right?
>>>
>> We had some discussions on integration with Quntum which included a few
>> upstream calls to discuss the gaps we have in order to use quantum in
>> ovirt. We had Gary that is working on quantum in these sessions and the
>> link to the summary of our work so far was sent earlier on this thread.
>>
>>
>>
>> Other than the above I maintain a wiki page with all the gaps we are
>> aware of for networking in Ovirt -
>>
>> http://wiki.ovirt.org/wiki/Networking
>>
>> There you can see that there was a proposal to use Network-Manager in VDSM.
>>
>> I see that Fabian split the page to features and technologies, thanks
>> Fabian :)
>>
>>
>> Livnat
>>
>>
>>
>>>    Any comments? Thanks!
>>>
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
> 



From eedri at redhat.com  Mon Aug  6 08:00:07 2012
From: eedri at redhat.com (Eyal Edri)
Date: Mon, 6 Aug 2012 04:00:07 -0400 (EDT)
Subject: Jenkins IRC Bot.
In-Reply-To: <501F2996.4080202@middleswarth.net>
Message-ID: <16274031.354334.1344240007562.JavaMail.root@redhat.com>

great, i've been wanting to test it someday :)

can we set it to alert on Jenkins build failures? 

e.

----- Original Message -----
> From: "Robert Middleswarth" <robert at middleswarth.net>
> To: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Monday, August 6, 2012 5:19:02 AM
> Subject: Jenkins IRC Bot.
> 
> I setup a test Jenkins bot.  It is for notices only no control. It's
> IRC
> channel is #ovirt-jenkins we can test this and see if it is useful
> and
> decide of we want to keep it running or not.
> 
> --
> Thanks
> Robert Middleswarth
> @rmiddle (twitter/IRC)
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From robert at middleswarth.net  Mon Aug  6 12:30:08 2012
From: robert at middleswarth.net (Robert Middleswarth)
Date: Mon, 06 Aug 2012 08:30:08 -0400
Subject: Jenkins IRC Bot.
In-Reply-To: <16274031.354334.1344240007562.JavaMail.root@redhat.com>
References: <16274031.354334.1344240007562.JavaMail.root@redhat.com>
Message-ID: <501FB8D0.3030301@middleswarth.net>

On 08/06/2012 04:00 AM, Eyal Edri wrote:
> great, i've been wanting to test it someday :)
>
> can we set it to alert on Jenkins build failures?
It currently reports when a job starts and stops.  What kind of alert 
are you looking for?

Thanks
Robert
>
> e.
>
> ----- Original Message -----
>> From: "Robert Middleswarth" <robert at middleswarth.net>
>> To: "arch" <arch at ovirt.org>, "infra" <infra at ovirt.org>
>> Sent: Monday, August 6, 2012 5:19:02 AM
>> Subject: Jenkins IRC Bot.
>>
>> I setup a test Jenkins bot.  It is for notices only no control. It's
>> IRC
>> channel is #ovirt-jenkins we can test this and see if it is useful
>> and
>> decide of we want to keep it running or not.
>>
>> --
>> Thanks
>> Robert Middleswarth
>> @rmiddle (twitter/IRC)
>>
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>


-- 
Thanks
Robert Middleswarth
@rmiddle (twitter/IRC)



From oschreib at redhat.com  Wed Aug  8 15:00:54 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 8 Aug 2012 11:00:54 -0400 (EDT)
Subject: ANNOUNCE: oVirt 3.1 Release
In-Reply-To: <360551252.1948096.1344437207906.JavaMail.root@redhat.com>
Message-ID: <95602421.1954960.1344438054396.JavaMail.root@redhat.com>

The oVirt Project's second official release, version 3.1, ships with a set of storage, interface and infrastructure enhancements that narrow the gaps between the open source virtualization platform and proprietary alternatives.

oVirt 3.1 adds support for capturing and cloning from live snapshots, for virtual disk and network adapter hot plugging, and for connecting externally-hosted LUNs to oVirt virtual machines. The oVirt 3.1 web administration console also includes new interfaces for managing floating virtual disks and for configuring Gluster storage volumes.

In the 3.1 release, Red Hat Directory Server and IBM Tivoli Directory Server join IPA and Active Directory as supported identity providers, which administrators may pair with initial support for user-based resource quota capabilities.

For more information on oVirt 3.1, including installation instructions, please see the release notes at http://wiki.ovirt.org/wiki/OVirt_3.1_release_notes .

The new release is avilable for download at http://www.ovirt.org/get-ovirt/

For the entire oVirt community, thanks for your participation in making this release happen. In particular, thanks to anyone who contributed to the release through testing, submitting patches, and bug reporting.

Ofer Schreiber
oVirt release manager, on behalf of the oVirt team.


From mburns at redhat.com  Wed Aug  8 15:26:22 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 08 Aug 2012 11:26:22 -0400
Subject: Looking for an additional Release Manager for the oVirt Project
Message-ID: <1344439582.30067.7.camel@beelzebub.mburnsfire.net>

Hi all,

We are currently looking for someone who is willing to fill the role of
Release Manager for the oVirt Project.  Our current Release Manager,
Ofer Schreiber, is going to be away for ~7 weeks and we need someone to
fill the role during that time, and to share the role after he
returns.  

Ofer is preparing a wiki page detailing the role and responsibilities.  

If you are willing to help out or want to nominate someone for the role,
please let us know.  

Thanks

Mike



From lhawthor at redhat.com  Wed Aug  8 21:49:16 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Wed, 08 Aug 2012 14:49:16 -0700
Subject: Speakers Needed: Upcoming Workshops
Message-ID: <5022DEDC.1090007@redhat.com>

Hello everyone,

First of all, congratulations to the team on today's release of oVirt 3.1!

As mentioned in today's weekly status IRC meeting, we would like to 
ensure we have broad community participation in upcoming workshops. [0] 
For KVM Forum + oVirt in Barcelona [1], a general call for papers will 
be issued within the next few days. I will send a note to these lists 
when details of the CFP have been announced.

For the oVirt workshop to be hosted at Red Hat's Bangalore campus on 16 
October 2012, it would be wonderful if folks would propose sessions for 
this workshop. (We have chosen not to go through a formal CFP process 
for Bangalore so as to leave sufficient time for the KVM Forum + oVirt 
CFP process to run most smoothly.) If you would like to propose a 
session for oVirt Bangalore, please email me and I follow up with you.

As usual, any questions, please let me know.

[0] - http://wiki.ovirt.org/wiki/OVirt_Global_Workshops
[1] - http://events.linuxfoundation.org/events/kvm-forum/

Cheers,
LH

-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn



From kanagaraj.rk at gmail.com  Wed Aug  8 22:44:20 2012
From: kanagaraj.rk at gmail.com (R.Kanagaraj (RK))
Date: Thu, 9 Aug 2012 04:14:20 +0530
Subject: Speakers Needed: Upcoming Workshops
In-Reply-To: <5022DEDC.1090007@redhat.com>
References: <5022DEDC.1090007@redhat.com>
Message-ID: <CALVLwtbq3j9DggCwC=n+Vhu9MaiEedj56Qj7FMRYQt2=-RMeiA@mail.gmail.com>

Dear all,

I would like to give a live session on deploying ovirt node, engine and
perform basic tasks such as adding storage, creating data center etc.,.

On Thu, Aug 9, 2012 at 3:19 AM, Leslie Hawthorn <lhawthor at redhat.com> wrote:

> Hello everyone,
>
> First of all, congratulations to the team on today's release of oVirt 3.1!
>
> As mentioned in today's weekly status IRC meeting, we would like to ensure
> we have broad community participation in upcoming workshops. [0] For KVM
> Forum + oVirt in Barcelona [1], a general call for papers will be issued
> within the next few days. I will send a note to these lists when details of
> the CFP have been announced.
>
> For the oVirt workshop to be hosted at Red Hat's Bangalore campus on 16
> October 2012, it would be wonderful if folks would propose sessions for
> this workshop. (We have chosen not to go through a formal CFP process for
> Bangalore so as to leave sufficient time for the KVM Forum + oVirt CFP
> process to run most smoothly.) If you would like to propose a session for
> oVirt Bangalore, please email me and I follow up with you.
>
> As usual, any questions, please let me know.
>
> [0] - http://wiki.ovirt.org/wiki/**OVirt_Global_Workshops<http://wiki.ovirt.org/wiki/OVirt_Global_Workshops>
> [1] - http://events.linuxfoundation.**org/events/kvm-forum/<http://events.linuxfoundation.org/events/kvm-forum/>
>
> Cheers,
> LH
>
> --
> Leslie Hawthorn
> Community Action and Impact
> Open Source and Standards @ Red Hat
>
> identi.ca/lh
> twitter.com/lhawthorn
>
> ______________________________**_________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/**mailman/listinfo/arch<http://lists.ovirt.org/mailman/listinfo/arch>
>



-- 

With Regards,
RK,
+91 98404 83044
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120809/05366400/attachment.html>

From lhawthor at redhat.com  Wed Aug  8 22:54:43 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Wed, 08 Aug 2012 15:54:43 -0700
Subject: Speakers Needed: Upcoming Workshops
In-Reply-To: <CALVLwtbq3j9DggCwC=n+Vhu9MaiEedj56Qj7FMRYQt2=-RMeiA@mail.gmail.com>
References: <5022DEDC.1090007@redhat.com>
	<CALVLwtbq3j9DggCwC=n+Vhu9MaiEedj56Qj7FMRYQt2=-RMeiA@mail.gmail.com>
Message-ID: <5022EE33.7090504@redhat.com>

On 08/08/2012 03:44 PM, R.Kanagaraj (RK) wrote:
> Dear all,
>
> I would like to give a live session on deploying ovirt node, engine 
> and perform basic tasks such as adding storage, creating data center 
> etc.,.
>
Hi RK,

Great to hear from you! Would you please send me an abstract so I can 
take a look at it and determine how it would best fit into the program? 
A speaker bio would also be a welcome addition. If you would like to 
take a look at a sample, you can find one here:

http://events.linuxfoundation.org/events/linuxcon/ovirt-architecture

Best,
LH


> On Thu, Aug 9, 2012 at 3:19 AM, Leslie Hawthorn <lhawthor at redhat.com 
> <mailto:lhawthor at redhat.com>> wrote:
>
>     Hello everyone,
>
>     First of all, congratulations to the team on today's release of
>     oVirt 3.1!
>
>     As mentioned in today's weekly status IRC meeting, we would like
>     to ensure we have broad community participation in upcoming
>     workshops. [0] For KVM Forum + oVirt in Barcelona [1], a general
>     call for papers will be issued within the next few days. I will
>     send a note to these lists when details of the CFP have been
>     announced.
>
>     For the oVirt workshop to be hosted at Red Hat's Bangalore campus
>     on 16 October 2012, it would be wonderful if folks would propose
>     sessions for this workshop. (We have chosen not to go through a
>     formal CFP process for Bangalore so as to leave sufficient time
>     for the KVM Forum + oVirt CFP process to run most smoothly.) If
>     you would like to propose a session for oVirt Bangalore, please
>     email me and I follow up with you.
>
>     As usual, any questions, please let me know.
>
>     [0] - http://wiki.ovirt.org/wiki/OVirt_Global_Workshops
>     [1] - http://events.linuxfoundation.org/events/kvm-forum/
>
>     Cheers,
>     LH
>
>     -- 
>     Leslie Hawthorn
>     Community Action and Impact
>     Open Source and Standards @ Red Hat
>
>     identi.ca/lh <http://identi.ca/lh>
>     twitter.com/lhawthorn <http://twitter.com/lhawthorn>
>
>     _______________________________________________
>     Arch mailing list
>     Arch at ovirt.org <mailto:Arch at ovirt.org>
>     http://lists.ovirt.org/mailman/listinfo/arch
>
>
>
>
> -- 
>
> With Regards,
> RK,
> +91 98404 83044
>


-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120808/0f609479/attachment.html>

From kanagaraj.rk at gmail.com  Fri Aug 10 00:35:30 2012
From: kanagaraj.rk at gmail.com (R.Kanagaraj (RK))
Date: Fri, 10 Aug 2012 06:05:30 +0530
Subject: Speakers Needed: Upcoming Workshops
In-Reply-To: <5022EE33.7090504@redhat.com>
References: <5022DEDC.1090007@redhat.com>
	<CALVLwtbq3j9DggCwC=n+Vhu9MaiEedj56Qj7FMRYQt2=-RMeiA@mail.gmail.com>
	<5022EE33.7090504@redhat.com>
Message-ID: <CALVLwtZFonW2pccYKiUtgqwQ87SojjMX_hpyAHk1zLti_7qLyw@mail.gmail.com>

will update you soon.

On Thu, Aug 9, 2012 at 4:24 AM, Leslie Hawthorn <lhawthor at redhat.com> wrote:

>  On 08/08/2012 03:44 PM, R.Kanagaraj (RK) wrote:
>
> Dear all,
>
> I would like to give a live session on deploying ovirt node, engine and
> perform basic tasks such as adding storage, creating data center etc.,.
>
>  Hi RK,
>
> Great to hear from you! Would you please send me an abstract so I can take
> a look at it and determine how it would best fit into the program? A
> speaker bio would also be a welcome addition. If you would like to take a
> look at a sample, you can find one here:
>
> http://events.linuxfoundation.org/events/linuxcon/ovirt-architecture
>
> Best,
> LH
>
>
>
>  On Thu, Aug 9, 2012 at 3:19 AM, Leslie Hawthorn <lhawthor at redhat.com>wrote:
>
>> Hello everyone,
>>
>> First of all, congratulations to the team on today's release of oVirt 3.1!
>>
>> As mentioned in today's weekly status IRC meeting, we would like to
>> ensure we have broad community participation in upcoming workshops. [0] For
>> KVM Forum + oVirt in Barcelona [1], a general call for papers will be
>> issued within the next few days. I will send a note to these lists when
>> details of the CFP have been announced.
>>
>> For the oVirt workshop to be hosted at Red Hat's Bangalore campus on 16
>> October 2012, it would be wonderful if folks would propose sessions for
>> this workshop. (We have chosen not to go through a formal CFP process for
>> Bangalore so as to leave sufficient time for the KVM Forum + oVirt CFP
>> process to run most smoothly.) If you would like to propose a session for
>> oVirt Bangalore, please email me and I follow up with you.
>>
>> As usual, any questions, please let me know.
>>
>> [0] - http://wiki.ovirt.org/wiki/OVirt_Global_Workshops
>> [1] - http://events.linuxfoundation.org/events/kvm-forum/
>>
>> Cheers,
>> LH
>>
>> --
>> Leslie Hawthorn
>> Community Action and Impact
>> Open Source and Standards @ Red Hat
>>
>> identi.ca/lh
>> twitter.com/lhawthorn
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>
>
>
> --
>
> With Regards,
> RK,
> +91 98404 83044
>
>
>
> --
> Leslie Hawthorn
> Community Action and Impact
> Open Source and Standards @ Red Hat
> identi.ca/lhtwitter.com/lhawthorn
>
>


-- 

With Regards,
RK,
+91 98404 83044
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120810/8a257678/attachment.html>

From lhawthor at redhat.com  Fri Aug 10 01:04:49 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Thu, 09 Aug 2012 18:04:49 -0700
Subject: Speakers Needed: Upcoming Workshops
In-Reply-To: <CALVLwtZFonW2pccYKiUtgqwQ87SojjMX_hpyAHk1zLti_7qLyw@mail.gmail.com>
References: <5022DEDC.1090007@redhat.com>
	<CALVLwtbq3j9DggCwC=n+Vhu9MaiEedj56Qj7FMRYQt2=-RMeiA@mail.gmail.com>
	<5022EE33.7090504@redhat.com>
	<CALVLwtZFonW2pccYKiUtgqwQ87SojjMX_hpyAHk1zLti_7qLyw@mail.gmail.com>
Message-ID: <50245E31.3000003@redhat.com>

On 08/09/2012 05:35 PM, R.Kanagaraj (RK) wrote:
> will update you soon.
Excellent - thank you!

Cheers,
LH
>
> On Thu, Aug 9, 2012 at 4:24 AM, Leslie Hawthorn <lhawthor at redhat.com 
> <mailto:lhawthor at redhat.com>> wrote:
>
>     On 08/08/2012 03:44 PM, R.Kanagaraj (RK) wrote:
>>     Dear all,
>>
>>     I would like to give a live session on deploying ovirt node,
>>     engine and perform basic tasks such as adding storage, creating
>>     data center etc.,.
>>
>     Hi RK,
>
>     Great to hear from you! Would you please send me an abstract so I
>     can take a look at it and determine how it would best fit into the
>     program? A speaker bio would also be a welcome addition. If you
>     would like to take a look at a sample, you can find one here:
>
>     http://events.linuxfoundation.org/events/linuxcon/ovirt-architecture
>
>     Best,
>     LH
>
>
>
>>     On Thu, Aug 9, 2012 at 3:19 AM, Leslie Hawthorn
>>     <lhawthor at redhat.com <mailto:lhawthor at redhat.com>> wrote:
>>
>>         Hello everyone,
>>
>>         First of all, congratulations to the team on today's release
>>         of oVirt 3.1!
>>
>>         As mentioned in today's weekly status IRC meeting, we would
>>         like to ensure we have broad community participation in
>>         upcoming workshops. [0] For KVM Forum + oVirt in Barcelona
>>         [1], a general call for papers will be issued within the next
>>         few days. I will send a note to these lists when details of
>>         the CFP have been announced.
>>
>>         For the oVirt workshop to be hosted at Red Hat's Bangalore
>>         campus on 16 October 2012, it would be wonderful if folks
>>         would propose sessions for this workshop. (We have chosen not
>>         to go through a formal CFP process for Bangalore so as to
>>         leave sufficient time for the KVM Forum + oVirt CFP process
>>         to run most smoothly.) If you would like to propose a session
>>         for oVirt Bangalore, please email me and I follow up with you.
>>
>>         As usual, any questions, please let me know.
>>
>>         [0] - http://wiki.ovirt.org/wiki/OVirt_Global_Workshops
>>         [1] - http://events.linuxfoundation.org/events/kvm-forum/
>>
>>         Cheers,
>>         LH
>>
>>         -- 
>>         Leslie Hawthorn
>>         Community Action and Impact
>>         Open Source and Standards @ Red Hat
>>
>>         identi.ca/lh <http://identi.ca/lh>
>>         twitter.com/lhawthorn <http://twitter.com/lhawthorn>
>>
>>         _______________________________________________
>>         Arch mailing list
>>         Arch at ovirt.org <mailto:Arch at ovirt.org>
>>         http://lists.ovirt.org/mailman/listinfo/arch
>>
>>
>>
>>
>>     -- 
>>
>>     With Regards,
>>     RK,
>>     +91 98404 83044 <tel:%2B91%2098404%2083044>
>>
>
>
>     -- 
>     Leslie Hawthorn
>     Community Action and Impact
>     Open Source and Standards @ Red Hat
>
>     identi.ca/lh  <http://identi.ca/lh>
>     twitter.com/lhawthorn  <http://twitter.com/lhawthorn>
>
>
>
>
> -- 
>
> With Regards,
> RK,
> +91 98404 83044
>


-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120809/3a540340/attachment.html>

From danken at redhat.com  Mon Aug 13 09:15:12 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 13 Aug 2012 12:15:12 +0300
Subject: Host network management roadmap inquiry
In-Reply-To: <501BAC8C.5060406@redhat.com>
References: <414527091.1747093.1343829414123.JavaMail.root@redhat.com>
	<1343835248.2211.26.camel@fdeutsch-laptop.local>
	<501BAC8C.5060406@redhat.com>
Message-ID: <20120813091512.GA29434@redhat.com>

On Fri, Aug 03, 2012 at 01:48:44PM +0300, Gary Kotton wrote:
> On 08/01/2012 06:34 PM, Fabian Deutsch wrote:
> >
> >http://wiki.ovirt.org/wiki/Networking
> 
> Can you please clarify what you mean by network permissions. Quantum
> has permissions for the management of networks.


Yeah, something like that - we need to let the administrator define who
can attach what to which network.


From danken at redhat.com  Mon Aug 13 11:44:07 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 13 Aug 2012 14:44:07 +0300
Subject: Host network management roadmap inquiry
In-Reply-To: <501D5694.7090103@redhat.com>
References: <50192822.9030309@linux.vnet.ibm.com> <501D5694.7090103@redhat.com>
Message-ID: <20120813114407.GC699@redhat.com>

On Sat, Aug 04, 2012 at 08:06:28PM +0300, Livnat Peer wrote:
> On 01/08/12 15:59, Mark Wu wrote:
> > Sorry for cross-posting!
> > 
> > I would like to inquiry about the roadmap of host network management in
> > oVirt in order to
> > make sure the ideas to be worked on are welcomed by community.
> > 
> > I did some initial investigation on the following topics.  I am not very
> > familiar with them, so the information may contain some inaccuracies or
> > errors.
> > 
> 
> Hi Mark,
> 
> My name is Livnat Peer, I'm focused on Networking in oVirt.
> I am wondering if there is an interest for a monthly meeting on
> networking in oVirt. I think we can discuss the current status in
> networking features/bugs and the road map for future oVirt versions.
> 
> > netcf:
> >     
> >     It provides cross-platform network configuration library/tool by
> > converting the XML definition of an interface into local config file.
> > It's already used by libvirt to manage host network interfaces.It
> > supports all network entities including bridge, vlan, bond, nic. And it
> > also supports configuration rollback.  The benefit for vdsm is making
> > host network stack configuration easy to port to other distros.
> >     
> > Problems found:
> >     It doesn't restore interface live state during config transaction
> > now. There's a feature request submit for it.
> >     There're some advanced settings not supported in netcf, like
> > 'NM_CONTROLLED' and some less used bonding options.
> > 
> >     It doesn't provide python binding officially. But we can use libvirt
> > API to integrate it into vdsm. It shouldn't have any impact on engine side.
> > 
> 
> Making it easy to consume vdsm in other distros has great value for the
> ovirt project, I don't see a reason why not to do that.
> I think we should start with mapping the gaps of the functionality
> currently used by vdsm and see what is missing for us to use netcf.
> I think there was a proposal to use Network Manager in Fedora that also
> was supposed to work with netcf but I don't have more details on that,
> 
> danken  - do you recall something more specific?

I'm afraid not - netcf-in-NM has been in the planning phase for quite
some time, but NetworkManager still does its own config file parsing.

Now that NM supports bridges, and due to its ubiquitousness on the
desktop, we may want to use it as an API to managing host networking,
instead of asking it "don't touch our config, mister!"
(NM_CONTROLLED=no).

Note that I haven't analysed NM's gaps for our use case, on top of my
issues of trusting a package with an UpperCase name.


From agl at us.ibm.com  Mon Aug 13 15:21:19 2012
From: agl at us.ibm.com (Adam Litke)
Date: Mon, 13 Aug 2012 10:21:19 -0500
Subject: Consumability of vdsm via libvdsm.so
Message-ID: <20120813152119.GD31190@aglitke>

Hi all,

We just finished a lively discussion regarding the ongoing effort to stabilize
the vdsm API using a C library called libvdsm.  There are many things that need
discussion, but I would like to focus this thread on one in particular:

Can ovirt-engine consume libvdsm via JNI?

libvdsm provides a full-featured C interface to the vdsm API using GObject.
Java bindings are provided automatically by jGIR[1].  The library communicates
with vdsmd using an internal transport which is not exposed to end users
(including ovirt-engine).  I would like to learn from folks with deep Java
knowledge if this approach is workable.  What are the technical challenges to
integrating in this way?  Please save discussion of AMQP and other bindings for
other threads.

Thanks!

[1] https://live.gnome.org/JGIR

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From garrett at redhat.com  Mon Aug 13 15:47:09 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Mon, 13 Aug 2012 17:47:09 +0200
Subject: introduction
Message-ID: <5029217D.5050107@redhat.com>

Hi everyone!

My name is Garrett LeSage and I'm a designer in the Open Source and 
Standards team (OSAS), working with Carl Trieloff, Dave Neary, Jason 
Brooks, Karsten Wade, Leslie Hawthorn, and a few other folks who 
frequent these lists. I have already met some of you at conferences (Red 
Hat Summit & GUADEC), and wanted to introduce myself to everyone here.

 From what I've seen so far, oVirt is a fantastic piece of 
virtualization technology and I'd like to help the project from a design 
perspective.

A bit of background about myself: I've been a Linux user since 1995 and 
I've contributed graphic design resources to Fedora, the Tango icon 
project, and Better Desktop. For the past few years, I was working at 
SUSE on cloud and virtualization products (such as SUSE Studio), and am 
happy to have recently re-joined Red Hat.  (:

For oVirt, I have started working on a new site structure (based on Dave 
Neary's work) and also have a few drafts for a new website look as well.

In the next few days, I'll be sending some of my already in-progress 
drafts to the lists for feedback. I look forward to all constructive 
responses --- positive, negative, and indifferent.

Thanks, and I'm looking forward to working with you all more!

Garrett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120813/cc4e8f90/attachment.html>

From ykaul at redhat.com  Mon Aug 13 15:49:21 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Mon, 13 Aug 2012 18:49:21 +0300
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <20120813152119.GD31190@aglitke>
References: <20120813152119.GD31190@aglitke>
Message-ID: <50292201.1000004@redhat.com>

On 08/13/2012 06:21 PM, Adam Litke wrote:
> Hi all,
>
> We just finished a lively discussion regarding the ongoing effort to stabilize
> the vdsm API using a C library called libvdsm.  There are many things that need
> discussion, but I would like to focus this thread on one in particular:
>
> Can ovirt-engine consume libvdsm via JNI?
>
> libvdsm provides a full-featured C interface to the vdsm API using GObject.
> Java bindings are provided automatically by jGIR[1].  The library communicates
> with vdsmd using an internal transport which is not exposed to end users
> (including ovirt-engine).  I would like to learn from folks with deep Java
> knowledge if this approach is workable.  What are the technical challenges to
> integrating in this way?  Please save discussion of AMQP and other bindings for
> other threads.
>
> Thanks!
>
> [1] https://live.gnome.org/JGIR

How mature/maintained is JGIR?
Last commit seems to be 2010-02-09.
The author is: Alexander Kurtakov <akurtako at redhat.com>
His status in our organizational chart:
Employee Type: Ex-employee

Y.

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120813/2f5404e6/attachment.html>

From smizrahi at redhat.com  Mon Aug 13 15:53:23 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Mon, 13 Aug 2012 11:53:23 -0400 (EDT)
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <50292201.1000004@redhat.com>
Message-ID: <1828009687.8843934.1344873203698.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Adam Litke" <agl at us.ibm.com>
> Cc: arch at ovirt.org
> Sent: Monday, August 13, 2012 11:49:21 AM
> Subject: Re: Consumability of vdsm via libvdsm.so
> 
> 
> 
> On 08/13/2012 06:21 PM, Adam Litke wrote:
> 
> 
> Hi all,
> 
> We just finished a lively discussion regarding the ongoing effort to
> stabilize
> the vdsm API using a C library called libvdsm.  There are many things
> that need
> discussion, but I would like to focus this thread on one in
> particular:
> 
> Can ovirt-engine consume libvdsm via JNI?
> 
> libvdsm provides a full-featured C interface to the vdsm API using
> GObject.
> Java bindings are provided automatically by jGIR[1].  The library
> communicates
> with vdsmd using an internal transport which is not exposed to end
> users
> (including ovirt-engine).  I would like to learn from folks with deep
> Java
> knowledge if this approach is workable.  What are the technical
> challenges to
> integrating in this way?  Please save discussion of AMQP and other
> bindings for
> other threads.
> 
> Thanks!
> 
> [1] https://live.gnome.org/JGIR
> How mature/maintained is JGIR?
> Last commit seems to be 2010-02-09.
> The author is: Alexander Kurtakov <akurtako at redhat.com>
> His status in our organizational chart:
> Employee Type: Ex-employee
It will need some work to get it up to par with the rest of the gobject generators
> 
> Y.
> 
> 
> 
> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From simon at redhat.com  Mon Aug 13 16:17:27 2012
From: simon at redhat.com (Simon Grinberg)
Date: Mon, 13 Aug 2012 12:17:27 -0400 (EDT)
Subject: introduction
In-Reply-To: <5029217D.5050107@redhat.com>
Message-ID: <890007484.4075503.1344874647110.JavaMail.root@redhat.com>

Welcome aboard 

----- Original Message -----

> From: "Garrett LeSage" <garrett at redhat.com>
> To: arch at ovirt.org, users at ovirt.org
> Sent: Monday, August 13, 2012 6:47:09 PM
> Subject: introduction

> Hi everyone!
> My name is Garrett LeSage and I'm a designer in the Open Source and
> Standards team (OSAS), working with Carl Trieloff, Dave Neary, Jason
> Brooks, Karsten Wade, Leslie Hawthorn, and a few other folks who
> frequent these lists. I have already met some of you at conferences
> (Red Hat Summit & GUADEC), and wanted to introduce myself to
> everyone here.
> From what I've seen so far, oVirt is a fantastic piece of
> virtualization technology and I'd like to help the project from a
> design perspective.
> A bit of background about myself: I've been a Linux user since 1995
> and I've contributed graphic design resources to Fedora, the Tango
> icon project, and Better Desktop. For the past few years, I was
> working at SUSE on cloud and virtualization products (such as SUSE
> Studio), and am happy to have recently re-joined Red Hat. (:
> For oVirt, I have started working on a new site structure (based on
> Dave Neary's work) and also have a few drafts for a new website look
> as well.
> In the next few days, I'll be sending some of my already in-progress
> drafts to the lists for feedback. I look forward to all constructive
> responses ? positive, negative, and indifferent.
> Thanks, and I'm looking forward to working with you all more!
> Garrett
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120813/9ef21da2/attachment.html>

From mkenneth at redhat.com  Mon Aug 13 16:20:11 2012
From: mkenneth at redhat.com (Miki Kenneth)
Date: Mon, 13 Aug 2012 12:20:11 -0400 (EDT)
Subject: [Users] introduction
In-Reply-To: <5029217D.5050107@redhat.com>
Message-ID: <17663438.2491.1344874806827.JavaMail.mkenneth@mkenneth.csb>

Welcome and good luck.

----- Original Message -----
> 
> 
> 
> 
> Hi everyone!
> 
> My name is Garrett LeSage and I'm a designer in the Open Source and
> Standards team (OSAS), working with Carl Trieloff, Dave Neary, Jason
> Brooks, Karsten Wade, Leslie Hawthorn, and a few other folks who
> frequent these lists. I have already met some of you at conferences
> (Red Hat Summit & GUADEC), and wanted to introduce myself to
> everyone here.
> 
> From what I've seen so far, oVirt is a fantastic piece of
> virtualization technology and I'd like to help the project from a
> design perspective.
> 
> A bit of background about myself: I've been a Linux user since 1995
> and I've contributed graphic design resources to Fedora, the Tango
> icon project, and Better Desktop. For the past few years, I was
> working at SUSE on cloud and virtualization products (such as SUSE
> Studio), and am happy to have recently re-joined Red Hat. (:
> 
> For oVirt, I have started working on a new site structure (based on
> Dave Neary's work) and also have a few drafts for a new website look
> as well.
> 
> In the next few days, I'll be sending some of my already in-progress
> drafts to the lists for feedback. I look forward to all constructive
> responses ? positive, negative, and indifferent.
> 
> Thanks, and I'm looking forward to working with you all more!
> 
> Garrett
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From abaron at redhat.com  Mon Aug 13 20:54:18 2012
From: abaron at redhat.com (Ayal Baron)
Date: Mon, 13 Aug 2012 16:54:18 -0400 (EDT)
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <1828009687.8843934.1344873203698.JavaMail.root@redhat.com>
Message-ID: <776631331.43563201.1344891258826.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Yaniv Kaul" <ykaul at redhat.com>
> > To: "Adam Litke" <agl at us.ibm.com>
> > Cc: arch at ovirt.org
> > Sent: Monday, August 13, 2012 11:49:21 AM
> > Subject: Re: Consumability of vdsm via libvdsm.so
> > 
> > 
> > 
> > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > 
> > 
> > Hi all,
> > 
> > We just finished a lively discussion regarding the ongoing effort
> > to
> > stabilize
> > the vdsm API using a C library called libvdsm.  There are many
> > things
> > that need
> > discussion, but I would like to focus this thread on one in
> > particular:
> > 
> > Can ovirt-engine consume libvdsm via JNI?
> > 
> > libvdsm provides a full-featured C interface to the vdsm API using
> > GObject.
> > Java bindings are provided automatically by jGIR[1].  The library
> > communicates
> > with vdsmd using an internal transport which is not exposed to end
> > users
> > (including ovirt-engine).  I would like to learn from folks with
> > deep
> > Java
> > knowledge if this approach is workable.  What are the technical
> > challenges to
> > integrating in this way?  Please save discussion of AMQP and other
> > bindings for
> > other threads.
> > 
> > Thanks!
> > 
> > [1] https://live.gnome.org/JGIR
> > How mature/maintained is JGIR?
> > Last commit seems to be 2010-02-09.
> > The author is: Alexander Kurtakov <akurtako at redhat.com>
> > His status in our organizational chart:
> > Employee Type: Ex-employee
> It will need some work to get it up to par with the rest of the
> gobject generators

It's been dead since 2009, that doesn't seem very promising (http://www.ohloh.net/p/java-gobject-introspection)

It also states: "It also includes a custom GLib/GObject interface layer adapted from gstreamer-java." and looking at gstreamer-java yields: "An unofficial/alternative set of java bindings for the gstreamer multimedia framework"

Again, doesn't look like something you want to base your API on.
Sounds to me like the 'free' java bindings come at a very high cost (bringing JGIR up to date and maintaining it).

What are the alternatives?

> > 
> > Y.
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From robert at middleswarth.net  Tue Aug 14 05:43:06 2012
From: robert at middleswarth.net (Robert Middleswarth)
Date: Tue, 14 Aug 2012 01:43:06 -0400
Subject: Jenkins testing.
Message-ID: <5029E56A.8070909@middleswarth.net>

After a few false starts it looks like we have per patch testing working 
on VDSM, oVirt-engine, oVirt-engine-sdk and oVirt-engine-cli.  There are 
3 status a patch can get.  1) Success - Means the patch ran though the 
tests without issue.  2) Failure - Means the tests failed.  3) Aborted - 
Generally means the submitter is not in the whitelist and the tests were 
never run.  If you have any questions please feel free to ask.

-- 
Thanks
Robert Middleswarth
@rmiddle (twitter/IRC)



From eedri at redhat.com  Tue Aug 14 07:22:13 2012
From: eedri at redhat.com (Eyal Edri)
Date: Tue, 14 Aug 2012 03:22:13 -0400 (EDT)
Subject: Jenkins testing.
In-Reply-To: <5029E56A.8070909@middleswarth.net>
Message-ID: <1133835900.4334166.1344928933385.JavaMail.root@redhat.com>

Great job!

I know it required a great effort and time to make this work so kudos for making it happen.

Eyal.

----- Original Message -----
> From: "Robert Middleswarth" <robert at middleswarth.net>
> To: "infra" <infra at ovirt.org>, engine-devel at ovirt.org, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, August 14, 2012 8:43:06 AM
> Subject: Jenkins testing.
> 
> After a few false starts it looks like we have per patch testing
> working
> on VDSM, oVirt-engine, oVirt-engine-sdk and oVirt-engine-cli.  There
> are
> 3 status a patch can get.  1) Success - Means the patch ran though
> the
> tests without issue.  2) Failure - Means the tests failed.  3)
> Aborted -
> Generally means the submitter is not in the whitelist and the tests
> were
> never run.  If you have any questions please feel free to ask.
> 
> --
> Thanks
> Robert Middleswarth
> @rmiddle (twitter/IRC)
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From deepakcs at linux.vnet.ibm.com  Tue Aug 14 07:22:11 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Tue, 14 Aug 2012 12:52:11 +0530
Subject: [vdsm] Jenkins testing.
In-Reply-To: <5029E56A.8070909@middleswarth.net>
References: <5029E56A.8070909@middleswarth.net>
Message-ID: <5029FCA3.90109@linux.vnet.ibm.com>

On 08/14/2012 11:13 AM, Robert Middleswarth wrote:
> After a few false starts it looks like we have per patch testing 
> working on VDSM, oVirt-engine, oVirt-engine-sdk and oVirt-engine-cli.  
> There are 3 status a patch can get.  1) Success - Means the patch ran 
> though the tests without issue.  2) Failure - Means the tests failed.  
> 3) Aborted - Generally means the submitter is not in the whitelist and 
> the tests were never run.  If you have any questions please feel free 
> to ask.
>
So what is needed for the submitted to be in whitelist ?
I once for Success for few of my patches.. then got failure for some 
other patch( maybe thats due to the false starts u had) and then for the 
latest patch of mine, it says aborted.

So not sure if i am in whitelist or not ?
If not, what do i need to do to be part of it ?
If yes, why did the build abort for my latest patch ?



From deepakcs at linux.vnet.ibm.com  Tue Aug 14 08:54:31 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Tue, 14 Aug 2012 14:24:31 +0530
Subject: [vdsm] Jenkins testing.
In-Reply-To: <5029FCA3.90109@linux.vnet.ibm.com>
References: <5029E56A.8070909@middleswarth.net>
	<5029FCA3.90109@linux.vnet.ibm.com>
Message-ID: <502A1247.3060508@linux.vnet.ibm.com>

On 08/14/2012 12:52 PM, Deepak C Shetty wrote:
> On 08/14/2012 11:13 AM, Robert Middleswarth wrote:
>> After a few false starts it looks like we have per patch testing 
>> working on VDSM, oVirt-engine, oVirt-engine-sdk and 
>> oVirt-engine-cli.  There are 3 status a patch can get.  1) Success - 
>> Means the patch ran though the tests without issue.  2) Failure - 
>> Means the tests failed.  3) Aborted - Generally means the submitter 
>> is not in the whitelist and the tests were never run.  If you have 
>> any questions please feel free to ask.
>>
> So what is needed for the submitted to be in whitelist ?
> I once for Success for few of my patches.. then got failure for some 
> other patch( maybe thats due to the false starts u had) and then for 
> the latest patch of mine, it says aborted.
>
> So not sure if i am in whitelist or not ?
> If not, what do i need to do to be part of it ?
> If yes, why did the build abort for my latest patch ?
>
Pls see http://gerrit.ovirt.org/#/c/6856/
For patch1 it says build success, for patch 2, it says aborted.. why ?



From danken at redhat.com  Tue Aug 14 09:51:11 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 14 Aug 2012 12:51:11 +0300
Subject: [vdsm] Jenkins testing.
In-Reply-To: <5029E56A.8070909@middleswarth.net>
References: <5029E56A.8070909@middleswarth.net>
Message-ID: <20120814095111.GA12200@redhat.com>

On Tue, Aug 14, 2012 at 01:43:06AM -0400, Robert Middleswarth wrote:
> After a few false starts it looks like we have per patch testing
> working on VDSM, oVirt-engine, oVirt-engine-sdk and
> oVirt-engine-cli.  There are 3 status a patch can get.  1) Success -
> Means the patch ran though the tests without issue.  2) Failure -
> Means the tests failed.  3) Aborted - Generally means the submitter
> is not in the whitelist and the tests were never run.  If you have
> any questions please feel free to ask.

Thanks Robert, for this great improvement.

However, it seems to me that the script is pulling the wrong git hash.
For example, my patch http://gerrit.ovirt.org/#/c/7097/ with git has
539ccfbf02f0ca9605149885ae6b3e6feb4f1976 reports of success. However the
console output
http://jenkins.ovirt.info/job/patch_vdsm_unit_tests/417/console
show that the git hash that was actually built was
8af050b205994746198e5fb257652cd2fb8bfbc1 (vdsm/master)

Something is fishy here, and I may be getting false positive results.

Regards,
Dan.


From eedri at redhat.com  Tue Aug 14 10:20:11 2012
From: eedri at redhat.com (Eyal Edri)
Date: Tue, 14 Aug 2012 06:20:11 -0400 (EDT)
Subject: [Engine-devel] [vdsm] Jenkins testing.
In-Reply-To: <502A1247.3060508@linux.vnet.ibm.com>
Message-ID: <560190193.4470348.1344939611714.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> To: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> Cc: engine-devel at ovirt.org, "arch" <arch at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>,
> "infra" <infra at ovirt.org>
> Sent: Tuesday, August 14, 2012 11:54:31 AM
> Subject: Re: [Engine-devel] [vdsm] Jenkins testing.
> 
> On 08/14/2012 12:52 PM, Deepak C Shetty wrote:
> > On 08/14/2012 11:13 AM, Robert Middleswarth wrote:
> >> After a few false starts it looks like we have per patch testing
> >> working on VDSM, oVirt-engine, oVirt-engine-sdk and
> >> oVirt-engine-cli.  There are 3 status a patch can get.  1) Success
> >> -
> >> Means the patch ran though the tests without issue.  2) Failure -
> >> Means the tests failed.  3) Aborted - Generally means the
> >> submitter
> >> is not in the whitelist and the tests were never run.  If you have
> >> any questions please feel free to ask.
> >>
> > So what is needed for the submitted to be in whitelist ?
> > I once for Success for few of my patches.. then got failure for
> > some
> > other patch( maybe thats due to the false starts u had) and then
> > for
> > the latest patch of mine, it says aborted.
> >
> > So not sure if i am in whitelist or not ?
> > If not, what do i need to do to be part of it ?
> > If yes, why did the build abort for my latest patch ?
> >
> Pls see http://gerrit.ovirt.org/#/c/6856/
> For patch1 it says build success, for patch 2, it says aborted.. why
> ?
> 

it's because your email address wasn't in the jenkins-whitelist.txt file.
this file includes emails address for users that jenkins will allow running test jobs on thier patches.
this was introduced as a way for defending the jenkins from malicious users that might send harmful patches to jenkins.

i've added you to the whitelist, you should be ok now.

the list was generated automaticly from git log, so it still might missing known people,
if anyone sees this aborted msg in the gerrit, please contact infra team so he can be added to the whitelist.

Eyal.

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From agl at us.ibm.com  Tue Aug 14 14:09:28 2012
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 14 Aug 2012 09:09:28 -0500
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <776631331.43563201.1344891258826.JavaMail.root@redhat.com>
References: <1828009687.8843934.1344873203698.JavaMail.root@redhat.com>
	<776631331.43563201.1344891258826.JavaMail.root@redhat.com>
Message-ID: <20120814140928.GB6674@aglitke>

On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Yaniv Kaul" <ykaul at redhat.com>
> > > To: "Adam Litke" <agl at us.ibm.com>
> > > Cc: arch at ovirt.org
> > > Sent: Monday, August 13, 2012 11:49:21 AM
> > > Subject: Re: Consumability of vdsm via libvdsm.so
> > > 
> > > 
> > > 
> > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > 
> > > 
> > > Hi all,
> > > 
> > > We just finished a lively discussion regarding the ongoing effort
> > > to
> > > stabilize
> > > the vdsm API using a C library called libvdsm.  There are many
> > > things
> > > that need
> > > discussion, but I would like to focus this thread on one in
> > > particular:
> > > 
> > > Can ovirt-engine consume libvdsm via JNI?
> > > 
> > > libvdsm provides a full-featured C interface to the vdsm API using
> > > GObject.
> > > Java bindings are provided automatically by jGIR[1].  The library
> > > communicates
> > > with vdsmd using an internal transport which is not exposed to end
> > > users
> > > (including ovirt-engine).  I would like to learn from folks with
> > > deep
> > > Java
> > > knowledge if this approach is workable.  What are the technical
> > > challenges to
> > > integrating in this way?  Please save discussion of AMQP and other
> > > bindings for
> > > other threads.
> > > 
> > > Thanks!
> > > 
> > > [1] https://live.gnome.org/JGIR
> > > How mature/maintained is JGIR?
> > > Last commit seems to be 2010-02-09.
> > > The author is: Alexander Kurtakov <akurtako at redhat.com>
> > > His status in our organizational chart:
> > > Employee Type: Ex-employee
> > It will need some work to get it up to par with the rest of the
> > gobject generators
> 
> It's been dead since 2009, that doesn't seem very promising (http://www.ohloh.net/p/java-gobject-introspection)
> 
> It also states: "It also includes a custom GLib/GObject interface layer adapted from gstreamer-java." and looking at gstreamer-java yields: "An unofficial/alternative set of java bindings for the gstreamer multimedia framework"
> 
> Again, doesn't look like something you want to base your API on.
> Sounds to me like the 'free' java bindings come at a very high cost (bringing JGIR up to date and maintaining it).
> 
> What are the alternatives?

There are two other alternatives (and one bad idea) that come to mind:

1.) Generate our own Java bindings to libvdsm.so during the vdsm build process.

I prefer this option from an API cleanliness POV because the transport code
would only be written once (in libvdsm.so).  This form of generation should be
simple because we are just wrapping the library so it can be called via JNI.


2.) Generate a native Java "library" that is equivalent to libvdsm.so.

This gets us into the business of libvirt-style bindings generation which I
think is a mistake.  It opens the door to us maintaining parallel
implementations of "libvdsm"s (one per language). 


-1.) Standardize the transport around JSON-RPC and make that the supported
interface.

I am only mentioning it because I am certain someone will bring it up.  I think
it's a bad idea and it's off-topic for this particular thread anyway.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From smizrahi at redhat.com  Tue Aug 14 14:20:34 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 14 Aug 2012 10:20:34 -0400 (EDT)
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <20120814140928.GB6674@aglitke>
Message-ID: <236479023.9410625.1344954034847.JavaMail.root@redhat.com>

I have an Idea, having json rpc for the over HTTP and 2 way json RPC over openstacks' messaging abstraction layer.

This means we have 1 actual code base, the interfaces are on the transport layer.
And if you choose to use messaging you (in the future) get 2 way communication which means we can use.
Json-RPC notification for events. And that we (in the future) might fit to an openstack cluster.

I still think generating the java bindings is preferable as it will have to be done and having it generated straight from the schema is ideal.


----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Ayal Baron" <abaron at redhat.com>
> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, arch at ovirt.org
> Sent: Tuesday, August 14, 2012 10:09:28 AM
> Subject: Re: Consumability of vdsm via libvdsm.so
> 
> On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Yaniv Kaul" <ykaul at redhat.com>
> > > > To: "Adam Litke" <agl at us.ibm.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Monday, August 13, 2012 11:49:21 AM
> > > > Subject: Re: Consumability of vdsm via libvdsm.so
> > > > 
> > > > 
> > > > 
> > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > 
> > > > 
> > > > Hi all,
> > > > 
> > > > We just finished a lively discussion regarding the ongoing
> > > > effort
> > > > to
> > > > stabilize
> > > > the vdsm API using a C library called libvdsm.  There are many
> > > > things
> > > > that need
> > > > discussion, but I would like to focus this thread on one in
> > > > particular:
> > > > 
> > > > Can ovirt-engine consume libvdsm via JNI?
> > > > 
> > > > libvdsm provides a full-featured C interface to the vdsm API
> > > > using
> > > > GObject.
> > > > Java bindings are provided automatically by jGIR[1].  The
> > > > library
> > > > communicates
> > > > with vdsmd using an internal transport which is not exposed to
> > > > end
> > > > users
> > > > (including ovirt-engine).  I would like to learn from folks
> > > > with
> > > > deep
> > > > Java
> > > > knowledge if this approach is workable.  What are the technical
> > > > challenges to
> > > > integrating in this way?  Please save discussion of AMQP and
> > > > other
> > > > bindings for
> > > > other threads.
> > > > 
> > > > Thanks!
> > > > 
> > > > [1] https://live.gnome.org/JGIR
> > > > How mature/maintained is JGIR?
> > > > Last commit seems to be 2010-02-09.
> > > > The author is: Alexander Kurtakov <akurtako at redhat.com>
> > > > His status in our organizational chart:
> > > > Employee Type: Ex-employee
> > > It will need some work to get it up to par with the rest of the
> > > gobject generators
> > 
> > It's been dead since 2009, that doesn't seem very promising
> > (http://www.ohloh.net/p/java-gobject-introspection)
> > 
> > It also states: "It also includes a custom GLib/GObject interface
> > layer adapted from gstreamer-java." and looking at gstreamer-java
> > yields: "An unofficial/alternative set of java bindings for the
> > gstreamer multimedia framework"
> > 
> > Again, doesn't look like something you want to base your API on.
> > Sounds to me like the 'free' java bindings come at a very high cost
> > (bringing JGIR up to date and maintaining it).
> > 
> > What are the alternatives?
> 
> There are two other alternatives (and one bad idea) that come to
> mind:
> 
> 1.) Generate our own Java bindings to libvdsm.so during the vdsm
> build process.
> 
> I prefer this option from an API cleanliness POV because the
> transport code
> would only be written once (in libvdsm.so).  This form of generation
> should be
> simple because we are just wrapping the library so it can be called
> via JNI.
> 
> 
> 2.) Generate a native Java "library" that is equivalent to
> libvdsm.so.
> 
> This gets us into the business of libvirt-style bindings generation
> which I
> think is a mistake.  It opens the door to us maintaining parallel
> implementations of "libvdsm"s (one per language).
> 
> 
> -1.) Standardize the transport around JSON-RPC and make that the
> supported
> interface.
> 
> I am only mentioning it because I am certain someone will bring it
> up.  I think
> it's a bad idea and it's off-topic for this particular thread anyway.
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> 


From yzaslavs at redhat.com  Tue Aug 14 16:35:03 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 14 Aug 2012 19:35:03 +0300
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <20120814140928.GB6674@aglitke>
References: <1828009687.8843934.1344873203698.JavaMail.root@redhat.com>
	<776631331.43563201.1344891258826.JavaMail.root@redhat.com>
	<20120814140928.GB6674@aglitke>
Message-ID: <502A7E37.7060907@redhat.com>



On 08/14/2012 05:09 PM, Adam Litke wrote:
> On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
>>
>>
>> ----- Original Message -----
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>>> To: "Adam Litke" <agl at us.ibm.com>
>>>> Cc: arch at ovirt.org
>>>> Sent: Monday, August 13, 2012 11:49:21 AM
>>>> Subject: Re: Consumability of vdsm via libvdsm.so
>>>>
>>>>
>>>>
>>>> On 08/13/2012 06:21 PM, Adam Litke wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> We just finished a lively discussion regarding the ongoing effort
>>>> to
>>>> stabilize
>>>> the vdsm API using a C library called libvdsm.  There are many
>>>> things
>>>> that need
>>>> discussion, but I would like to focus this thread on one in
>>>> particular:
>>>>
>>>> Can ovirt-engine consume libvdsm via JNI?
>>>>
>>>> libvdsm provides a full-featured C interface to the vdsm API using
>>>> GObject.
>>>> Java bindings are provided automatically by jGIR[1].  The library
>>>> communicates
>>>> with vdsmd using an internal transport which is not exposed to end
>>>> users
>>>> (including ovirt-engine).  I would like to learn from folks with
>>>> deep
>>>> Java
>>>> knowledge if this approach is workable.  What are the technical
>>>> challenges to
>>>> integrating in this way?  Please save discussion of AMQP and other
>>>> bindings for
>>>> other threads.
>>>>
>>>> Thanks!
>>>>
>>>> [1] https://live.gnome.org/JGIR
>>>> How mature/maintained is JGIR?
>>>> Last commit seems to be 2010-02-09.
>>>> The author is: Alexander Kurtakov <akurtako at redhat.com>
>>>> His status in our organizational chart:
>>>> Employee Type: Ex-employee
>>> It will need some work to get it up to par with the rest of the
>>> gobject generators
>>
>> It's been dead since 2009, that doesn't seem very promising (http://www.ohloh.net/p/java-gobject-introspection)
>>
>> It also states: "It also includes a custom GLib/GObject interface layer adapted from gstreamer-java." and looking at gstreamer-java yields: "An unofficial/alternative set of java bindings for the gstreamer multimedia framework"
>>
>> Again, doesn't look like something you want to base your API on.
>> Sounds to me like the 'free' java bindings come at a very high cost (bringing JGIR up to date and maintaining it).
>>
>> What are the alternatives?

Hi Adam,
Bare in mind that invoking JNI from Java EE violates Java EE spec.
In addition, if you have a bug at your library (i.e - you build some 
abstraction layer library above some C API in order to simplify calls 
that will be made from java code) - this bug may cause segmentation 
fault, which will cause your JVM to crash -> meaning your jboss 
application server will crash.
I know we only run the engine enterprise application on Jboss (although 
an application server can co-host several application servers - in this 
case, your penalty will be higher).
What I've seen in some enterprise application is a light java server 
serving an application server to invoke risky/native code.
You of course pay for the traffic between the application server and 
this "jni server" but at least you guarantee your application server 
does not crash.

These are my 2 cents on this subject

Yair


>
> There are two other alternatives (and one bad idea) that come to mind:
>
> 1.) Generate our own Java bindings to libvdsm.so during the vdsm build process.
>
> I prefer this option from an API cleanliness POV because the transport code
> would only be written once (in libvdsm.so).  This form of generation should be
> simple because we are just wrapping the library so it can be called via JNI.
>
>
> 2.) Generate a native Java "library" that is equivalent to libvdsm.so.
>
> This gets us into the business of libvirt-style bindings generation which I
> think is a mistake.  It opens the door to us maintaining parallel
> implementations of "libvdsm"s (one per language).
>
>
> -1.) Standardize the transport around JSON-RPC and make that the supported
> interface.
>
> I am only mentioning it because I am certain someone will bring it up.  I think
> it's a bad idea and it's off-topic for this particular thread anyway.
>


From agl at us.ibm.com  Tue Aug 14 16:36:47 2012
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 14 Aug 2012 11:36:47 -0500
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <236479023.9410625.1344954034847.JavaMail.root@redhat.com>
References: <20120814140928.GB6674@aglitke>
	<236479023.9410625.1344954034847.JavaMail.root@redhat.com>
Message-ID: <20120814163647.GC6674@aglitke>

On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi wrote:
> I have an Idea, having json rpc for the over HTTP and 2 way json RPC over
> openstacks' messaging abstraction layer.

So you are proposing to disregard all of the arguments in favor of a libvdsm and
instead standardize on a protocol.  In that case, we could just keep xmlrpc...
We will be back at square one having every application writing on object model
on top of the transport.  We will also need to reinvent a model for ensuring
backwards compatibility of the protocol data."

> This means we have 1 actual code base, the interfaces are on the transport
> layer.  And if you choose to use messaging you (in the future) get 2 way
> communication which means we can use.  Json-RPC notification for events. And
> that we (in the future) might fit to an openstack cluster.

> I still think generating the java bindings is preferable as it will have to be
> done and having it generated straight from the schema is ideal.

In that case we will also need to generate python bindings at a minimum.  In
this model, how would REST and AMQP bridges be integrated?

> 
> ----- Original Message -----
> > From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron" <abaron at redhat.com> Cc:
> > "Saggi Mizrahi" <smizrahi at redhat.com>, arch at ovirt.org Sent: Tuesday, August
> > 14, 2012 10:09:28 AM Subject: Re: Consumability of vdsm via libvdsm.so
> > 
> > On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam Litke"
> > > > > <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday, August 13, 2012
> > > > > 11:49:21 AM Subject: Re: Consumability of vdsm via libvdsm.so
> > > > > 
> > > > > 
> > > > > 
> > > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > > 
> > > > > 
> > > > > Hi all,
> > > > > 
> > > > > We just finished a lively discussion regarding the ongoing effort to
> > > > > stabilize the vdsm API using a C library called libvdsm.  There are
> > > > > many things that need discussion, but I would like to focus this
> > > > > thread on one in particular:
> > > > > 
> > > > > Can ovirt-engine consume libvdsm via JNI?
> > > > > 
> > > > > libvdsm provides a full-featured C interface to the vdsm API using
> > > > > GObject.  Java bindings are provided automatically by jGIR[1].  The
> > > > > library communicates with vdsmd using an internal transport which is
> > > > > not exposed to end users (including ovirt-engine).  I would like to
> > > > > learn from folks with deep Java knowledge if this approach is
> > > > > workable.  What are the technical challenges to integrating in this
> > > > > way?  Please save discussion of AMQP and other bindings for other
> > > > > threads.
> > > > > 
> > > > > Thanks!
> > > > > 
> > > > > [1] https://live.gnome.org/JGIR How mature/maintained is JGIR?  Last
> > > > > commit seems to be 2010-02-09.  The author is: Alexander Kurtakov
> > > > > <akurtako at redhat.com> His status in our organizational chart: Employee
> > > > > Type: Ex-employee
> > > > It will need some work to get it up to par with the rest of the gobject
> > > > generators
> > > 
> > > It's been dead since 2009, that doesn't seem very promising
> > > (http://www.ohloh.net/p/java-gobject-introspection)
> > > 
> > > It also states: "It also includes a custom GLib/GObject interface layer
> > > adapted from gstreamer-java." and looking at gstreamer-java yields: "An
> > > unofficial/alternative set of java bindings for the gstreamer multimedia
> > > framework"
> > > 
> > > Again, doesn't look like something you want to base your API on.  Sounds
> > > to me like the 'free' java bindings come at a very high cost (bringing
> > > JGIR up to date and maintaining it).
> > > 
> > > What are the alternatives?
> > 
> > There are two other alternatives (and one bad idea) that come to mind:
> > 
> > 1.) Generate our own Java bindings to libvdsm.so during the vdsm build
> > process.
> > 
> > I prefer this option from an API cleanliness POV because the transport code
> > would only be written once (in libvdsm.so).  This form of generation should
> > be simple because we are just wrapping the library so it can be called via
> > JNI.
> > 
> > 
> > 2.) Generate a native Java "library" that is equivalent to libvdsm.so.
> > 
> > This gets us into the business of libvirt-style bindings generation which I
> > think is a mistake.  It opens the door to us maintaining parallel
> > implementations of "libvdsm"s (one per language).
> > 
> > 
> > -1.) Standardize the transport around JSON-RPC and make that the supported
> > interface.
> > 
> > I am only mentioning it because I am certain someone will bring it up.  I
> > think it's a bad idea and it's off-topic for this particular thread anyway.
> > 
> > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > 
> > 
> 

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From yzaslavs at redhat.com  Tue Aug 14 16:45:06 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 14 Aug 2012 19:45:06 +0300
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <20120814163647.GC6674@aglitke>
References: <20120814140928.GB6674@aglitke>
	<236479023.9410625.1344954034847.JavaMail.root@redhat.com>
	<20120814163647.GC6674@aglitke>
Message-ID: <502A8092.808@redhat.com>



On 08/14/2012 07:36 PM, Adam Litke wrote:
> On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi wrote:
>> I have an Idea, having json rpc for the over HTTP and 2 way json RPC over
>> openstacks' messaging abstraction layer.

Saggi, missed your idea for some reason -
+1 on your idea (following my comment to Adam regarding JNI and Java EE).

>
> So you are proposing to disregard all of the arguments in favor of a libvdsm and
> instead standardize on a protocol.  In that case, we could just keep xmlrpc...
> We will be back at square one having every application writing on object model
> on top of the transport.  We will also need to reinvent a model for ensuring
> backwards compatibility of the protocol data."

Adam,
When you use JNI, you generate java classes.
We can consider these classes as our "Java API" to the C library.
Why not have some dynamic proxy invoking this "Java API" in some IPC 
manner - there are plenty of frameworks to provide that.
We can use json as the format of the payload for the underlying 
transport (or some other format, XML, binary, etc..., this is just some 
"very high level design thought" I have).

>
>> This means we have 1 actual code base, the interfaces are on the transport
>> layer.  And if you choose to use messaging you (in the future) get 2 way
>> communication which means we can use.  Json-RPC notification for events. And
>> that we (in the future) might fit to an openstack cluster.
>
>> I still think generating the java bindings is preferable as it will have to be
>> done and having it generated straight from the schema is ideal.
>
> In that case we will also need to generate python bindings at a minimum.  In
> this model, how would REST and AMQP bridges be integrated?
>
>>
>> ----- Original Message -----
>>> From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron" <abaron at redhat.com> Cc:
>>> "Saggi Mizrahi" <smizrahi at redhat.com>, arch at ovirt.org Sent: Tuesday, August
>>> 14, 2012 10:09:28 AM Subject: Re: Consumability of vdsm via libvdsm.so
>>>
>>> On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam Litke"
>>>>>> <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday, August 13, 2012
>>>>>> 11:49:21 AM Subject: Re: Consumability of vdsm via libvdsm.so
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/13/2012 06:21 PM, Adam Litke wrote:
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We just finished a lively discussion regarding the ongoing effort to
>>>>>> stabilize the vdsm API using a C library called libvdsm.  There are
>>>>>> many things that need discussion, but I would like to focus this
>>>>>> thread on one in particular:
>>>>>>
>>>>>> Can ovirt-engine consume libvdsm via JNI?
>>>>>>
>>>>>> libvdsm provides a full-featured C interface to the vdsm API using
>>>>>> GObject.  Java bindings are provided automatically by jGIR[1].  The
>>>>>> library communicates with vdsmd using an internal transport which is
>>>>>> not exposed to end users (including ovirt-engine).  I would like to
>>>>>> learn from folks with deep Java knowledge if this approach is
>>>>>> workable.  What are the technical challenges to integrating in this
>>>>>> way?  Please save discussion of AMQP and other bindings for other
>>>>>> threads.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> [1] https://live.gnome.org/JGIR How mature/maintained is JGIR?  Last
>>>>>> commit seems to be 2010-02-09.  The author is: Alexander Kurtakov
>>>>>> <akurtako at redhat.com> His status in our organizational chart: Employee
>>>>>> Type: Ex-employee
>>>>> It will need some work to get it up to par with the rest of the gobject
>>>>> generators
>>>>
>>>> It's been dead since 2009, that doesn't seem very promising
>>>> (http://www.ohloh.net/p/java-gobject-introspection)
>>>>
>>>> It also states: "It also includes a custom GLib/GObject interface layer
>>>> adapted from gstreamer-java." and looking at gstreamer-java yields: "An
>>>> unofficial/alternative set of java bindings for the gstreamer multimedia
>>>> framework"
>>>>
>>>> Again, doesn't look like something you want to base your API on.  Sounds
>>>> to me like the 'free' java bindings come at a very high cost (bringing
>>>> JGIR up to date and maintaining it).
>>>>
>>>> What are the alternatives?
>>>
>>> There are two other alternatives (and one bad idea) that come to mind:
>>>
>>> 1.) Generate our own Java bindings to libvdsm.so during the vdsm build
>>> process.
>>>
>>> I prefer this option from an API cleanliness POV because the transport code
>>> would only be written once (in libvdsm.so).  This form of generation should
>>> be simple because we are just wrapping the library so it can be called via
>>> JNI.
>>>
>>>
>>> 2.) Generate a native Java "library" that is equivalent to libvdsm.so.
>>>
>>> This gets us into the business of libvirt-style bindings generation which I
>>> think is a mistake.  It opens the door to us maintaining parallel
>>> implementations of "libvdsm"s (one per language).
>>>
>>>
>>> -1.) Standardize the transport around JSON-RPC and make that the supported
>>> interface.
>>>
>>> I am only mentioning it because I am certain someone will bring it up.  I
>>> think it's a bad idea and it's off-topic for this particular thread anyway.
>>>
>>> -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
>>>
>>>
>>
>


From smizrahi at redhat.com  Tue Aug 14 17:43:01 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 14 Aug 2012 13:43:01 -0400 (EDT)
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <20120814163647.GC6674@aglitke>
Message-ID: <1439758794.9499554.1344966181299.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> Sent: Tuesday, August 14, 2012 12:36:47 PM
> Subject: Re: Consumability of vdsm via libvdsm.so
> 
> On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi wrote:
> > I have an Idea, having json rpc for the over HTTP and 2 way json
> > RPC over
> > openstacks' messaging abstraction layer.
> 
> So you are proposing to disregard all of the arguments in favor of a
> libvdsm and
> instead standardize on a protocol.  In that case, we could just keep
> xmlrpc...
The difference between xml-rpc and json-rpc is that json-rpc is transport agnostic, less verbose, easier to parse.
> We will be back at square one having every application writing on
> object model
> on top of the transport.  We will also need to reinvent a model for
> ensuring
> backwards compatibility of the protocol data."
As I said, I still think we need to have a schema and supply bindings, GObject for python\C\C++\Vala, and native Java (because, as Yair pointed out, JNI in Java EE is non standard).
> 
> > This means we have 1 actual code base, the interfaces are on the
> > transport
> > layer.  And if you choose to use messaging you (in the future) get
> > 2 way
> > communication which means we can use.  Json-RPC notification for
> > events. And
> > that we (in the future) might fit to an openstack cluster.
> 
> > I still think generating the java bindings is preferable as it will
> > have to be
> > done and having it generated straight from the schema is ideal.
> 
> In that case we will also need to generate python bindings at a
> minimum.  In
> this model, how would REST and AMQP bridges be integrated?
No REST, as I said. We forgo the "everything ever can be supported" for json-rpc over different transports. HTTP\AMQP\ZMQ\Simple TCP Socket.
Unlike supporting different API schemes supporting transports is fairly simple because the number of methods to implement is small and remains constant and is independent of the actual API.

The big reason to use bindings is to keep us transport agnositc. Something that REST or SOAP or XML-RPC don't give us because they are bound to HTTP.

We could also "extend" on JSON-RPC by being able to switch serializers giving us the ability to support BSON and protobuff as long as the clients adhere to the strong types in the schema.
Unlike XML-RPC that uses advanced XML features, JSON-RPC can really be any serialized object. So technically, if de\serialization becomes an issue we could put high performance serializers as configurable options for very large scale deployments.

JSON-RPC also supports extension methods that can be used to extend the protocol.

As I see it this solves all the issues that were preventing us from committing to a protocoll.
* We don't want to be bound to a single transport. (Transport agnostic)
* We don't want to be bound to a single serializer (Solved with optional extension that could be added when we need it)
* 2 way communication (if you use anything other then HTTP you have that)
* low latency (If you use anything other then HTTP you have that too)
* Removal of calls that are actually a group of calls (eg. connectStorageServers vs connectStorageServer) - Even with HTTP, JSON-RPC supports request lists which give the expected semantic.
* Simple set-up. Using ZMQ, HTTP or TCP Socket you can setup VDSM without a broker.
* Don't have a lot of big classes for bindings. Because we bind int the transport level the amount of methods per transport is minimal and constant.
* We provide the bindings. Bindings we'll be available and generated from the schema. So there is no problem with the (everyone needs to write their own bindings).
* Allow bridges. Someone can still write a lightweight REST bridge over the bindings\socket.

Is there something that this doesn't solve?
> 
> > 
> > ----- Original Message -----
> > > From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron"
> > > <abaron at redhat.com> Cc:
> > > "Saggi Mizrahi" <smizrahi at redhat.com>, arch at ovirt.org Sent:
> > > Tuesday, August
> > > 14, 2012 10:09:28 AM Subject: Re: Consumability of vdsm via
> > > libvdsm.so
> > > 
> > > On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam Litke"
> > > > > > <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday, August
> > > > > > 13, 2012
> > > > > > 11:49:21 AM Subject: Re: Consumability of vdsm via
> > > > > > libvdsm.so
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > > > 
> > > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > We just finished a lively discussion regarding the ongoing
> > > > > > effort to
> > > > > > stabilize the vdsm API using a C library called libvdsm.
> > > > > >  There are
> > > > > > many things that need discussion, but I would like to focus
> > > > > > this
> > > > > > thread on one in particular:
> > > > > > 
> > > > > > Can ovirt-engine consume libvdsm via JNI?
> > > > > > 
> > > > > > libvdsm provides a full-featured C interface to the vdsm
> > > > > > API using
> > > > > > GObject.  Java bindings are provided automatically by
> > > > > > jGIR[1].  The
> > > > > > library communicates with vdsmd using an internal transport
> > > > > > which is
> > > > > > not exposed to end users (including ovirt-engine).  I would
> > > > > > like to
> > > > > > learn from folks with deep Java knowledge if this approach
> > > > > > is
> > > > > > workable.  What are the technical challenges to integrating
> > > > > > in this
> > > > > > way?  Please save discussion of AMQP and other bindings for
> > > > > > other
> > > > > > threads.
> > > > > > 
> > > > > > Thanks!
> > > > > > 
> > > > > > [1] https://live.gnome.org/JGIR How mature/maintained is
> > > > > > JGIR?  Last
> > > > > > commit seems to be 2010-02-09.  The author is: Alexander
> > > > > > Kurtakov
> > > > > > <akurtako at redhat.com> His status in our organizational
> > > > > > chart: Employee
> > > > > > Type: Ex-employee
> > > > > It will need some work to get it up to par with the rest of
> > > > > the gobject
> > > > > generators
> > > > 
> > > > It's been dead since 2009, that doesn't seem very promising
> > > > (http://www.ohloh.net/p/java-gobject-introspection)
> > > > 
> > > > It also states: "It also includes a custom GLib/GObject
> > > > interface layer
> > > > adapted from gstreamer-java." and looking at gstreamer-java
> > > > yields: "An
> > > > unofficial/alternative set of java bindings for the gstreamer
> > > > multimedia
> > > > framework"
> > > > 
> > > > Again, doesn't look like something you want to base your API
> > > > on.  Sounds
> > > > to me like the 'free' java bindings come at a very high cost
> > > > (bringing
> > > > JGIR up to date and maintaining it).
> > > > 
> > > > What are the alternatives?
> > > 
> > > There are two other alternatives (and one bad idea) that come to
> > > mind:
> > > 
> > > 1.) Generate our own Java bindings to libvdsm.so during the vdsm
> > > build
> > > process.
> > > 
> > > I prefer this option from an API cleanliness POV because the
> > > transport code
> > > would only be written once (in libvdsm.so).  This form of
> > > generation should
> > > be simple because we are just wrapping the library so it can be
> > > called via
> > > JNI.
> > > 
> > > 
> > > 2.) Generate a native Java "library" that is equivalent to
> > > libvdsm.so.
> > > 
> > > This gets us into the business of libvirt-style bindings
> > > generation which I
> > > think is a mistake.  It opens the door to us maintaining parallel
> > > implementations of "libvdsm"s (one per language).
> > > 
> > > 
> > > -1.) Standardize the transport around JSON-RPC and make that the
> > > supported
> > > interface.
> > > 
> > > I am only mentioning it because I am certain someone will bring
> > > it up.  I
> > > think it's a bad idea and it's off-topic for this particular
> > > thread anyway.
> > > 
> > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > 
> > > 
> > 
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> 


From agl at us.ibm.com  Tue Aug 14 18:11:06 2012
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 14 Aug 2012 13:11:06 -0500
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <1439758794.9499554.1344966181299.JavaMail.root@redhat.com>
References: <20120814163647.GC6674@aglitke>
	<1439758794.9499554.1344966181299.JavaMail.root@redhat.com>
Message-ID: <20120814181106.GD6674@aglitke>

On Tue, Aug 14, 2012 at 01:43:01PM -0400, Saggi Mizrahi wrote:
> 
> ----- Original Message -----
> > From: "Adam Litke" <agl at us.ibm.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> > Sent: Tuesday, August 14, 2012 12:36:47 PM
> > Subject: Re: Consumability of vdsm via libvdsm.so
> > 
> > On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi wrote:
> > > I have an Idea, having json rpc for the over HTTP and 2 way json
> > > RPC over
> > > openstacks' messaging abstraction layer.
> > 
> > So you are proposing to disregard all of the arguments in favor of a
> > libvdsm and
> > instead standardize on a protocol.  In that case, we could just keep
> > xmlrpc...
> The difference between xml-rpc and json-rpc is that json-rpc is transport agnostic, less verbose, easier to parse.
> > We will be back at square one having every application writing on
> > object model
> > on top of the transport.  We will also need to reinvent a model for
> > ensuring
> > backwards compatibility of the protocol data."
> As I said, I still think we need to have a schema and supply bindings, GObject for python\C\C++\Vala, and native Java (because, as Yair pointed out, JNI in Java EE is non standard).
> > 
> > > This means we have 1 actual code base, the interfaces are on the
> > > transport
> > > layer.  And if you choose to use messaging you (in the future) get
> > > 2 way
> > > communication which means we can use.  Json-RPC notification for
> > > events. And
> > > that we (in the future) might fit to an openstack cluster.
> > 
> > > I still think generating the java bindings is preferable as it will
> > > have to be
> > > done and having it generated straight from the schema is ideal.
> > 
> > In that case we will also need to generate python bindings at a
> > minimum.  In
> > this model, how would REST and AMQP bridges be integrated?
> No REST, as I said. We forgo the "everything ever can be supported" for json-rpc over different transports. HTTP\AMQP\ZMQ\Simple TCP Socket.
> Unlike supporting different API schemes supporting transports is fairly simple because the number of methods to implement is small and remains constant and is independent of the actual API.
> 
> The big reason to use bindings is to keep us transport agnositc. Something that REST or SOAP or XML-RPC don't give us because they are bound to HTTP.
> 
> We could also "extend" on JSON-RPC by being able to switch serializers giving us the ability to support BSON and protobuff as long as the clients adhere to the strong types in the schema.
> Unlike XML-RPC that uses advanced XML features, JSON-RPC can really be any serialized object. So technically, if de\serialization becomes an issue we could put high performance serializers as configurable options for very large scale deployments.
> 
> JSON-RPC also supports extension methods that can be used to extend the protocol.
> 
> As I see it this solves all the issues that were preventing us from committing to a protocoll.
> * We don't want to be bound to a single transport. (Transport agnostic)
> * We don't want to be bound to a single serializer (Solved with optional extension that could be added when we need it)
> * 2 way communication (if you use anything other then HTTP you have that)
> * low latency (If you use anything other then HTTP you have that too)
> * Removal of calls that are actually a group of calls (eg. connectStorageServers vs connectStorageServer) - Even with HTTP, JSON-RPC supports request lists which give the expected semantic.
> * Simple set-up. Using ZMQ, HTTP or TCP Socket you can setup VDSM without a broker.
> * Don't have a lot of big classes for bindings. Because we bind int the transport level the amount of methods per transport is minimal and constant.
> * We provide the bindings. Bindings we'll be available and generated from the schema. So there is no problem with the (everyone needs to write their own bindings).
> * Allow bridges. Someone can still write a lightweight REST bridge over the bindings\socket.
> 
> Is there something that this doesn't solve?

Thanks for the additional detail.  How is this proposal different from what I
have submitted to gerrit other than we now need to write an additional Java
bindings generator?

> > 
> > > 
> > > ----- Original Message -----
> > > > From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron"
> > > > <abaron at redhat.com> Cc:
> > > > "Saggi Mizrahi" <smizrahi at redhat.com>, arch at ovirt.org Sent:
> > > > Tuesday, August
> > > > 14, 2012 10:09:28 AM Subject: Re: Consumability of vdsm via
> > > > libvdsm.so
> > > > 
> > > > On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam Litke"
> > > > > > > <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday, August
> > > > > > > 13, 2012
> > > > > > > 11:49:21 AM Subject: Re: Consumability of vdsm via
> > > > > > > libvdsm.so
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > We just finished a lively discussion regarding the ongoing
> > > > > > > effort to
> > > > > > > stabilize the vdsm API using a C library called libvdsm.
> > > > > > >  There are
> > > > > > > many things that need discussion, but I would like to focus
> > > > > > > this
> > > > > > > thread on one in particular:
> > > > > > > 
> > > > > > > Can ovirt-engine consume libvdsm via JNI?
> > > > > > > 
> > > > > > > libvdsm provides a full-featured C interface to the vdsm
> > > > > > > API using
> > > > > > > GObject.  Java bindings are provided automatically by
> > > > > > > jGIR[1].  The
> > > > > > > library communicates with vdsmd using an internal transport
> > > > > > > which is
> > > > > > > not exposed to end users (including ovirt-engine).  I would
> > > > > > > like to
> > > > > > > learn from folks with deep Java knowledge if this approach
> > > > > > > is
> > > > > > > workable.  What are the technical challenges to integrating
> > > > > > > in this
> > > > > > > way?  Please save discussion of AMQP and other bindings for
> > > > > > > other
> > > > > > > threads.
> > > > > > > 
> > > > > > > Thanks!
> > > > > > > 
> > > > > > > [1] https://live.gnome.org/JGIR How mature/maintained is
> > > > > > > JGIR?  Last
> > > > > > > commit seems to be 2010-02-09.  The author is: Alexander
> > > > > > > Kurtakov
> > > > > > > <akurtako at redhat.com> His status in our organizational
> > > > > > > chart: Employee
> > > > > > > Type: Ex-employee
> > > > > > It will need some work to get it up to par with the rest of
> > > > > > the gobject
> > > > > > generators
> > > > > 
> > > > > It's been dead since 2009, that doesn't seem very promising
> > > > > (http://www.ohloh.net/p/java-gobject-introspection)
> > > > > 
> > > > > It also states: "It also includes a custom GLib/GObject
> > > > > interface layer
> > > > > adapted from gstreamer-java." and looking at gstreamer-java
> > > > > yields: "An
> > > > > unofficial/alternative set of java bindings for the gstreamer
> > > > > multimedia
> > > > > framework"
> > > > > 
> > > > > Again, doesn't look like something you want to base your API
> > > > > on.  Sounds
> > > > > to me like the 'free' java bindings come at a very high cost
> > > > > (bringing
> > > > > JGIR up to date and maintaining it).
> > > > > 
> > > > > What are the alternatives?
> > > > 
> > > > There are two other alternatives (and one bad idea) that come to
> > > > mind:
> > > > 
> > > > 1.) Generate our own Java bindings to libvdsm.so during the vdsm
> > > > build
> > > > process.
> > > > 
> > > > I prefer this option from an API cleanliness POV because the
> > > > transport code
> > > > would only be written once (in libvdsm.so).  This form of
> > > > generation should
> > > > be simple because we are just wrapping the library so it can be
> > > > called via
> > > > JNI.
> > > > 
> > > > 
> > > > 2.) Generate a native Java "library" that is equivalent to
> > > > libvdsm.so.
> > > > 
> > > > This gets us into the business of libvirt-style bindings
> > > > generation which I
> > > > think is a mistake.  It opens the door to us maintaining parallel
> > > > implementations of "libvdsm"s (one per language).
> > > > 
> > > > 
> > > > -1.) Standardize the transport around JSON-RPC and make that the
> > > > supported
> > > > interface.
> > > > 
> > > > I am only mentioning it because I am certain someone will bring
> > > > it up.  I
> > > > think it's a bad idea and it's off-topic for this particular
> > > > thread anyway.
> > > > 
> > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > > 
> > > > 
> > > 
> > 
> > --
> > Adam Litke <agl at us.ibm.com>
> > IBM Linux Technology Center
> > 
> > 
> 

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From smizrahi at redhat.com  Tue Aug 14 18:39:11 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 14 Aug 2012 14:39:11 -0400 (EDT)
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <20120814181106.GD6674@aglitke>
Message-ID: <841104180.9516604.1344969551940.JavaMail.root@redhat.com>

Well, not by much other then that:
* The bindings could sit out of tree with less strict support guidelines (TBD).
* We support HTTP but the bindings don't use it (unless someone really thinks there is a reason to).
* You could. if you so desire. Write against the protocol directly (optimizations?).

We were really close with what we had, the only problems that people seemed to have is not committing to a protocol, and forcing everyone to work with the bindings.
This means we commit to the protocol and make the bindings optional (I don't see why someone would want to not use them, but I know that Not-Invented-Here Syndrome is quite common).

I feel like it would make everyone happy and it's an evolution of what we already started work on.

----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> Sent: Tuesday, August 14, 2012 2:11:06 PM
> Subject: Re: Consumability of vdsm via libvdsm.so
> 
> On Tue, Aug 14, 2012 at 01:43:01PM -0400, Saggi Mizrahi wrote:
> > 
> > ----- Original Message -----
> > > From: "Adam Litke" <agl at us.ibm.com>
> > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> > > Sent: Tuesday, August 14, 2012 12:36:47 PM
> > > Subject: Re: Consumability of vdsm via libvdsm.so
> > > 
> > > On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi wrote:
> > > > I have an Idea, having json rpc for the over HTTP and 2 way
> > > > json
> > > > RPC over
> > > > openstacks' messaging abstraction layer.
> > > 
> > > So you are proposing to disregard all of the arguments in favor
> > > of a
> > > libvdsm and
> > > instead standardize on a protocol.  In that case, we could just
> > > keep
> > > xmlrpc...
> > The difference between xml-rpc and json-rpc is that json-rpc is
> > transport agnostic, less verbose, easier to parse.
> > > We will be back at square one having every application writing on
> > > object model
> > > on top of the transport.  We will also need to reinvent a model
> > > for
> > > ensuring
> > > backwards compatibility of the protocol data."
> > As I said, I still think we need to have a schema and supply
> > bindings, GObject for python\C\C++\Vala, and native Java (because,
> > as Yair pointed out, JNI in Java EE is non standard).
> > > 
> > > > This means we have 1 actual code base, the interfaces are on
> > > > the
> > > > transport
> > > > layer.  And if you choose to use messaging you (in the future)
> > > > get
> > > > 2 way
> > > > communication which means we can use.  Json-RPC notification
> > > > for
> > > > events. And
> > > > that we (in the future) might fit to an openstack cluster.
> > > 
> > > > I still think generating the java bindings is preferable as it
> > > > will
> > > > have to be
> > > > done and having it generated straight from the schema is ideal.
> > > 
> > > In that case we will also need to generate python bindings at a
> > > minimum.  In
> > > this model, how would REST and AMQP bridges be integrated?
> > No REST, as I said. We forgo the "everything ever can be supported"
> > for json-rpc over different transports. HTTP\AMQP\ZMQ\Simple TCP
> > Socket.
> > Unlike supporting different API schemes supporting transports is
> > fairly simple because the number of methods to implement is small
> > and remains constant and is independent of the actual API.
> > 
> > The big reason to use bindings is to keep us transport agnositc.
> > Something that REST or SOAP or XML-RPC don't give us because they
> > are bound to HTTP.
> > 
> > We could also "extend" on JSON-RPC by being able to switch
> > serializers giving us the ability to support BSON and protobuff as
> > long as the clients adhere to the strong types in the schema.
> > Unlike XML-RPC that uses advanced XML features, JSON-RPC can really
> > be any serialized object. So technically, if de\serialization
> > becomes an issue we could put high performance serializers as
> > configurable options for very large scale deployments.
> > 
> > JSON-RPC also supports extension methods that can be used to extend
> > the protocol.
> > 
> > As I see it this solves all the issues that were preventing us from
> > committing to a protocoll.
> > * We don't want to be bound to a single transport. (Transport
> > agnostic)
> > * We don't want to be bound to a single serializer (Solved with
> > optional extension that could be added when we need it)
> > * 2 way communication (if you use anything other then HTTP you have
> > that)
> > * low latency (If you use anything other then HTTP you have that
> > too)
> > * Removal of calls that are actually a group of calls (eg.
> > connectStorageServers vs connectStorageServer) - Even with HTTP,
> > JSON-RPC supports request lists which give the expected semantic.
> > * Simple set-up. Using ZMQ, HTTP or TCP Socket you can setup VDSM
> > without a broker.
> > * Don't have a lot of big classes for bindings. Because we bind int
> > the transport level the amount of methods per transport is minimal
> > and constant.
> > * We provide the bindings. Bindings we'll be available and
> > generated from the schema. So there is no problem with the
> > (everyone needs to write their own bindings).
> > * Allow bridges. Someone can still write a lightweight REST bridge
> > over the bindings\socket.
> > 
> > Is there something that this doesn't solve?
> 
> Thanks for the additional detail.  How is this proposal different
> from what I
> have submitted to gerrit other than we now need to write an
> additional Java
> bindings generator?
> 
> > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron"
> > > > > <abaron at redhat.com> Cc:
> > > > > "Saggi Mizrahi" <smizrahi at redhat.com>, arch at ovirt.org Sent:
> > > > > Tuesday, August
> > > > > 14, 2012 10:09:28 AM Subject: Re: Consumability of vdsm via
> > > > > libvdsm.so
> > > > > 
> > > > > On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam Litke"
> > > > > > > > <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday,
> > > > > > > > August
> > > > > > > > 13, 2012
> > > > > > > > 11:49:21 AM Subject: Re: Consumability of vdsm via
> > > > > > > > libvdsm.so
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > > We just finished a lively discussion regarding the
> > > > > > > > ongoing
> > > > > > > > effort to
> > > > > > > > stabilize the vdsm API using a C library called
> > > > > > > > libvdsm.
> > > > > > > >  There are
> > > > > > > > many things that need discussion, but I would like to
> > > > > > > > focus
> > > > > > > > this
> > > > > > > > thread on one in particular:
> > > > > > > > 
> > > > > > > > Can ovirt-engine consume libvdsm via JNI?
> > > > > > > > 
> > > > > > > > libvdsm provides a full-featured C interface to the
> > > > > > > > vdsm
> > > > > > > > API using
> > > > > > > > GObject.  Java bindings are provided automatically by
> > > > > > > > jGIR[1].  The
> > > > > > > > library communicates with vdsmd using an internal
> > > > > > > > transport
> > > > > > > > which is
> > > > > > > > not exposed to end users (including ovirt-engine).  I
> > > > > > > > would
> > > > > > > > like to
> > > > > > > > learn from folks with deep Java knowledge if this
> > > > > > > > approach
> > > > > > > > is
> > > > > > > > workable.  What are the technical challenges to
> > > > > > > > integrating
> > > > > > > > in this
> > > > > > > > way?  Please save discussion of AMQP and other bindings
> > > > > > > > for
> > > > > > > > other
> > > > > > > > threads.
> > > > > > > > 
> > > > > > > > Thanks!
> > > > > > > > 
> > > > > > > > [1] https://live.gnome.org/JGIR How mature/maintained
> > > > > > > > is
> > > > > > > > JGIR?  Last
> > > > > > > > commit seems to be 2010-02-09.  The author is:
> > > > > > > > Alexander
> > > > > > > > Kurtakov
> > > > > > > > <akurtako at redhat.com> His status in our organizational
> > > > > > > > chart: Employee
> > > > > > > > Type: Ex-employee
> > > > > > > It will need some work to get it up to par with the rest
> > > > > > > of
> > > > > > > the gobject
> > > > > > > generators
> > > > > > 
> > > > > > It's been dead since 2009, that doesn't seem very promising
> > > > > > (http://www.ohloh.net/p/java-gobject-introspection)
> > > > > > 
> > > > > > It also states: "It also includes a custom GLib/GObject
> > > > > > interface layer
> > > > > > adapted from gstreamer-java." and looking at gstreamer-java
> > > > > > yields: "An
> > > > > > unofficial/alternative set of java bindings for the
> > > > > > gstreamer
> > > > > > multimedia
> > > > > > framework"
> > > > > > 
> > > > > > Again, doesn't look like something you want to base your
> > > > > > API
> > > > > > on.  Sounds
> > > > > > to me like the 'free' java bindings come at a very high
> > > > > > cost
> > > > > > (bringing
> > > > > > JGIR up to date and maintaining it).
> > > > > > 
> > > > > > What are the alternatives?
> > > > > 
> > > > > There are two other alternatives (and one bad idea) that come
> > > > > to
> > > > > mind:
> > > > > 
> > > > > 1.) Generate our own Java bindings to libvdsm.so during the
> > > > > vdsm
> > > > > build
> > > > > process.
> > > > > 
> > > > > I prefer this option from an API cleanliness POV because the
> > > > > transport code
> > > > > would only be written once (in libvdsm.so).  This form of
> > > > > generation should
> > > > > be simple because we are just wrapping the library so it can
> > > > > be
> > > > > called via
> > > > > JNI.
> > > > > 
> > > > > 
> > > > > 2.) Generate a native Java "library" that is equivalent to
> > > > > libvdsm.so.
> > > > > 
> > > > > This gets us into the business of libvirt-style bindings
> > > > > generation which I
> > > > > think is a mistake.  It opens the door to us maintaining
> > > > > parallel
> > > > > implementations of "libvdsm"s (one per language).
> > > > > 
> > > > > 
> > > > > -1.) Standardize the transport around JSON-RPC and make that
> > > > > the
> > > > > supported
> > > > > interface.
> > > > > 
> > > > > I am only mentioning it because I am certain someone will
> > > > > bring
> > > > > it up.  I
> > > > > think it's a bad idea and it's off-topic for this particular
> > > > > thread anyway.
> > > > > 
> > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > > > 
> > > > > 
> > > > 
> > > 
> > > --
> > > Adam Litke <agl at us.ibm.com>
> > > IBM Linux Technology Center
> > > 
> > > 
> > 
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> 


From agl at us.ibm.com  Tue Aug 14 18:57:52 2012
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 14 Aug 2012 13:57:52 -0500
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <841104180.9516604.1344969551940.JavaMail.root@redhat.com>
References: <20120814181106.GD6674@aglitke>
	<841104180.9516604.1344969551940.JavaMail.root@redhat.com>
Message-ID: <20120814185752.GG6674@aglitke>

On Tue, Aug 14, 2012 at 02:39:11PM -0400, Saggi Mizrahi wrote:
> Well, not by much other then that: * The bindings could sit out of tree with
> less strict support guidelines (TBD).  * We support HTTP but the bindings
> don't use it (unless someone really thinks there is a reason to).  * You
> could. if you so desire. Write against the protocol directly (optimizations?).
> 
> We were really close with what we had, the only problems that people seemed to
> have is not committing to a protocol, and forcing everyone to work with the
> bindings.  This means we commit to the protocol and make the bindings optional
> (I don't see why someone would want to not use them, but I know that
> Not-Invented-Here Syndrome is quite common).
> 
> I feel like it would make everyone happy and it's an evolution of what we
> already started work on.

Ok.  In that case I don't mind committing to a stable protocol as long as we
still do bindings for C and Python in the current style because I think we have
gotten that part right.  We'll generate native bindings for Java then.  Since
JSON is very easy to sloppily extend in incompatible ways (especially for Java/C
bindings), how do we plan to enforce strict data types at the protocol level?

Could someone explain to me how the P2P (ZeroMQ/AMQP) stuff fits into this
design as well?

> 
> ----- Original Message -----
> > From: "Adam Litke" <agl at us.ibm.com> To: "Saggi Mizrahi"
> > <smizrahi at redhat.com> Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> > Sent: Tuesday, August 14, 2012 2:11:06 PM Subject: Re: Consumability of vdsm
> > via libvdsm.so
> > 
> > On Tue, Aug 14, 2012 at 01:43:01PM -0400, Saggi Mizrahi wrote:
> > > 
> > > ----- Original Message -----
> > > > From: "Adam Litke" <agl at us.ibm.com> To: "Saggi Mizrahi"
> > > > <smizrahi at redhat.com> Cc: arch at ovirt.org, "Ayal Baron"
> > > > <abaron at redhat.com> Sent: Tuesday, August 14, 2012 12:36:47 PM Subject:
> > > > Re: Consumability of vdsm via libvdsm.so
> > > > 
> > > > On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi wrote:
> > > > > I have an Idea, having json rpc for the over HTTP and 2 way json RPC
> > > > > over openstacks' messaging abstraction layer.
> > > > 
> > > > So you are proposing to disregard all of the arguments in favor of a
> > > > libvdsm and instead standardize on a protocol.  In that case, we could
> > > > just keep xmlrpc...
> > > The difference between xml-rpc and json-rpc is that json-rpc is transport
> > > agnostic, less verbose, easier to parse.
> > > > We will be back at square one having every application writing on object
> > > > model on top of the transport.  We will also need to reinvent a model
> > > > for ensuring backwards compatibility of the protocol data."
> > > As I said, I still think we need to have a schema and supply bindings,
> > > GObject for python\C\C++\Vala, and native Java (because, as Yair pointed
> > > out, JNI in Java EE is non standard).
> > > > 
> > > > > This means we have 1 actual code base, the interfaces are on the
> > > > > transport layer.  And if you choose to use messaging you (in the
> > > > > future) get 2 way communication which means we can use.  Json-RPC
> > > > > notification for events. And that we (in the future) might fit to an
> > > > > openstack cluster.
> > > > 
> > > > > I still think generating the java bindings is preferable as it will
> > > > > have to be done and having it generated straight from the schema is
> > > > > ideal.
> > > > 
> > > > In that case we will also need to generate python bindings at a minimum.
> > > > In this model, how would REST and AMQP bridges be integrated?
> > > No REST, as I said. We forgo the "everything ever can be supported" for
> > > json-rpc over different transports. HTTP\AMQP\ZMQ\Simple TCP Socket.
> > > Unlike supporting different API schemes supporting transports is fairly
> > > simple because the number of methods to implement is small and remains
> > > constant and is independent of the actual API.
> > > 
> > > The big reason to use bindings is to keep us transport agnositc.
> > > Something that REST or SOAP or XML-RPC don't give us because they are
> > > bound to HTTP.
> > > 
> > > We could also "extend" on JSON-RPC by being able to switch serializers
> > > giving us the ability to support BSON and protobuff as long as the clients
> > > adhere to the strong types in the schema.  Unlike XML-RPC that uses
> > > advanced XML features, JSON-RPC can really be any serialized object. So
> > > technically, if de\serialization becomes an issue we could put high
> > > performance serializers as configurable options for very large scale
> > > deployments.
> > > 
> > > JSON-RPC also supports extension methods that can be used to extend the
> > > protocol.
> > > 
> > > As I see it this solves all the issues that were preventing us from
> > > committing to a protocoll.  * We don't want to be bound to a single
> > > transport. (Transport agnostic) * We don't want to be bound to a single
> > > serializer (Solved with optional extension that could be added when we
> > > need it) * 2 way communication (if you use anything other then HTTP you
> > > have that) * low latency (If you use anything other then HTTP you have
> > > that too) * Removal of calls that are actually a group of calls (eg.
> > > connectStorageServers vs connectStorageServer) - Even with HTTP, JSON-RPC
> > > supports request lists which give the expected semantic.  * Simple set-up.
> > > Using ZMQ, HTTP or TCP Socket you can setup VDSM without a broker.  *
> > > Don't have a lot of big classes for bindings. Because we bind int the
> > > transport level the amount of methods per transport is minimal and
> > > constant.  * We provide the bindings. Bindings we'll be available and
> > > generated from the schema. So there is no problem with the (everyone needs
> > > to write their own bindings).  * Allow bridges. Someone can still write a
> > > lightweight REST bridge over the bindings\socket.
> > > 
> > > Is there something that this doesn't solve?
> > 
> > Thanks for the additional detail.  How is this proposal different from what
> > I have submitted to gerrit other than we now need to write an additional
> > Java bindings generator?
> > 
> > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron"
> > > > > > <abaron at redhat.com> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>,
> > > > > > arch at ovirt.org Sent: Tuesday, August 14, 2012 10:09:28 AM Subject:
> > > > > > Re: Consumability of vdsm via libvdsm.so
> > > > > > 
> > > > > > On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam Litke"
> > > > > > > > > <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday, August 13,
> > > > > > > > > 2012 11:49:21 AM Subject: Re: Consumability of vdsm via
> > > > > > > > > libvdsm.so
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > We just finished a lively discussion regarding the ongoing
> > > > > > > > > effort to stabilize the vdsm API using a C library called
> > > > > > > > > libvdsm.  There are many things that need discussion, but I
> > > > > > > > > would like to focus this thread on one in particular:
> > > > > > > > > 
> > > > > > > > > Can ovirt-engine consume libvdsm via JNI?
> > > > > > > > > 
> > > > > > > > > libvdsm provides a full-featured C interface to the vdsm API
> > > > > > > > > using GObject.  Java bindings are provided automatically by
> > > > > > > > > jGIR[1].  The library communicates with vdsmd using an
> > > > > > > > > internal transport which is not exposed to end users
> > > > > > > > > (including ovirt-engine).  I would like to learn from folks
> > > > > > > > > with deep Java knowledge if this approach is workable.  What
> > > > > > > > > are the technical challenges to integrating in this way?
> > > > > > > > > Please save discussion of AMQP and other bindings for other
> > > > > > > > > threads.
> > > > > > > > > 
> > > > > > > > > Thanks!
> > > > > > > > > 
> > > > > > > > > [1] https://live.gnome.org/JGIR How mature/maintained is JGIR?
> > > > > > > > > Last commit seems to be 2010-02-09.  The author is: Alexander
> > > > > > > > > Kurtakov <akurtako at redhat.com> His status in our
> > > > > > > > > organizational chart: Employee Type: Ex-employee
> > > > > > > > It will need some work to get it up to par with the rest of the
> > > > > > > > gobject generators
> > > > > > > 
> > > > > > > It's been dead since 2009, that doesn't seem very promising
> > > > > > > (http://www.ohloh.net/p/java-gobject-introspection)
> > > > > > > 
> > > > > > > It also states: "It also includes a custom GLib/GObject interface
> > > > > > > layer adapted from gstreamer-java." and looking at gstreamer-java
> > > > > > > yields: "An unofficial/alternative set of java bindings for the
> > > > > > > gstreamer multimedia framework"
> > > > > > > 
> > > > > > > Again, doesn't look like something you want to base your API on.
> > > > > > > Sounds to me like the 'free' java bindings come at a very high
> > > > > > > cost (bringing JGIR up to date and maintaining it).
> > > > > > > 
> > > > > > > What are the alternatives?
> > > > > > 
> > > > > > There are two other alternatives (and one bad idea) that come to
> > > > > > mind:
> > > > > > 
> > > > > > 1.) Generate our own Java bindings to libvdsm.so during the vdsm
> > > > > > build process.
> > > > > > 
> > > > > > I prefer this option from an API cleanliness POV because the
> > > > > > transport code would only be written once (in libvdsm.so).  This
> > > > > > form of generation should be simple because we are just wrapping the
> > > > > > library so it can be called via JNI.
> > > > > > 
> > > > > > 
> > > > > > 2.) Generate a native Java "library" that is equivalent to
> > > > > > libvdsm.so.
> > > > > > 
> > > > > > This gets us into the business of libvirt-style bindings generation
> > > > > > which I think is a mistake.  It opens the door to us maintaining
> > > > > > parallel implementations of "libvdsm"s (one per language).
> > > > > > 
> > > > > > 
> > > > > > -1.) Standardize the transport around JSON-RPC and make that the
> > > > > > supported interface.
> > > > > > 
> > > > > > I am only mentioning it because I am certain someone will bring it
> > > > > > up.  I think it's a bad idea and it's off-topic for this particular
> > > > > > thread anyway.
> > > > > > 
> > > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > > 
> > > > 
> > > 
> > 
> > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > 
> > 
> 

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From smizrahi at redhat.com  Tue Aug 14 19:26:46 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 14 Aug 2012 15:26:46 -0400 (EDT)
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <20120814185752.GG6674@aglitke>
Message-ID: <1241549331.9528780.1344972406011.JavaMail.root@redhat.com>

Currently the "strong types" we have are
* strings
* uint64 \ int64
* doubles
* Booleans
* array
* map<string, variant>
* Null

On the other hand json has:
* strings
* numbers
* booleans
* array
* map<string, variant>
* null

We could have all numbers be floats and call it a day but I think that for typed languages the broad distinction we did should still be there.

Type safety will still be checked by the server side checkers as discussed.
Checks should be that things are in the correct type and that no mandatory fields are missing from expected objects.

for ZMQ and AMQP I suggest we use the openstack model of listening on 2 topics.
- vdsm
- vdsm.hostname

That way you could send a broadcast to all VDSMs or for a specific one. In the future we might messaging specific APIs to have VDSM listen to addtional host groups.
- vdsm.hostgroup

This means managers are able to group hosts dynamically.
These will not be available through the HTTP transport for obvious reasons.

----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> Sent: Tuesday, August 14, 2012 2:57:52 PM
> Subject: Re: Consumability of vdsm via libvdsm.so
> 
> On Tue, Aug 14, 2012 at 02:39:11PM -0400, Saggi Mizrahi wrote:
> > Well, not by much other then that: * The bindings could sit out of
> > tree with
> > less strict support guidelines (TBD).  * We support HTTP but the
> > bindings
> > don't use it (unless someone really thinks there is a reason to).
> >  * You
> > could. if you so desire. Write against the protocol directly
> > (optimizations?).
> > 
> > We were really close with what we had, the only problems that
> > people seemed to
> > have is not committing to a protocol, and forcing everyone to work
> > with the
> > bindings.  This means we commit to the protocol and make the
> > bindings optional
> > (I don't see why someone would want to not use them, but I know
> > that
> > Not-Invented-Here Syndrome is quite common).
> > 
> > I feel like it would make everyone happy and it's an evolution of
> > what we
> > already started work on.
> 
> Ok.  In that case I don't mind committing to a stable protocol as
> long as we
> still do bindings for C and Python in the current style because I
> think we have
> gotten that part right.  We'll generate native bindings for Java
> then.  Since
> JSON is very easy to sloppily extend in incompatible ways (especially
> for Java/C
> bindings), how do we plan to enforce strict data types at the
> protocol level?
> 
> Could someone explain to me how the P2P (ZeroMQ/AMQP) stuff fits into
> this
> design as well?
> 
> > 
> > ----- Original Message -----
> > > From: "Adam Litke" <agl at us.ibm.com> To: "Saggi Mizrahi"
> > > <smizrahi at redhat.com> Cc: arch at ovirt.org, "Ayal Baron"
> > > <abaron at redhat.com>
> > > Sent: Tuesday, August 14, 2012 2:11:06 PM Subject: Re:
> > > Consumability of vdsm
> > > via libvdsm.so
> > > 
> > > On Tue, Aug 14, 2012 at 01:43:01PM -0400, Saggi Mizrahi wrote:
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Saggi Mizrahi"
> > > > > <smizrahi at redhat.com> Cc: arch at ovirt.org, "Ayal Baron"
> > > > > <abaron at redhat.com> Sent: Tuesday, August 14, 2012 12:36:47
> > > > > PM Subject:
> > > > > Re: Consumability of vdsm via libvdsm.so
> > > > > 
> > > > > On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi
> > > > > wrote:
> > > > > > I have an Idea, having json rpc for the over HTTP and 2 way
> > > > > > json RPC
> > > > > > over openstacks' messaging abstraction layer.
> > > > > 
> > > > > So you are proposing to disregard all of the arguments in
> > > > > favor of a
> > > > > libvdsm and instead standardize on a protocol.  In that case,
> > > > > we could
> > > > > just keep xmlrpc...
> > > > The difference between xml-rpc and json-rpc is that json-rpc is
> > > > transport
> > > > agnostic, less verbose, easier to parse.
> > > > > We will be back at square one having every application
> > > > > writing on object
> > > > > model on top of the transport.  We will also need to reinvent
> > > > > a model
> > > > > for ensuring backwards compatibility of the protocol data."
> > > > As I said, I still think we need to have a schema and supply
> > > > bindings,
> > > > GObject for python\C\C++\Vala, and native Java (because, as
> > > > Yair pointed
> > > > out, JNI in Java EE is non standard).
> > > > > 
> > > > > > This means we have 1 actual code base, the interfaces are
> > > > > > on the
> > > > > > transport layer.  And if you choose to use messaging you
> > > > > > (in the
> > > > > > future) get 2 way communication which means we can use.
> > > > > >  Json-RPC
> > > > > > notification for events. And that we (in the future) might
> > > > > > fit to an
> > > > > > openstack cluster.
> > > > > 
> > > > > > I still think generating the java bindings is preferable as
> > > > > > it will
> > > > > > have to be done and having it generated straight from the
> > > > > > schema is
> > > > > > ideal.
> > > > > 
> > > > > In that case we will also need to generate python bindings at
> > > > > a minimum.
> > > > > In this model, how would REST and AMQP bridges be integrated?
> > > > No REST, as I said. We forgo the "everything ever can be
> > > > supported" for
> > > > json-rpc over different transports. HTTP\AMQP\ZMQ\Simple TCP
> > > > Socket.
> > > > Unlike supporting different API schemes supporting transports
> > > > is fairly
> > > > simple because the number of methods to implement is small and
> > > > remains
> > > > constant and is independent of the actual API.
> > > > 
> > > > The big reason to use bindings is to keep us transport
> > > > agnositc.
> > > > Something that REST or SOAP or XML-RPC don't give us because
> > > > they are
> > > > bound to HTTP.
> > > > 
> > > > We could also "extend" on JSON-RPC by being able to switch
> > > > serializers
> > > > giving us the ability to support BSON and protobuff as long as
> > > > the clients
> > > > adhere to the strong types in the schema.  Unlike XML-RPC that
> > > > uses
> > > > advanced XML features, JSON-RPC can really be any serialized
> > > > object. So
> > > > technically, if de\serialization becomes an issue we could put
> > > > high
> > > > performance serializers as configurable options for very large
> > > > scale
> > > > deployments.
> > > > 
> > > > JSON-RPC also supports extension methods that can be used to
> > > > extend the
> > > > protocol.
> > > > 
> > > > As I see it this solves all the issues that were preventing us
> > > > from
> > > > committing to a protocoll.  * We don't want to be bound to a
> > > > single
> > > > transport. (Transport agnostic) * We don't want to be bound to
> > > > a single
> > > > serializer (Solved with optional extension that could be added
> > > > when we
> > > > need it) * 2 way communication (if you use anything other then
> > > > HTTP you
> > > > have that) * low latency (If you use anything other then HTTP
> > > > you have
> > > > that too) * Removal of calls that are actually a group of calls
> > > > (eg.
> > > > connectStorageServers vs connectStorageServer) - Even with
> > > > HTTP, JSON-RPC
> > > > supports request lists which give the expected semantic.  *
> > > > Simple set-up.
> > > > Using ZMQ, HTTP or TCP Socket you can setup VDSM without a
> > > > broker.  *
> > > > Don't have a lot of big classes for bindings. Because we bind
> > > > int the
> > > > transport level the amount of methods per transport is minimal
> > > > and
> > > > constant.  * We provide the bindings. Bindings we'll be
> > > > available and
> > > > generated from the schema. So there is no problem with the
> > > > (everyone needs
> > > > to write their own bindings).  * Allow bridges. Someone can
> > > > still write a
> > > > lightweight REST bridge over the bindings\socket.
> > > > 
> > > > Is there something that this doesn't solve?
> > > 
> > > Thanks for the additional detail.  How is this proposal different
> > > from what
> > > I have submitted to gerrit other than we now need to write an
> > > additional
> > > Java bindings generator?
> > > 
> > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron"
> > > > > > > <abaron at redhat.com> Cc: "Saggi Mizrahi"
> > > > > > > <smizrahi at redhat.com>,
> > > > > > > arch at ovirt.org Sent: Tuesday, August 14, 2012 10:09:28 AM
> > > > > > > Subject:
> > > > > > > Re: Consumability of vdsm via libvdsm.so
> > > > > > > 
> > > > > > > On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam
> > > > > > > > > > Litke"
> > > > > > > > > > <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday,
> > > > > > > > > > August 13,
> > > > > > > > > > 2012 11:49:21 AM Subject: Re: Consumability of vdsm
> > > > > > > > > > via
> > > > > > > > > > libvdsm.so
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Hi all,
> > > > > > > > > > 
> > > > > > > > > > We just finished a lively discussion regarding the
> > > > > > > > > > ongoing
> > > > > > > > > > effort to stabilize the vdsm API using a C library
> > > > > > > > > > called
> > > > > > > > > > libvdsm.  There are many things that need
> > > > > > > > > > discussion, but I
> > > > > > > > > > would like to focus this thread on one in
> > > > > > > > > > particular:
> > > > > > > > > > 
> > > > > > > > > > Can ovirt-engine consume libvdsm via JNI?
> > > > > > > > > > 
> > > > > > > > > > libvdsm provides a full-featured C interface to the
> > > > > > > > > > vdsm API
> > > > > > > > > > using GObject.  Java bindings are provided
> > > > > > > > > > automatically by
> > > > > > > > > > jGIR[1].  The library communicates with vdsmd using
> > > > > > > > > > an
> > > > > > > > > > internal transport which is not exposed to end
> > > > > > > > > > users
> > > > > > > > > > (including ovirt-engine).  I would like to learn
> > > > > > > > > > from folks
> > > > > > > > > > with deep Java knowledge if this approach is
> > > > > > > > > > workable.  What
> > > > > > > > > > are the technical challenges to integrating in this
> > > > > > > > > > way?
> > > > > > > > > > Please save discussion of AMQP and other bindings
> > > > > > > > > > for other
> > > > > > > > > > threads.
> > > > > > > > > > 
> > > > > > > > > > Thanks!
> > > > > > > > > > 
> > > > > > > > > > [1] https://live.gnome.org/JGIR How
> > > > > > > > > > mature/maintained is JGIR?
> > > > > > > > > > Last commit seems to be 2010-02-09.  The author is:
> > > > > > > > > > Alexander
> > > > > > > > > > Kurtakov <akurtako at redhat.com> His status in our
> > > > > > > > > > organizational chart: Employee Type: Ex-employee
> > > > > > > > > It will need some work to get it up to par with the
> > > > > > > > > rest of the
> > > > > > > > > gobject generators
> > > > > > > > 
> > > > > > > > It's been dead since 2009, that doesn't seem very
> > > > > > > > promising
> > > > > > > > (http://www.ohloh.net/p/java-gobject-introspection)
> > > > > > > > 
> > > > > > > > It also states: "It also includes a custom GLib/GObject
> > > > > > > > interface
> > > > > > > > layer adapted from gstreamer-java." and looking at
> > > > > > > > gstreamer-java
> > > > > > > > yields: "An unofficial/alternative set of java bindings
> > > > > > > > for the
> > > > > > > > gstreamer multimedia framework"
> > > > > > > > 
> > > > > > > > Again, doesn't look like something you want to base
> > > > > > > > your API on.
> > > > > > > > Sounds to me like the 'free' java bindings come at a
> > > > > > > > very high
> > > > > > > > cost (bringing JGIR up to date and maintaining it).
> > > > > > > > 
> > > > > > > > What are the alternatives?
> > > > > > > 
> > > > > > > There are two other alternatives (and one bad idea) that
> > > > > > > come to
> > > > > > > mind:
> > > > > > > 
> > > > > > > 1.) Generate our own Java bindings to libvdsm.so during
> > > > > > > the vdsm
> > > > > > > build process.
> > > > > > > 
> > > > > > > I prefer this option from an API cleanliness POV because
> > > > > > > the
> > > > > > > transport code would only be written once (in
> > > > > > > libvdsm.so).  This
> > > > > > > form of generation should be simple because we are just
> > > > > > > wrapping the
> > > > > > > library so it can be called via JNI.
> > > > > > > 
> > > > > > > 
> > > > > > > 2.) Generate a native Java "library" that is equivalent
> > > > > > > to
> > > > > > > libvdsm.so.
> > > > > > > 
> > > > > > > This gets us into the business of libvirt-style bindings
> > > > > > > generation
> > > > > > > which I think is a mistake.  It opens the door to us
> > > > > > > maintaining
> > > > > > > parallel implementations of "libvdsm"s (one per
> > > > > > > language).
> > > > > > > 
> > > > > > > 
> > > > > > > -1.) Standardize the transport around JSON-RPC and make
> > > > > > > that the
> > > > > > > supported interface.
> > > > > > > 
> > > > > > > I am only mentioning it because I am certain someone will
> > > > > > > bring it
> > > > > > > up.  I think it's a bad idea and it's off-topic for this
> > > > > > > particular
> > > > > > > thread anyway.
> > > > > > > 
> > > > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology
> > > > > > > Center
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > > > 
> > > > > 
> > > > 
> > > 
> > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > 
> > > 
> > 
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> 


From agl at us.ibm.com  Tue Aug 14 19:46:00 2012
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 14 Aug 2012 14:46:00 -0500
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <1241549331.9528780.1344972406011.JavaMail.root@redhat.com>
References: <20120814185752.GG6674@aglitke>
	<1241549331.9528780.1344972406011.JavaMail.root@redhat.com>
Message-ID: <20120814194600.GH6674@aglitke>

On Tue, Aug 14, 2012 at 03:26:46PM -0400, Saggi Mizrahi wrote:
> Currently the "strong types" we have are
> * strings
> * uint64 \ int64
> * doubles
> * Booleans
> * array
> * map<string, variant>
> * Null
> 
> On the other hand json has:
> * strings
> * numbers
> * booleans
> * array
> * map<string, variant>
> * null
> 
> We could have all numbers be floats and call it a day but I think that for typed languages the broad distinction we did should still be there.
> 
> Type safety will still be checked by the server side checkers as discussed.
> Checks should be that things are in the correct type and that no mandatory fields are missing from expected objects.

Additionally, fields can only be appended to objects (not removed or changed).
Do we plan to add something to help internal vdsm code construct well-formed
objects which comply to the rules set forth in the API.  Today, objects are
constructed dynamically and in a very ad-hoc manner which makes it difficult to
verify correctness for all possible runtime scenarios.  It seems we would need
to formally construct objects and then "fill in" the values as is appropriate.

> 
> for ZMQ and AMQP I suggest we use the openstack model of listening on 2 topics.
> - vdsm
> - vdsm.hostname

So this is a separate server (analogous to the newly proposed JsonRPC binding)?

> 
> That way you could send a broadcast to all VDSMs or for a specific one. In the future we might messaging specific APIs to have VDSM listen to addtional host groups.
> - vdsm.hostgroup
> 
> This means managers are able to group hosts dynamically.
> These will not be available through the HTTP transport for obvious reasons.
> 
> ----- Original Message -----
> > From: "Adam Litke" <agl at us.ibm.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> > Sent: Tuesday, August 14, 2012 2:57:52 PM
> > Subject: Re: Consumability of vdsm via libvdsm.so
> > 
> > On Tue, Aug 14, 2012 at 02:39:11PM -0400, Saggi Mizrahi wrote:
> > > Well, not by much other then that: * The bindings could sit out of
> > > tree with
> > > less strict support guidelines (TBD).  * We support HTTP but the
> > > bindings
> > > don't use it (unless someone really thinks there is a reason to).
> > >  * You
> > > could. if you so desire. Write against the protocol directly
> > > (optimizations?).
> > > 
> > > We were really close with what we had, the only problems that
> > > people seemed to
> > > have is not committing to a protocol, and forcing everyone to work
> > > with the
> > > bindings.  This means we commit to the protocol and make the
> > > bindings optional
> > > (I don't see why someone would want to not use them, but I know
> > > that
> > > Not-Invented-Here Syndrome is quite common).
> > > 
> > > I feel like it would make everyone happy and it's an evolution of
> > > what we
> > > already started work on.
> > 
> > Ok.  In that case I don't mind committing to a stable protocol as
> > long as we
> > still do bindings for C and Python in the current style because I
> > think we have
> > gotten that part right.  We'll generate native bindings for Java
> > then.  Since
> > JSON is very easy to sloppily extend in incompatible ways (especially
> > for Java/C
> > bindings), how do we plan to enforce strict data types at the
> > protocol level?
> > 
> > Could someone explain to me how the P2P (ZeroMQ/AMQP) stuff fits into
> > this
> > design as well?
> > 
> > > 
> > > ----- Original Message -----
> > > > From: "Adam Litke" <agl at us.ibm.com> To: "Saggi Mizrahi"
> > > > <smizrahi at redhat.com> Cc: arch at ovirt.org, "Ayal Baron"
> > > > <abaron at redhat.com>
> > > > Sent: Tuesday, August 14, 2012 2:11:06 PM Subject: Re:
> > > > Consumability of vdsm
> > > > via libvdsm.so
> > > > 
> > > > On Tue, Aug 14, 2012 at 01:43:01PM -0400, Saggi Mizrahi wrote:
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Saggi Mizrahi"
> > > > > > <smizrahi at redhat.com> Cc: arch at ovirt.org, "Ayal Baron"
> > > > > > <abaron at redhat.com> Sent: Tuesday, August 14, 2012 12:36:47
> > > > > > PM Subject:
> > > > > > Re: Consumability of vdsm via libvdsm.so
> > > > > > 
> > > > > > On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi
> > > > > > wrote:
> > > > > > > I have an Idea, having json rpc for the over HTTP and 2 way
> > > > > > > json RPC
> > > > > > > over openstacks' messaging abstraction layer.
> > > > > > 
> > > > > > So you are proposing to disregard all of the arguments in
> > > > > > favor of a
> > > > > > libvdsm and instead standardize on a protocol.  In that case,
> > > > > > we could
> > > > > > just keep xmlrpc...
> > > > > The difference between xml-rpc and json-rpc is that json-rpc is
> > > > > transport
> > > > > agnostic, less verbose, easier to parse.
> > > > > > We will be back at square one having every application
> > > > > > writing on object
> > > > > > model on top of the transport.  We will also need to reinvent
> > > > > > a model
> > > > > > for ensuring backwards compatibility of the protocol data."
> > > > > As I said, I still think we need to have a schema and supply
> > > > > bindings,
> > > > > GObject for python\C\C++\Vala, and native Java (because, as
> > > > > Yair pointed
> > > > > out, JNI in Java EE is non standard).
> > > > > > 
> > > > > > > This means we have 1 actual code base, the interfaces are
> > > > > > > on the
> > > > > > > transport layer.  And if you choose to use messaging you
> > > > > > > (in the
> > > > > > > future) get 2 way communication which means we can use.
> > > > > > >  Json-RPC
> > > > > > > notification for events. And that we (in the future) might
> > > > > > > fit to an
> > > > > > > openstack cluster.
> > > > > > 
> > > > > > > I still think generating the java bindings is preferable as
> > > > > > > it will
> > > > > > > have to be done and having it generated straight from the
> > > > > > > schema is
> > > > > > > ideal.
> > > > > > 
> > > > > > In that case we will also need to generate python bindings at
> > > > > > a minimum.
> > > > > > In this model, how would REST and AMQP bridges be integrated?
> > > > > No REST, as I said. We forgo the "everything ever can be
> > > > > supported" for
> > > > > json-rpc over different transports. HTTP\AMQP\ZMQ\Simple TCP
> > > > > Socket.
> > > > > Unlike supporting different API schemes supporting transports
> > > > > is fairly
> > > > > simple because the number of methods to implement is small and
> > > > > remains
> > > > > constant and is independent of the actual API.
> > > > > 
> > > > > The big reason to use bindings is to keep us transport
> > > > > agnositc.
> > > > > Something that REST or SOAP or XML-RPC don't give us because
> > > > > they are
> > > > > bound to HTTP.
> > > > > 
> > > > > We could also "extend" on JSON-RPC by being able to switch
> > > > > serializers
> > > > > giving us the ability to support BSON and protobuff as long as
> > > > > the clients
> > > > > adhere to the strong types in the schema.  Unlike XML-RPC that
> > > > > uses
> > > > > advanced XML features, JSON-RPC can really be any serialized
> > > > > object. So
> > > > > technically, if de\serialization becomes an issue we could put
> > > > > high
> > > > > performance serializers as configurable options for very large
> > > > > scale
> > > > > deployments.
> > > > > 
> > > > > JSON-RPC also supports extension methods that can be used to
> > > > > extend the
> > > > > protocol.
> > > > > 
> > > > > As I see it this solves all the issues that were preventing us
> > > > > from
> > > > > committing to a protocoll.  * We don't want to be bound to a
> > > > > single
> > > > > transport. (Transport agnostic) * We don't want to be bound to
> > > > > a single
> > > > > serializer (Solved with optional extension that could be added
> > > > > when we
> > > > > need it) * 2 way communication (if you use anything other then
> > > > > HTTP you
> > > > > have that) * low latency (If you use anything other then HTTP
> > > > > you have
> > > > > that too) * Removal of calls that are actually a group of calls
> > > > > (eg.
> > > > > connectStorageServers vs connectStorageServer) - Even with
> > > > > HTTP, JSON-RPC
> > > > > supports request lists which give the expected semantic.  *
> > > > > Simple set-up.
> > > > > Using ZMQ, HTTP or TCP Socket you can setup VDSM without a
> > > > > broker.  *
> > > > > Don't have a lot of big classes for bindings. Because we bind
> > > > > int the
> > > > > transport level the amount of methods per transport is minimal
> > > > > and
> > > > > constant.  * We provide the bindings. Bindings we'll be
> > > > > available and
> > > > > generated from the schema. So there is no problem with the
> > > > > (everyone needs
> > > > > to write their own bindings).  * Allow bridges. Someone can
> > > > > still write a
> > > > > lightweight REST bridge over the bindings\socket.
> > > > > 
> > > > > Is there something that this doesn't solve?
> > > > 
> > > > Thanks for the additional detail.  How is this proposal different
> > > > from what
> > > > I have submitted to gerrit other than we now need to write an
> > > > additional
> > > > Java bindings generator?
> > > > 
> > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron"
> > > > > > > > <abaron at redhat.com> Cc: "Saggi Mizrahi"
> > > > > > > > <smizrahi at redhat.com>,
> > > > > > > > arch at ovirt.org Sent: Tuesday, August 14, 2012 10:09:28 AM
> > > > > > > > Subject:
> > > > > > > > Re: Consumability of vdsm via libvdsm.so
> > > > > > > > 
> > > > > > > > On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam
> > > > > > > > > > > Litke"
> > > > > > > > > > > <agl at us.ibm.com> Cc: arch at ovirt.org Sent: Monday,
> > > > > > > > > > > August 13,
> > > > > > > > > > > 2012 11:49:21 AM Subject: Re: Consumability of vdsm
> > > > > > > > > > > via
> > > > > > > > > > > libvdsm.so
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Hi all,
> > > > > > > > > > > 
> > > > > > > > > > > We just finished a lively discussion regarding the
> > > > > > > > > > > ongoing
> > > > > > > > > > > effort to stabilize the vdsm API using a C library
> > > > > > > > > > > called
> > > > > > > > > > > libvdsm.  There are many things that need
> > > > > > > > > > > discussion, but I
> > > > > > > > > > > would like to focus this thread on one in
> > > > > > > > > > > particular:
> > > > > > > > > > > 
> > > > > > > > > > > Can ovirt-engine consume libvdsm via JNI?
> > > > > > > > > > > 
> > > > > > > > > > > libvdsm provides a full-featured C interface to the
> > > > > > > > > > > vdsm API
> > > > > > > > > > > using GObject.  Java bindings are provided
> > > > > > > > > > > automatically by
> > > > > > > > > > > jGIR[1].  The library communicates with vdsmd using
> > > > > > > > > > > an
> > > > > > > > > > > internal transport which is not exposed to end
> > > > > > > > > > > users
> > > > > > > > > > > (including ovirt-engine).  I would like to learn
> > > > > > > > > > > from folks
> > > > > > > > > > > with deep Java knowledge if this approach is
> > > > > > > > > > > workable.  What
> > > > > > > > > > > are the technical challenges to integrating in this
> > > > > > > > > > > way?
> > > > > > > > > > > Please save discussion of AMQP and other bindings
> > > > > > > > > > > for other
> > > > > > > > > > > threads.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks!
> > > > > > > > > > > 
> > > > > > > > > > > [1] https://live.gnome.org/JGIR How
> > > > > > > > > > > mature/maintained is JGIR?
> > > > > > > > > > > Last commit seems to be 2010-02-09.  The author is:
> > > > > > > > > > > Alexander
> > > > > > > > > > > Kurtakov <akurtako at redhat.com> His status in our
> > > > > > > > > > > organizational chart: Employee Type: Ex-employee
> > > > > > > > > > It will need some work to get it up to par with the
> > > > > > > > > > rest of the
> > > > > > > > > > gobject generators
> > > > > > > > > 
> > > > > > > > > It's been dead since 2009, that doesn't seem very
> > > > > > > > > promising
> > > > > > > > > (http://www.ohloh.net/p/java-gobject-introspection)
> > > > > > > > > 
> > > > > > > > > It also states: "It also includes a custom GLib/GObject
> > > > > > > > > interface
> > > > > > > > > layer adapted from gstreamer-java." and looking at
> > > > > > > > > gstreamer-java
> > > > > > > > > yields: "An unofficial/alternative set of java bindings
> > > > > > > > > for the
> > > > > > > > > gstreamer multimedia framework"
> > > > > > > > > 
> > > > > > > > > Again, doesn't look like something you want to base
> > > > > > > > > your API on.
> > > > > > > > > Sounds to me like the 'free' java bindings come at a
> > > > > > > > > very high
> > > > > > > > > cost (bringing JGIR up to date and maintaining it).
> > > > > > > > > 
> > > > > > > > > What are the alternatives?
> > > > > > > > 
> > > > > > > > There are two other alternatives (and one bad idea) that
> > > > > > > > come to
> > > > > > > > mind:
> > > > > > > > 
> > > > > > > > 1.) Generate our own Java bindings to libvdsm.so during
> > > > > > > > the vdsm
> > > > > > > > build process.
> > > > > > > > 
> > > > > > > > I prefer this option from an API cleanliness POV because
> > > > > > > > the
> > > > > > > > transport code would only be written once (in
> > > > > > > > libvdsm.so).  This
> > > > > > > > form of generation should be simple because we are just
> > > > > > > > wrapping the
> > > > > > > > library so it can be called via JNI.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 2.) Generate a native Java "library" that is equivalent
> > > > > > > > to
> > > > > > > > libvdsm.so.
> > > > > > > > 
> > > > > > > > This gets us into the business of libvirt-style bindings
> > > > > > > > generation
> > > > > > > > which I think is a mistake.  It opens the door to us
> > > > > > > > maintaining
> > > > > > > > parallel implementations of "libvdsm"s (one per
> > > > > > > > language).
> > > > > > > > 
> > > > > > > > 
> > > > > > > > -1.) Standardize the transport around JSON-RPC and make
> > > > > > > > that the
> > > > > > > > supported interface.
> > > > > > > > 
> > > > > > > > I am only mentioning it because I am certain someone will
> > > > > > > > bring it
> > > > > > > > up.  I think it's a bad idea and it's off-topic for this
> > > > > > > > particular
> > > > > > > > thread anyway.
> > > > > > > > 
> > > > > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology
> > > > > > > > Center
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > > 
> > > > 
> > > 
> > 
> > --
> > Adam Litke <agl at us.ibm.com>
> > IBM Linux Technology Center
> > 
> > 
> 

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From smizrahi at redhat.com  Tue Aug 14 20:59:11 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 14 Aug 2012 16:59:11 -0400 (EDT)
Subject: Consumability of vdsm via libvdsm.so
In-Reply-To: <20120814194600.GH6674@aglitke>
Message-ID: <198325317.9563797.1344977951139.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> Sent: Tuesday, August 14, 2012 3:46:00 PM
> Subject: Re: Consumability of vdsm via libvdsm.so
> 
> On Tue, Aug 14, 2012 at 03:26:46PM -0400, Saggi Mizrahi wrote:
> > Currently the "strong types" we have are
> > * strings
> > * uint64 \ int64
> > * doubles
> > * Booleans
> > * array
> > * map<string, variant>
> > * Null
> > 
> > On the other hand json has:
> > * strings
> > * numbers
> > * booleans
> > * array
> > * map<string, variant>
> > * null
> > 
> > We could have all numbers be floats and call it a day but I think
> > that for typed languages the broad distinction we did should still
> > be there.
> > 
> > Type safety will still be checked by the server side checkers as
> > discussed.
> > Checks should be that things are in the correct type and that no
> > mandatory fields are missing from expected objects.
> 
> Additionally, fields can only be appended to objects (not removed or
> changed).
> Do we plan to add something to help internal vdsm code construct
> well-formed
> objects which comply to the rules set forth in the API.  Today,
> objects are
> constructed dynamically and in a very ad-hoc manner which makes it
> difficult to
> verify correctness for all possible runtime scenarios.  It seems we
> would need
> to formally construct objects and then "fill in" the values as is
> appropriate.
We could check ourselves on the way out as well using some schema generator magic. But I put this as lower priority.
> 
> > 
> > for ZMQ and AMQP I suggest we use the openstack model of listening
> > on 2 topics.
> > - vdsm
> > - vdsm.hostname
> 
> So this is a separate server (analogous to the newly proposed JsonRPC
> binding)?
JsonRPC could still be transmitted over AMQP and ZMQ.
It's the same objects just different transport.
The added benefit is that if such transport is configured VDSM could theoretically send json-rpc notifications (ie. events) to a specified tag.

> 
> > 
> > That way you could send a broadcast to all VDSMs or for a specific
> > one. In the future we might messaging specific APIs to have VDSM
> > listen to addtional host groups.
> > - vdsm.hostgroup
> > 
> > This means managers are able to group hosts dynamically.
> > These will not be available through the HTTP transport for obvious
> > reasons.
> > 
> > ----- Original Message -----
> > > From: "Adam Litke" <agl at us.ibm.com>
> > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > Cc: arch at ovirt.org, "Ayal Baron" <abaron at redhat.com>
> > > Sent: Tuesday, August 14, 2012 2:57:52 PM
> > > Subject: Re: Consumability of vdsm via libvdsm.so
> > > 
> > > On Tue, Aug 14, 2012 at 02:39:11PM -0400, Saggi Mizrahi wrote:
> > > > Well, not by much other then that: * The bindings could sit out
> > > > of
> > > > tree with
> > > > less strict support guidelines (TBD).  * We support HTTP but
> > > > the
> > > > bindings
> > > > don't use it (unless someone really thinks there is a reason
> > > > to).
> > > >  * You
> > > > could. if you so desire. Write against the protocol directly
> > > > (optimizations?).
> > > > 
> > > > We were really close with what we had, the only problems that
> > > > people seemed to
> > > > have is not committing to a protocol, and forcing everyone to
> > > > work
> > > > with the
> > > > bindings.  This means we commit to the protocol and make the
> > > > bindings optional
> > > > (I don't see why someone would want to not use them, but I know
> > > > that
> > > > Not-Invented-Here Syndrome is quite common).
> > > > 
> > > > I feel like it would make everyone happy and it's an evolution
> > > > of
> > > > what we
> > > > already started work on.
> > > 
> > > Ok.  In that case I don't mind committing to a stable protocol as
> > > long as we
> > > still do bindings for C and Python in the current style because I
> > > think we have
> > > gotten that part right.  We'll generate native bindings for Java
> > > then.  Since
> > > JSON is very easy to sloppily extend in incompatible ways
> > > (especially
> > > for Java/C
> > > bindings), how do we plan to enforce strict data types at the
> > > protocol level?
> > > 
> > > Could someone explain to me how the P2P (ZeroMQ/AMQP) stuff fits
> > > into
> > > this
> > > design as well?
> > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Saggi Mizrahi"
> > > > > <smizrahi at redhat.com> Cc: arch at ovirt.org, "Ayal Baron"
> > > > > <abaron at redhat.com>
> > > > > Sent: Tuesday, August 14, 2012 2:11:06 PM Subject: Re:
> > > > > Consumability of vdsm
> > > > > via libvdsm.so
> > > > > 
> > > > > On Tue, Aug 14, 2012 at 01:43:01PM -0400, Saggi Mizrahi
> > > > > wrote:
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Saggi Mizrahi"
> > > > > > > <smizrahi at redhat.com> Cc: arch at ovirt.org, "Ayal Baron"
> > > > > > > <abaron at redhat.com> Sent: Tuesday, August 14, 2012
> > > > > > > 12:36:47
> > > > > > > PM Subject:
> > > > > > > Re: Consumability of vdsm via libvdsm.so
> > > > > > > 
> > > > > > > On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi
> > > > > > > wrote:
> > > > > > > > I have an Idea, having json rpc for the over HTTP and 2
> > > > > > > > way
> > > > > > > > json RPC
> > > > > > > > over openstacks' messaging abstraction layer.
> > > > > > > 
> > > > > > > So you are proposing to disregard all of the arguments in
> > > > > > > favor of a
> > > > > > > libvdsm and instead standardize on a protocol.  In that
> > > > > > > case,
> > > > > > > we could
> > > > > > > just keep xmlrpc...
> > > > > > The difference between xml-rpc and json-rpc is that
> > > > > > json-rpc is
> > > > > > transport
> > > > > > agnostic, less verbose, easier to parse.
> > > > > > > We will be back at square one having every application
> > > > > > > writing on object
> > > > > > > model on top of the transport.  We will also need to
> > > > > > > reinvent
> > > > > > > a model
> > > > > > > for ensuring backwards compatibility of the protocol
> > > > > > > data."
> > > > > > As I said, I still think we need to have a schema and
> > > > > > supply
> > > > > > bindings,
> > > > > > GObject for python\C\C++\Vala, and native Java (because, as
> > > > > > Yair pointed
> > > > > > out, JNI in Java EE is non standard).
> > > > > > > 
> > > > > > > > This means we have 1 actual code base, the interfaces
> > > > > > > > are
> > > > > > > > on the
> > > > > > > > transport layer.  And if you choose to use messaging
> > > > > > > > you
> > > > > > > > (in the
> > > > > > > > future) get 2 way communication which means we can use.
> > > > > > > >  Json-RPC
> > > > > > > > notification for events. And that we (in the future)
> > > > > > > > might
> > > > > > > > fit to an
> > > > > > > > openstack cluster.
> > > > > > > 
> > > > > > > > I still think generating the java bindings is
> > > > > > > > preferable as
> > > > > > > > it will
> > > > > > > > have to be done and having it generated straight from
> > > > > > > > the
> > > > > > > > schema is
> > > > > > > > ideal.
> > > > > > > 
> > > > > > > In that case we will also need to generate python
> > > > > > > bindings at
> > > > > > > a minimum.
> > > > > > > In this model, how would REST and AMQP bridges be
> > > > > > > integrated?
> > > > > > No REST, as I said. We forgo the "everything ever can be
> > > > > > supported" for
> > > > > > json-rpc over different transports. HTTP\AMQP\ZMQ\Simple
> > > > > > TCP
> > > > > > Socket.
> > > > > > Unlike supporting different API schemes supporting
> > > > > > transports
> > > > > > is fairly
> > > > > > simple because the number of methods to implement is small
> > > > > > and
> > > > > > remains
> > > > > > constant and is independent of the actual API.
> > > > > > 
> > > > > > The big reason to use bindings is to keep us transport
> > > > > > agnositc.
> > > > > > Something that REST or SOAP or XML-RPC don't give us
> > > > > > because
> > > > > > they are
> > > > > > bound to HTTP.
> > > > > > 
> > > > > > We could also "extend" on JSON-RPC by being able to switch
> > > > > > serializers
> > > > > > giving us the ability to support BSON and protobuff as long
> > > > > > as
> > > > > > the clients
> > > > > > adhere to the strong types in the schema.  Unlike XML-RPC
> > > > > > that
> > > > > > uses
> > > > > > advanced XML features, JSON-RPC can really be any
> > > > > > serialized
> > > > > > object. So
> > > > > > technically, if de\serialization becomes an issue we could
> > > > > > put
> > > > > > high
> > > > > > performance serializers as configurable options for very
> > > > > > large
> > > > > > scale
> > > > > > deployments.
> > > > > > 
> > > > > > JSON-RPC also supports extension methods that can be used
> > > > > > to
> > > > > > extend the
> > > > > > protocol.
> > > > > > 
> > > > > > As I see it this solves all the issues that were preventing
> > > > > > us
> > > > > > from
> > > > > > committing to a protocoll.  * We don't want to be bound to
> > > > > > a
> > > > > > single
> > > > > > transport. (Transport agnostic) * We don't want to be bound
> > > > > > to
> > > > > > a single
> > > > > > serializer (Solved with optional extension that could be
> > > > > > added
> > > > > > when we
> > > > > > need it) * 2 way communication (if you use anything other
> > > > > > then
> > > > > > HTTP you
> > > > > > have that) * low latency (If you use anything other then
> > > > > > HTTP
> > > > > > you have
> > > > > > that too) * Removal of calls that are actually a group of
> > > > > > calls
> > > > > > (eg.
> > > > > > connectStorageServers vs connectStorageServer) - Even with
> > > > > > HTTP, JSON-RPC
> > > > > > supports request lists which give the expected semantic.  *
> > > > > > Simple set-up.
> > > > > > Using ZMQ, HTTP or TCP Socket you can setup VDSM without a
> > > > > > broker.  *
> > > > > > Don't have a lot of big classes for bindings. Because we
> > > > > > bind
> > > > > > int the
> > > > > > transport level the amount of methods per transport is
> > > > > > minimal
> > > > > > and
> > > > > > constant.  * We provide the bindings. Bindings we'll be
> > > > > > available and
> > > > > > generated from the schema. So there is no problem with the
> > > > > > (everyone needs
> > > > > > to write their own bindings).  * Allow bridges. Someone can
> > > > > > still write a
> > > > > > lightweight REST bridge over the bindings\socket.
> > > > > > 
> > > > > > Is there something that this doesn't solve?
> > > > > 
> > > > > Thanks for the additional detail.  How is this proposal
> > > > > different
> > > > > from what
> > > > > I have submitted to gerrit other than we now need to write an
> > > > > additional
> > > > > Java bindings generator?
> > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Adam Litke" <agl at us.ibm.com> To: "Ayal Baron"
> > > > > > > > > <abaron at redhat.com> Cc: "Saggi Mizrahi"
> > > > > > > > > <smizrahi at redhat.com>,
> > > > > > > > > arch at ovirt.org Sent: Tuesday, August 14, 2012
> > > > > > > > > 10:09:28 AM
> > > > > > > > > Subject:
> > > > > > > > > Re: Consumability of vdsm via libvdsm.so
> > > > > > > > > 
> > > > > > > > > On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Yaniv Kaul" <ykaul at redhat.com> To: "Adam
> > > > > > > > > > > > Litke"
> > > > > > > > > > > > <agl at us.ibm.com> Cc: arch at ovirt.org Sent:
> > > > > > > > > > > > Monday,
> > > > > > > > > > > > August 13,
> > > > > > > > > > > > 2012 11:49:21 AM Subject: Re: Consumability of
> > > > > > > > > > > > vdsm
> > > > > > > > > > > > via
> > > > > > > > > > > > libvdsm.so
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi all,
> > > > > > > > > > > > 
> > > > > > > > > > > > We just finished a lively discussion regarding
> > > > > > > > > > > > the
> > > > > > > > > > > > ongoing
> > > > > > > > > > > > effort to stabilize the vdsm API using a C
> > > > > > > > > > > > library
> > > > > > > > > > > > called
> > > > > > > > > > > > libvdsm.  There are many things that need
> > > > > > > > > > > > discussion, but I
> > > > > > > > > > > > would like to focus this thread on one in
> > > > > > > > > > > > particular:
> > > > > > > > > > > > 
> > > > > > > > > > > > Can ovirt-engine consume libvdsm via JNI?
> > > > > > > > > > > > 
> > > > > > > > > > > > libvdsm provides a full-featured C interface to
> > > > > > > > > > > > the
> > > > > > > > > > > > vdsm API
> > > > > > > > > > > > using GObject.  Java bindings are provided
> > > > > > > > > > > > automatically by
> > > > > > > > > > > > jGIR[1].  The library communicates with vdsmd
> > > > > > > > > > > > using
> > > > > > > > > > > > an
> > > > > > > > > > > > internal transport which is not exposed to end
> > > > > > > > > > > > users
> > > > > > > > > > > > (including ovirt-engine).  I would like to
> > > > > > > > > > > > learn
> > > > > > > > > > > > from folks
> > > > > > > > > > > > with deep Java knowledge if this approach is
> > > > > > > > > > > > workable.  What
> > > > > > > > > > > > are the technical challenges to integrating in
> > > > > > > > > > > > this
> > > > > > > > > > > > way?
> > > > > > > > > > > > Please save discussion of AMQP and other
> > > > > > > > > > > > bindings
> > > > > > > > > > > > for other
> > > > > > > > > > > > threads.
> > > > > > > > > > > > 
> > > > > > > > > > > > Thanks!
> > > > > > > > > > > > 
> > > > > > > > > > > > [1] https://live.gnome.org/JGIR How
> > > > > > > > > > > > mature/maintained is JGIR?
> > > > > > > > > > > > Last commit seems to be 2010-02-09.  The author
> > > > > > > > > > > > is:
> > > > > > > > > > > > Alexander
> > > > > > > > > > > > Kurtakov <akurtako at redhat.com> His status in
> > > > > > > > > > > > our
> > > > > > > > > > > > organizational chart: Employee Type:
> > > > > > > > > > > > Ex-employee
> > > > > > > > > > > It will need some work to get it up to par with
> > > > > > > > > > > the
> > > > > > > > > > > rest of the
> > > > > > > > > > > gobject generators
> > > > > > > > > > 
> > > > > > > > > > It's been dead since 2009, that doesn't seem very
> > > > > > > > > > promising
> > > > > > > > > > (http://www.ohloh.net/p/java-gobject-introspection)
> > > > > > > > > > 
> > > > > > > > > > It also states: "It also includes a custom
> > > > > > > > > > GLib/GObject
> > > > > > > > > > interface
> > > > > > > > > > layer adapted from gstreamer-java." and looking at
> > > > > > > > > > gstreamer-java
> > > > > > > > > > yields: "An unofficial/alternative set of java
> > > > > > > > > > bindings
> > > > > > > > > > for the
> > > > > > > > > > gstreamer multimedia framework"
> > > > > > > > > > 
> > > > > > > > > > Again, doesn't look like something you want to base
> > > > > > > > > > your API on.
> > > > > > > > > > Sounds to me like the 'free' java bindings come at
> > > > > > > > > > a
> > > > > > > > > > very high
> > > > > > > > > > cost (bringing JGIR up to date and maintaining it).
> > > > > > > > > > 
> > > > > > > > > > What are the alternatives?
> > > > > > > > > 
> > > > > > > > > There are two other alternatives (and one bad idea)
> > > > > > > > > that
> > > > > > > > > come to
> > > > > > > > > mind:
> > > > > > > > > 
> > > > > > > > > 1.) Generate our own Java bindings to libvdsm.so
> > > > > > > > > during
> > > > > > > > > the vdsm
> > > > > > > > > build process.
> > > > > > > > > 
> > > > > > > > > I prefer this option from an API cleanliness POV
> > > > > > > > > because
> > > > > > > > > the
> > > > > > > > > transport code would only be written once (in
> > > > > > > > > libvdsm.so).  This
> > > > > > > > > form of generation should be simple because we are
> > > > > > > > > just
> > > > > > > > > wrapping the
> > > > > > > > > library so it can be called via JNI.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 2.) Generate a native Java "library" that is
> > > > > > > > > equivalent
> > > > > > > > > to
> > > > > > > > > libvdsm.so.
> > > > > > > > > 
> > > > > > > > > This gets us into the business of libvirt-style
> > > > > > > > > bindings
> > > > > > > > > generation
> > > > > > > > > which I think is a mistake.  It opens the door to us
> > > > > > > > > maintaining
> > > > > > > > > parallel implementations of "libvdsm"s (one per
> > > > > > > > > language).
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > -1.) Standardize the transport around JSON-RPC and
> > > > > > > > > make
> > > > > > > > > that the
> > > > > > > > > supported interface.
> > > > > > > > > 
> > > > > > > > > I am only mentioning it because I am certain someone
> > > > > > > > > will
> > > > > > > > > bring it
> > > > > > > > > up.  I think it's a bad idea and it's off-topic for
> > > > > > > > > this
> > > > > > > > > particular
> > > > > > > > > thread anyway.
> > > > > > > > > 
> > > > > > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology
> > > > > > > > > Center
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology
> > > > > > > Center
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > -- Adam Litke <agl at us.ibm.com> IBM Linux Technology Center
> > > > > 
> > > > > 
> > > > 
> > > 
> > > --
> > > Adam Litke <agl at us.ibm.com>
> > > IBM Linux Technology Center
> > > 
> > > 
> > 
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> 


From lhawthor at redhat.com  Wed Aug 15 23:43:26 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Wed, 15 Aug 2012 16:43:26 -0700
Subject: oVirt CFP for KVM Forum + oVirt
Message-ID: <502C341E.4050305@redhat.com>

Hello everyone,

FYI....

=================================================================
oVirt Workshop Europe 2012: Call For Participation
November 7-9, 2012 - Hotel Fira Palace - Barcelona, Spain

(All submissions must be received before midnight Sep 14th, 2012)
=================================================================

The oVirt Project is an open virtualization project for anyone who cares
about Linux-based KVM virtualization. Providing a feature-rich server
virtualization management system with advanced capabilities for hosts
and guests, including high availability, live migration, storage
management, system scheduler, and more. By open we mean open source&
open governance, done right.

During this workshop you?ll learn about the technical background and
direction of the oVirt project. You?ll meet the developers, and have an
opportunity to see and dive into the code right away. The workshop is
open to all who want to use, get involved with, or  learn about the
comprehensive open virtualization management platform, oVirt. The
sessions cover the technical projects details, governance, getting
involved, usage, and much more. If you have any interest in an Open
Virtualization Management platform, this workshop is for you!

We are excited to announce that this oVirt Workshop will be held in
conjunction with the KVM Forum.

http://events.linuxfoundation.org/events/kvm-forum/

The KVM Forum and oVirt Workshop are co-located with the Linux
Foundation's 2012 LinuxCon Europe in Barcelona, Spain.

oVirt Workshop attendees will be able to attend KVM Forum sessions and
are eligible to attend LinuxCon Europe for a discounted rate.

http://events.linuxfoundation.org/events/kvm-forum/register

We invite you to lead part of the discussion by submitting a speaking
proposal for oVirt Workshop 2012.

http://events.linuxfoundation.org/cfp

Suggested topics:

  - community use case/stories
  - roadmaps
  - deep dives into features/areas
  - deep dives into code/debugging/tuning
  - integration and extensions
  - components: engine, vdsm, node, sdk/cli, reports, mom, guest agent, etc.
  - subjects: network, storage, vm life cycle, scheduling&  sla, gluster, etc.
  - packaging, installation and distributions
  - community infrastructure and services

SUBMISSION REQUIREMENTS

Abstracts due: Sep 14th, 2012
Notification: Sep 28th, 2012

Please submit a short abstract (~150 words) describing your presentation
proposal.  In your submission please note how long your talk will take.
Slots vary in length up to 45 minutes.  Also include in your proposal
the proposal type -- one of:

- technical talk
- end-user talk
- birds of a feather (BOF) session

Submit your proposal here:

http://events.linuxfoundation.org/cfp

You will receive a notification whether or not your presentation proposal
was accepted by Sep 14th.

END-USER COLLABORATION

One of the big challenges as developers is to know what, where and how
people actually use our software.  We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using oVirt in production you are encouraged submit a speaking
proposal.  Simply mark it as an end-user collaboration proposal.  As an
end user, this is a unique opportunity to get your input to developers.

BOF SESSION

We will reserve some slots in the evening after the main conference
tracks, for birds of a feather (BOF) sessions. These sessions will be
less formal than presentation tracks and targetted for people who would
like to discuss specific issues with other developers and/or users.
If you are interested in getting developers and/or uses together to
discuss a specific problem, please submit a BOF proposal.

LIGHTNING TALKS

In addition to submitted talks we will also have some room for lightning
talks. These are short (5 minute) discussions to highlight new work or
ideas that aren't complete enough to warrant a full presentation slot.
Lightning talk submissions and scheduling will be handled on-site at
oVirt Workshop.

HOTEL / TRAVEL

The oVirt Workshop Europe 2012 will be held in Barcelona, Spain at the
Hotel Fira Palace.

http://events.linuxfoundation.org/events/kvm-forum/hotel

Thank you for your interest in oVirt.  We're looking forward to your
submissions and seeing you at the oVirt Workshop Europe 2012 in November!

Thanks,
your oVirt Workshop Europe 2012 Program Commitee


Cheers,
LH


-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn



From smizrahi at redhat.com  Thu Aug 16 15:39:26 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 16 Aug 2012 11:39:26 -0400 (EDT)
Subject: [RFC] Exception is VDSM
In-Reply-To: <249111162.10534052.1345130940017.JavaMail.root@redhat.com>
Message-ID: <168225633.10537346.1345131566638.JavaMail.root@redhat.com>

Currently we have very specific exceptions.
This causes proliferation of exception with no real gain.

There is really no benefit for each call to throw it's own error message:
For instance, 
MiscFileReadException
MiscFileWriteException
MiscBlockReadException
MiscBlockWriteException
* There are about a 100 of these.

Could all just be "general exception". The user knows what command it ran there is no need have the exceptions specify that.

Also exception like:
ImageDoesNotExistInSD
StoragePoolMasterNotFound
StoragePoolUnknown
VMPathNotExists

Actually just mean ENOENT or EntityDoesNotExist in different contexts. There is no real reason to distinguish between them because they are also context driven.

Cutting down on the amount of exceptions to error archetypes similar to standard c errors will give us simpler API.
Also, having a specific set of exceptions per call means that every new API means a new group of supported exceptions. This makes forward compatibility very problematic.


From simon at redhat.com  Thu Aug 16 16:12:04 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 16 Aug 2012 12:12:04 -0400 (EDT)
Subject: [RFC] Exception is VDSM
In-Reply-To: <168225633.10537346.1345131566638.JavaMail.root@redhat.com>
Message-ID: <1656269361.6113983.1345133524077.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "arch" <arch at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Thursday, August 16, 2012 6:39:26 PM
> Subject: [RFC] Exception is VDSM
> 
> Currently we have very specific exceptions.
> This causes proliferation of exception with no real gain.
> 
> There is really no benefit for each call to throw it's own error
> message:
> For instance,
> MiscFileReadException
> MiscFileWriteException
> MiscBlockReadException
> MiscBlockWriteException
> * There are about a 100 of these.
> 
> Could all just be "general exception". The user knows what command it
> ran there is no need have the exceptions specify that.

Who is this 'user'?

Does 'user' operation necessary invokes just one of the above in a 1:1 correlation to what he tries to do? no complex operation that may lead to ambiguity? 

     
> 
> Also exception like:
> ImageDoesNotExistInSD
> StoragePoolMasterNotFound
> StoragePoolUnknown
> VMPathNotExists
> 
> Actually just mean ENOENT or EntityDoesNotExist in different
> contexts. There is no real reason to distinguish between them
> because they are also context driven.
> 
> Cutting down on the amount of exceptions to error archetypes similar
> to standard c errors will give us simpler API.
> Also, having a specific set of exceptions per call means that every
> new API means a new group of supported exceptions. This makes
> forward compatibility very problematic.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From smizrahi at redhat.com  Thu Aug 16 18:10:28 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 16 Aug 2012 14:10:28 -0400 (EDT)
Subject: [RFC] Exception is VDSM
In-Reply-To: <1656269361.6113983.1345133524077.JavaMail.root@redhat.com>
Message-ID: <1362045224.10594177.1345140628726.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: "arch" <arch at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Thursday, August 16, 2012 12:12:04 PM
> Subject: Re: [RFC] Exception is VDSM
> 
> 
> 
> ----- Original Message -----
> > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> > <vdsm-devel at lists.fedorahosted.org>
> > Sent: Thursday, August 16, 2012 6:39:26 PM
> > Subject: [RFC] Exception is VDSM
> > 
> > Currently we have very specific exceptions.
> > This causes proliferation of exception with no real gain.
> > 
> > There is really no benefit for each call to throw it's own error
> > message:
> > For instance,
> > MiscFileReadException
> > MiscFileWriteException
> > MiscBlockReadException
> > MiscBlockWriteException
> > * There are about a 100 of these.
> > 
> > Could all just be "general exception". The user knows what command
> > it
> > ran there is no need have the exceptions specify that.
> 
> Who is this 'user'?
Any person or program that users the API.
> 
> Does 'user' operation necessary invokes just one of the above in a
> 1:1 correlation to what he tries to do? no complex operation that
> may lead to ambiguity?
The reason is whether this "ambiguity" is important. For instance when calling getVolumeSize you might find EntityNotFound ambiguous as you don't at which point the search failed. Pool, Domain, Image, or Volume.
The point I'm making is that it isn't important like open(2) returning ENOENT and not telling you at what point it failed the search. 99.9% of the time doesn't matter. If any of them are wrong, you need to change the "path" anyway because they are all dependent and there is no way for you to handle these differently. Also, in my opinion, returning StoragePoolUnknown is a mistake because this is all just a path to an entity. So you are talking about something else.

Exception handling is about handling exceptions. Throwing something that cannot be handled seems to me like a needless complication.

I'm also only talking about public exceptions here.
> 
>      
> > 
> > Also exception like:
> > ImageDoesNotExistInSD
> > StoragePoolMasterNotFound
> > StoragePoolUnknown
> > VMPathNotExists
> > 
> > Actually just mean ENOENT or EntityDoesNotExist in different
> > contexts. There is no real reason to distinguish between them
> > because they are also context driven.
> > 
> > Cutting down on the amount of exceptions to error archetypes
> > similar
> > to standard c errors will give us simpler API.
> > Also, having a specific set of exceptions per call means that every
> > new API means a new group of supported exceptions. This makes
> > forward compatibility very problematic.
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 


From danken at redhat.com  Thu Aug 16 21:24:54 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Fri, 17 Aug 2012 00:24:54 +0300
Subject: [RFC] Exception is VDSM
In-Reply-To: <1362045224.10594177.1345140628726.JavaMail.root@redhat.com>
References: <1656269361.6113983.1345133524077.JavaMail.root@redhat.com>
	<1362045224.10594177.1345140628726.JavaMail.root@redhat.com>
Message-ID: <20120816212454.GD21170@redhat.com>

On Thu, Aug 16, 2012 at 02:10:28PM -0400, Saggi Mizrahi wrote:
> 
> 
> ----- Original Message -----
> > From: "Simon Grinberg" <simon at redhat.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: "arch" <arch at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> > Sent: Thursday, August 16, 2012 12:12:04 PM
> > Subject: Re: [RFC] Exception is VDSM
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> > > <vdsm-devel at lists.fedorahosted.org>
> > > Sent: Thursday, August 16, 2012 6:39:26 PM
> > > Subject: [RFC] Exception is VDSM
> > > 
> > > Currently we have very specific exceptions.
> > > This causes proliferation of exception with no real gain.
> > > 
> > > There is really no benefit for each call to throw it's own error
> > > message:
> > > For instance,
> > > MiscFileReadException
> > > MiscFileWriteException
> > > MiscBlockReadException
> > > MiscBlockWriteException
> > > * There are about a 100 of these.
> > > 
> > > Could all just be "general exception". The user knows what command
> > > it
> > > ran there is no need have the exceptions specify that.
> > 
> > Who is this 'user'?
> Any person or program that users the API.
> > 
> > Does 'user' operation necessary invokes just one of the above in a
> > 1:1 correlation to what he tries to do? no complex operation that
> > may lead to ambiguity?
> The reason is whether this "ambiguity" is important. For instance when calling getVolumeSize you might find EntityNotFound ambiguous as you don't at which point the search failed. Pool, Domain, Image, or Volume.
> The point I'm making is that it isn't important like open(2) returning ENOENT and not telling you at what point it failed the search. 99.9% of the time doesn't matter. If any of them are wrong, you need to change the "path" anyway because they are all dependent and there is no way for you to handle these differently. Also, in my opinion, returning StoragePoolUnknown is a mistake because this is all just a path to an entity. So you are talking about something else.

I'm guessing that Simon has alluded to Engine's difficulties to
correlate an error code with the specific API call that initiated it.
Unlike the kernel, where half of the syscalls have EPERM, Engine is (at
least used to be) confused by two verbs having the same error code.

Dan.


From smizrahi at redhat.com  Thu Aug 16 21:35:47 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 16 Aug 2012 17:35:47 -0400 (EDT)
Subject: [RFC] Exception is VDSM
In-Reply-To: <20120816212454.GD21170@redhat.com>
Message-ID: <826640280.10653817.1345152947883.JavaMail.root@redhat.com>

Well, the if you find it difficult to correlate a return value (exceptions are just fancy return values) with where they came from you have a very big problem.

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Thursday, August 16, 2012 5:24:54 PM
> Subject: Re: [RFC] Exception is VDSM
> 
> On Thu, Aug 16, 2012 at 02:10:28PM -0400, Saggi Mizrahi wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Simon Grinberg" <simon at redhat.com>
> > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>, "VDSM Project Development"
> > > <vdsm-devel at lists.fedorahosted.org>
> > > Sent: Thursday, August 16, 2012 12:12:04 PM
> > > Subject: Re: [RFC] Exception is VDSM
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> > > > <vdsm-devel at lists.fedorahosted.org>
> > > > Sent: Thursday, August 16, 2012 6:39:26 PM
> > > > Subject: [RFC] Exception is VDSM
> > > > 
> > > > Currently we have very specific exceptions.
> > > > This causes proliferation of exception with no real gain.
> > > > 
> > > > There is really no benefit for each call to throw it's own
> > > > error
> > > > message:
> > > > For instance,
> > > > MiscFileReadException
> > > > MiscFileWriteException
> > > > MiscBlockReadException
> > > > MiscBlockWriteException
> > > > * There are about a 100 of these.
> > > > 
> > > > Could all just be "general exception". The user knows what
> > > > command
> > > > it
> > > > ran there is no need have the exceptions specify that.
> > > 
> > > Who is this 'user'?
> > Any person or program that users the API.
> > > 
> > > Does 'user' operation necessary invokes just one of the above in
> > > a
> > > 1:1 correlation to what he tries to do? no complex operation that
> > > may lead to ambiguity?
> > The reason is whether this "ambiguity" is important. For instance
> > when calling getVolumeSize you might find EntityNotFound ambiguous
> > as you don't at which point the search failed. Pool, Domain,
> > Image, or Volume.
> > The point I'm making is that it isn't important like open(2)
> > returning ENOENT and not telling you at what point it failed the
> > search. 99.9% of the time doesn't matter. If any of them are
> > wrong, you need to change the "path" anyway because they are all
> > dependent and there is no way for you to handle these differently.
> > Also, in my opinion, returning StoragePoolUnknown is a mistake
> > because this is all just a path to an entity. So you are talking
> > about something else.
> 
> I'm guessing that Simon has alluded to Engine's difficulties to
> correlate an error code with the specific API call that initiated it.
> Unlike the kernel, where half of the syscalls have EPERM, Engine is
> (at
> least used to be) confused by two verbs having the same error code.
> 
> Dan.
> 


From lpeer at redhat.com  Sun Aug 19 07:22:58 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 19 Aug 2012 10:22:58 +0300
Subject: Engine supporting Cluster and Data Center level 3.2
Message-ID: <50309452.2090406@redhat.com>

Hi All,

Following previous discussion on the list a patch was sent (and
accepted) to add cluster and Data center 3.2 in the engine.

http://gerrit.ovirt.org/#/c/7169/

Please note that vdsm is reporting version 3.2 for a while now (started
reporting 3.2 soon after oVirt 3.1 release was built).

To make it easier for us to keep track of what features are supported in
3.2 cluster and data center I created the following wiki page -

http://wiki.ovirt.org/wiki/Features/compatibilityVersion


Thanks, Livnat


From lpeer at redhat.com  Sun Aug 19 07:58:07 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 19 Aug 2012 10:58:07 +0300
Subject: new design: request for comments
In-Reply-To: <502D2B16.6090401@redhat.com>
References: <502D2B16.6090401@redhat.com>
Message-ID: <50309C8F.6010906@redhat.com>

Adding the arch list (for those who do not keep track of infra and not
registered to board list)



On 16/08/12 20:17, Garrett LeSage wrote:
> Hello all,
> 
> Warning: This email is long, but important.
> 
> I've been working on a new website design for oVirt, and gave folks a
> preview during yesterday's weekly status IRC meeting.
> 
> The website mockup is at:
> http://people.redhat.com/glesage/oVirt/website/mockup-1/
> (This is simply a static PNG exported from Inkscape, wrapped in a very
> simple HTML page. Therefore, don't expect it to scale with your browser,
> have selectable text, etc.)
> 
> The mockup has many different sections and updates, and I will explain
> each change, as well as the thought process that went into each, below.
> 
> There are two main things to remember about this design:
> 1) It's a bunch of individual changes that work together.
> 2) It's a work in progress.
> 
> Also, the mockup was designed with our target audience in mind:
> administrators (setting up and running the software), enthusiasts (who
> may run instances at home), and programmers (tinkering with and
> contributing back to the project), all with experience using Linux or
> some form of UNIX. It is also important to note that our audience is
> specifically _not_ casual desktop users (although they could benefit
> from someone setting up and maintaining oVirt for them).
> 
> I'm eager to hear feedback on any and all changes, and work with you to
> refine everything.
> 
> When you do provide feedback, and want to discuss more than one point,
> please limit each email to one aspect of the site at a time. If you'd
> like to talk about the logo and the site structure, for instance, please
> send one email specifically talking about the logo, and then another
> discussing the structure. This should make conversations easier for
> everyone to follow and make it easier for me to track requested updates.
> Thanks!
> 
> 
> == Detailed changes ==
> 
> = Logo =
> 
> The oVirt logo is actually quite similar. I altered the "o" glyph, to
> make it more aesthetically pleasing.
> 
> Comparison graphic between current and new (in simple greyscale, to make
> it easy to see the difference):
> http://people.redhat.com/glesage/oVirt/logo/ovirt-logo-proposed.png
> 
> 
> = Color =
> 
> oVirt.org, right now, uses a green color throughout the site. The oVirt
> administration UI also features green in its header. As a result, I've
> pulled in that green and used it as the primary accent color for the new
> site design.
> 
> (It also has the advantage that it is not blue, which is overused for
> iconography, on the Internet, and for software in general.)
> 
> 
> = Style =
> 
> Based on the typeface of our logo and our highlight color, our new style
> reflects simplicity, openness, vibrancy, and elegance.
> 
> We can make this style work for both the WordPress and Wiki parts of the
> site.
> 
> 
> = Site structure =
> 
> A revised site structure is hinted at in the front page mockup. You can
> see this reflected in the top navigation. I did some overall
> categorization, strongly influenced by Dave Neary's pre-existing work on
> the topic.
> 
> You can see a proposed sitemap here:
> http://people.redhat.com/glesage/oVirt/website/ovirt-sitemap.txt
> 
> This is a general grouping of types of content, not necessarily a view
> of the top-level page, or of sub-pages. In some cases, these items would
> be sub-level pages, in others, they would be part of the navigation page.
> 
> The documentation page would highlight the best documentation available,
> regardless of format - e.g. wiki, blog posts, etc. - and also have a
> prominent link to the wiki. Other sub-pages may also link to the wiki,
> if there is pertinent information (such as live docs for developers,
> linked to from the develop section).
> 
> 
> = Tagline =
> 
> This is a short, catchy phrase to indicate what the project is all
> about. Since the target of oVirt is running on a server, most likely in
> a datacenter, and it's open source, I figured we should make this
> prominent.
> 
> Usually taglines are simple and direct, and often have some sort of play
> on words. "Open your virtual datacenter" can be interpreted in a few ways:
> 1) You can use oVirt to start (open up) a datacenter with virtualization
> 2) Take your existing datacenter and virtualize it
> 3) Use oVirt as an open source solution to manage your datacenter
> 
> 
> = Supporting lead-in text =
> 
> It's important to start with some powerful explanatory text to state the
> overall goal of the project. Usually, this ranges from a phrase to
> around a sentence or two.
> 
> I wanted to express the purpose of the oVirt software in a very
> high-level view, as a hook to get people interested to read more.
> 
> 
> = Call to action =
> 
> "Start using oVirt now ?" is a call-to-action button. After the simple
> text explaining what oVirt is, it's important to provide an obvious next
> step.
> 
> After clicking the button, it would take the viewer to another page
> where it provides a quick and simple way to start using oVirt.
> Naturally, one would have to download oVirt to use it, so it should be
> super-easy to do on this page. The page should also start a simple
> step-by-step guide on getting oVirt working on one's own system(s).
> 
> I'm thinking that this may be, perhaps, simply a link to the "Download &
> Use" section. Yes, it's in the navigation, but it does provide a very
> important and clear next step, which helps with a natural-feeling
> progression for an interested viewer of oVirt.org.
> 
> (BTW: If the simple guide is too complex, then we need to work at
> further simplifying the process of setting up oVirt. It's important to
> try to lower the barrier to entry. Part of this is making sure that
> oVirt can run on one machine as well, and possibly booting from live USB
> media for first-time evaluation purposes.)
> 
> 
> = Front-page sections =
> 
> Most of text on the mockup is, in some way, based on content from the
> current oVirt.org website ? it's just edited a bit.
> 
> While most everyone appreciates a clean aesthetic, our primary target
> group *also* likes to get to the point and see the information right up
> front. The mockup of the front page that I'm presenting is based on this
> concept.
> 
> In addition to being an overview of the project and the software it
> produces, it also makes it really easy to explore from the content areas
> to relevant other parts of the website. By bringing the top-level
> navigation into the context of the overviews, we make it easier for
> someone to jump to other sections, instead of having to scroll back up
> to rely on the navigation.
> 
> The order of the front-page sections is important too. A goal with this
> design was to:
> 1) Introduce people to oVirt, with a simple explanation
> 2) Let people know right upfront that it's an active project (release
> blurb)
> 3) Detail some of the most important features
> 4) Make it clear that it's a community project
> 5) Provide timely news & a way to easily get more info
> 6) Publish information on upcoming oVirt-related events (currently, in the
> mockup, there's filler text for the time being)
> 
> Items #5 & #6 should both have a way to subscribe so that someone could
> access this information without visiting oVirt.org. Twitter solves the
> news component for us; we have to make sure the calendar is able to be
> subscribed to as well.
> 
> 
> -=-=-
> 
> Thanks for reading all of this! I'm looking forward to all
> conversations, especially if it's constructive (regardless of a
> positive, negative, or neutral slant).
> 
> Garrett
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra



From mkolesni at redhat.com  Sun Aug 19 08:18:07 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 19 Aug 2012 04:18:07 -0400 (EDT)
Subject: new design: request for comments
In-Reply-To: <50309C8F.6010906@redhat.com>
Message-ID: <470030258.7873819.1345364287649.JavaMail.root@redhat.com>

----- Original Message -----
> Adding the arch list (for those who do not keep track of infra and
> not
> registered to board list)
> 
> 
> 
> On 16/08/12 20:17, Garrett LeSage wrote:
> > Hello all,
> > 
> > Warning: This email is long, but important.
> > 
> > I've been working on a new website design for oVirt, and gave folks
> > a
> > preview during yesterday's weekly status IRC meeting.
> > 
> > The website mockup is at:
> > http://people.redhat.com/glesage/oVirt/website/mockup-1/
> > (This is simply a static PNG exported from Inkscape, wrapped in a
> > very
> > simple HTML page. Therefore, don't expect it to scale with your
> > browser,
> > have selectable text, etc.)
> > 
> > The mockup has many different sections and updates, and I will
> > explain
> > each change, as well as the thought process that went into each,
> > below.
> > 
> > There are two main things to remember about this design:
> > 1) It's a bunch of individual changes that work together.
> > 2) It's a work in progress.
> > 
> > Also, the mockup was designed with our target audience in mind:
> > administrators (setting up and running the software), enthusiasts
> > (who
> > may run instances at home), and programmers (tinkering with and
> > contributing back to the project), all with experience using Linux
> > or
> > some form of UNIX. It is also important to note that our audience
> > is
> > specifically _not_ casual desktop users (although they could
> > benefit
> > from someone setting up and maintaining oVirt for them).
> > 
> > I'm eager to hear feedback on any and all changes, and work with
> > you to
> > refine everything.
> > 
> > When you do provide feedback, and want to discuss more than one
> > point,
> > please limit each email to one aspect of the site at a time. If
> > you'd
> > like to talk about the logo and the site structure, for instance,
> > please
> > send one email specifically talking about the logo, and then
> > another
> > discussing the structure. This should make conversations easier for
> > everyone to follow and make it easier for me to track requested
> > updates.
> > Thanks!
> > 
> > 
> > == Detailed changes ==
> > 
> > = Logo =
> > 
> > The oVirt logo is actually quite similar. I altered the "o" glyph,
> > to
> > make it more aesthetically pleasing.
> > 
> > Comparison graphic between current and new (in simple greyscale, to
> > make
> > it easy to see the difference):
> > http://people.redhat.com/glesage/oVirt/logo/ovirt-logo-proposed.png
> > 
> > 
> > = Color =
> > 
> > oVirt.org, right now, uses a green color throughout the site. The
> > oVirt
> > administration UI also features green in its header. As a result,
> > I've
> > pulled in that green and used it as the primary accent color for
> > the new
> > site design.
> > 
> > (It also has the advantage that it is not blue, which is overused
> > for
> > iconography, on the Internet, and for software in general.)
> > 
> > 
> > = Style =
> > 
> > Based on the typeface of our logo and our highlight color, our new
> > style
> > reflects simplicity, openness, vibrancy, and elegance.
> > 
> > We can make this style work for both the WordPress and Wiki parts
> > of the
> > site.
> > 
> > 
> > = Site structure =
> > 
> > A revised site structure is hinted at in the front page mockup. You
> > can
> > see this reflected in the top navigation. I did some overall
> > categorization, strongly influenced by Dave Neary's pre-existing
> > work on
> > the topic.
> > 
> > You can see a proposed sitemap here:
> > http://people.redhat.com/glesage/oVirt/website/ovirt-sitemap.txt
> > 
> > This is a general grouping of types of content, not necessarily a
> > view
> > of the top-level page, or of sub-pages. In some cases, these items
> > would
> > be sub-level pages, in others, they would be part of the navigation
> > page.
> > 
> > The documentation page would highlight the best documentation
> > available,
> > regardless of format - e.g. wiki, blog posts, etc. - and also have
> > a
> > prominent link to the wiki. Other sub-pages may also link to the
> > wiki,
> > if there is pertinent information (such as live docs for
> > developers,
> > linked to from the develop section).
> > 
> > 
> > = Tagline =
> > 
> > This is a short, catchy phrase to indicate what the project is all
> > about. Since the target of oVirt is running on a server, most
> > likely in
> > a datacenter, and it's open source, I figured we should make this
> > prominent.
> > 
> > Usually taglines are simple and direct, and often have some sort of
> > play
> > on words. "Open your virtual datacenter" can be interpreted in a
> > few ways:
> > 1) You can use oVirt to start (open up) a datacenter with
> > virtualization
> > 2) Take your existing datacenter and virtualize it
> > 3) Use oVirt as an open source solution to manage your datacenter
> > 
> > 
> > = Supporting lead-in text =
> > 
> > It's important to start with some powerful explanatory text to
> > state the
> > overall goal of the project. Usually, this ranges from a phrase to
> > around a sentence or two.
> > 
> > I wanted to express the purpose of the oVirt software in a very
> > high-level view, as a hook to get people interested to read more.
> > 
> > 
> > = Call to action =
> > 
> > "Start using oVirt now ?" is a call-to-action button. After the
> > simple
> > text explaining what oVirt is, it's important to provide an obvious
> > next
> > step.
> > 
> > After clicking the button, it would take the viewer to another page
> > where it provides a quick and simple way to start using oVirt.
> > Naturally, one would have to download oVirt to use it, so it should
> > be
> > super-easy to do on this page. The page should also start a simple
> > step-by-step guide on getting oVirt working on one's own system(s).
> > 
> > I'm thinking that this may be, perhaps, simply a link to the
> > "Download &
> > Use" section. Yes, it's in the navigation, but it does provide a
> > very
> > important and clear next step, which helps with a natural-feeling
> > progression for an interested viewer of oVirt.org.
> > 
> > (BTW: If the simple guide is too complex, then we need to work at
> > further simplifying the process of setting up oVirt. It's important
> > to
> > try to lower the barrier to entry. Part of this is making sure that
> > oVirt can run on one machine as well, and possibly booting from
> > live USB
> > media for first-time evaluation purposes.)
> > 
> > 
> > = Front-page sections =
> > 
> > Most of text on the mockup is, in some way, based on content from
> > the
> > current oVirt.org website ? it's just edited a bit.
> > 
> > While most everyone appreciates a clean aesthetic, our primary
> > target
> > group *also* likes to get to the point and see the information
> > right up
> > front. The mockup of the front page that I'm presenting is based on
> > this
> > concept.
> > 
> > In addition to being an overview of the project and the software it
> > produces, it also makes it really easy to explore from the content
> > areas
> > to relevant other parts of the website. By bringing the top-level
> > navigation into the context of the overviews, we make it easier for
> > someone to jump to other sections, instead of having to scroll back
> > up
> > to rely on the navigation.
> > 
> > The order of the front-page sections is important too. A goal with
> > this
> > design was to:
> > 1) Introduce people to oVirt, with a simple explanation
> > 2) Let people know right upfront that it's an active project
> > (release
> > blurb)
> > 3) Detail some of the most important features
> > 4) Make it clear that it's a community project
> > 5) Provide timely news & a way to easily get more info
> > 6) Publish information on upcoming oVirt-related events (currently,
> > in the
> > mockup, there's filler text for the time being)
> > 
> > Items #5 & #6 should both have a way to subscribe so that someone
> > could
> > access this information without visiting oVirt.org. Twitter solves
> > the
> > news component for us; we have to make sure the calendar is able to
> > be
> > subscribed to as well.
> > 

I think putting the "search box" in the bottom of the page makes it harder to find & notice.
Usually search is amongst the topmost and/or central elements in the site, as it makes it much easier for people to navigate across the site & locate the information they want.

> > 
> > -=-=-
> > 
> > Thanks for reading all of this! I'm looking forward to all
> > conversations, especially if it's constructive (regardless of a
> > positive, negative, or neutral slant).
> > 
> > Garrett
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From lpeer at redhat.com  Sun Aug 19 09:08:22 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 19 Aug 2012 12:08:22 +0300
Subject: new design: request for comments
In-Reply-To: <502E00E3.4050405@redhat.com>
References: <502D2B16.6090401@redhat.com> <502D317D.3080200@redhat.com>
	<502E00E3.4050405@redhat.com>
Message-ID: <5030AD06.40205@redhat.com>

On 17/08/12 11:29, Garrett LeSage wrote:
> On Thu 16 Aug 2012 07:44:29 PM CEST, Yaniv Kaul wrote:
>> Looks ten times better than current site!
> 
> Thanks! I'm glad you like it!
> 

I also find this much better than what we have today.
Adding more comments in context.

> 
>> - My 1366x768 laptop display cannot keep up with the length and width
>> of the page.
> 
> This mockup is a static PNG (which happens to be 1020?1192). I'll make
> sure the actual page adapts to different resolutions.
> 
> (It will definitely work fine on your resolution without horizontal
> scrolling.)
> 
> 
>> - I'm not sure what is the different between the 'use' and
>> 'documentation', and community and develop - they are tightly
>> together. How about 'Use' - 'Interact' - 'Contribute' : use (which
>> will encompass download and documentation), Contribute (for develop)
>> and Interact (for community)
> 
> I'm open for discussing the wording.
> 
> However, I chose the names for the navigation for a few reasons:
> 
> 1) People are strongly conditioned to look for the word "download". It's
> an very important keyword to have on every software-related site. I
> added "use" there as well, as a place to give quick start information as
> well as possible uses ? the latter of which would link to the
> documentation. (Use = getting started information.)

+1 for using download.
The download is something users are looking for but I think we don't
need to add 'Use' there as well.
the quick start information can be a link under documentation and even
if we add a link to that next in the download page I think it does not
have to be reflected in the main navigation link.


> 
> 2) Community is a commonly used word among developers, so it's used in
> the mockup for similar reasons. (It's not as strong as a word as
> download is, however, but it does have a extremely close association
> with FOSS projects.) The section will contain information about the
> community involvement, governance, mailing lists, and information on how
> to join IRC.
> 
> 
> Documentation is a top-level section, as:
> ? we have quite a lot of documentation already
> ? it provides a quick link for those who want to do something more with
> the oVirt instance they have set up
> ? it is primarily focused on end-user documentation, not developer
> documentation (hence the develop area)
> 
> 
> As for your other suggestions:
> ? Interact may mean interacting with the oVirt software, the oVirt
> community, or even oVirt.org itself (as if the site would be a hosted
> service, for example). It's a bit ambiguous, and the navigation should
> strive to be very clear places to navigate to.
> ? "Contribute" might work instead of "develop".
> 

How about 'Developers'	?
Contribute is not clear as we consider many forms of participation to be
contributions, like reporting on bugs and responding to mails on the
lists etc.

> 
> Summary: I chose the sections, words, and even the order for the
> navigation with purpose. Your suggestion of "contribute" could be a
> replacement for "develop", but it would require further thought (and
> perhaps some discussion).
> 
> 
> Thanks for your feedback!
> 
> Garrett
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra



From mkolesni at redhat.com  Sun Aug 19 09:27:04 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 19 Aug 2012 05:27:04 -0400 (EDT)
Subject: new design: request for comments
In-Reply-To: <50309C8F.6010906@redhat.com>
Message-ID: <1774998284.7876658.1345368424267.JavaMail.root@redhat.com>

----- Original Message -----
> Adding the arch list (for those who do not keep track of infra and
> not
> registered to board list)
> 
> 
> 
> On 16/08/12 20:17, Garrett LeSage wrote:
> > Hello all,
> > 
> > Warning: This email is long, but important.
> > 
> > I've been working on a new website design for oVirt, and gave folks
> > a
> > preview during yesterday's weekly status IRC meeting.
> > 
> > The website mockup is at:
> > http://people.redhat.com/glesage/oVirt/website/mockup-1/
> > (This is simply a static PNG exported from Inkscape, wrapped in a
> > very
> > simple HTML page. Therefore, don't expect it to scale with your
> > browser,
> > have selectable text, etc.)
> > 
> > The mockup has many different sections and updates, and I will
> > explain
> > each change, as well as the thought process that went into each,
> > below.
> > 
> > There are two main things to remember about this design:
> > 1) It's a bunch of individual changes that work together.
> > 2) It's a work in progress.
> > 
> > Also, the mockup was designed with our target audience in mind:
> > administrators (setting up and running the software), enthusiasts
> > (who
> > may run instances at home), and programmers (tinkering with and
> > contributing back to the project), all with experience using Linux
> > or
> > some form of UNIX. It is also important to note that our audience
> > is
> > specifically _not_ casual desktop users (although they could
> > benefit
> > from someone setting up and maintaining oVirt for them).
> > 
> > I'm eager to hear feedback on any and all changes, and work with
> > you to
> > refine everything.
> > 
> > When you do provide feedback, and want to discuss more than one
> > point,
> > please limit each email to one aspect of the site at a time. If
> > you'd
> > like to talk about the logo and the site structure, for instance,
> > please
> > send one email specifically talking about the logo, and then
> > another
> > discussing the structure. This should make conversations easier for
> > everyone to follow and make it easier for me to track requested
> > updates.
> > Thanks!
> > 
> > 
> > == Detailed changes ==
> > 
> > = Logo =
> > 
> > The oVirt logo is actually quite similar. I altered the "o" glyph,
> > to
> > make it more aesthetically pleasing.
> > 
> > Comparison graphic between current and new (in simple greyscale, to
> > make
> > it easy to see the difference):
> > http://people.redhat.com/glesage/oVirt/logo/ovirt-logo-proposed.png
> > 
> > 
> > = Color =
> > 
> > oVirt.org, right now, uses a green color throughout the site. The
> > oVirt
> > administration UI also features green in its header. As a result,
> > I've
> > pulled in that green and used it as the primary accent color for
> > the new
> > site design.
> > 
> > (It also has the advantage that it is not blue, which is overused
> > for
> > iconography, on the Internet, and for software in general.)
> > 
> > 
> > = Style =
> > 
> > Based on the typeface of our logo and our highlight color, our new
> > style
> > reflects simplicity, openness, vibrancy, and elegance.
> > 
> > We can make this style work for both the WordPress and Wiki parts
> > of the
> > site.
> > 
> > 
> > = Site structure =
> > 
> > A revised site structure is hinted at in the front page mockup. You
> > can
> > see this reflected in the top navigation. I did some overall
> > categorization, strongly influenced by Dave Neary's pre-existing
> > work on
> > the topic.
> > 
> > You can see a proposed sitemap here:
> > http://people.redhat.com/glesage/oVirt/website/ovirt-sitemap.txt
> > 
> > This is a general grouping of types of content, not necessarily a
> > view
> > of the top-level page, or of sub-pages. In some cases, these items
> > would
> > be sub-level pages, in others, they would be part of the navigation
> > page.
> > 
> > The documentation page would highlight the best documentation
> > available,
> > regardless of format - e.g. wiki, blog posts, etc. - and also have
> > a
> > prominent link to the wiki. Other sub-pages may also link to the
> > wiki,
> > if there is pertinent information (such as live docs for
> > developers,
> > linked to from the develop section).
> > 
> > 
> > = Tagline =
> > 
> > This is a short, catchy phrase to indicate what the project is all
> > about. Since the target of oVirt is running on a server, most
> > likely in
> > a datacenter, and it's open source, I figured we should make this
> > prominent.
> > 
> > Usually taglines are simple and direct, and often have some sort of
> > play
> > on words. "Open your virtual datacenter" can be interpreted in a
> > few ways:
> > 1) You can use oVirt to start (open up) a datacenter with
> > virtualization
> > 2) Take your existing datacenter and virtualize it
> > 3) Use oVirt as an open source solution to manage your datacenter
> > 
> > 
> > = Supporting lead-in text =
> > 
> > It's important to start with some powerful explanatory text to
> > state the
> > overall goal of the project. Usually, this ranges from a phrase to
> > around a sentence or two.
> > 
> > I wanted to express the purpose of the oVirt software in a very
> > high-level view, as a hook to get people interested to read more.
> > 
> > 
> > = Call to action =
> > 
> > "Start using oVirt now ?" is a call-to-action button. After the
> > simple
> > text explaining what oVirt is, it's important to provide an obvious
> > next
> > step.
> > 
> > After clicking the button, it would take the viewer to another page
> > where it provides a quick and simple way to start using oVirt.
> > Naturally, one would have to download oVirt to use it, so it should
> > be
> > super-easy to do on this page. The page should also start a simple
> > step-by-step guide on getting oVirt working on one's own system(s).
> > 
> > I'm thinking that this may be, perhaps, simply a link to the
> > "Download &
> > Use" section. Yes, it's in the navigation, but it does provide a
> > very
> > important and clear next step, which helps with a natural-feeling
> > progression for an interested viewer of oVirt.org.
> > 
> > (BTW: If the simple guide is too complex, then we need to work at
> > further simplifying the process of setting up oVirt. It's important
> > to
> > try to lower the barrier to entry. Part of this is making sure that
> > oVirt can run on one machine as well, and possibly booting from
> > live USB
> > media for first-time evaluation purposes.)
> > 
> > 
> > = Front-page sections =
> > 
> > Most of text on the mockup is, in some way, based on content from
> > the
> > current oVirt.org website ? it's just edited a bit.
> > 
> > While most everyone appreciates a clean aesthetic, our primary
> > target
> > group *also* likes to get to the point and see the information
> > right up
> > front. The mockup of the front page that I'm presenting is based on
> > this
> > concept.
> > 
> > In addition to being an overview of the project and the software it
> > produces, it also makes it really easy to explore from the content
> > areas
> > to relevant other parts of the website. By bringing the top-level
> > navigation into the context of the overviews, we make it easier for
> > someone to jump to other sections, instead of having to scroll back
> > up
> > to rely on the navigation.
> > 
> > The order of the front-page sections is important too. A goal with
> > this
> > design was to:
> > 1) Introduce people to oVirt, with a simple explanation
> > 2) Let people know right upfront that it's an active project
> > (release
> > blurb)
> > 3) Detail some of the most important features
> > 4) Make it clear that it's a community project
> > 5) Provide timely news & a way to easily get more info
> > 6) Publish information on upcoming oVirt-related events (currently,
> > in the
> > mockup, there's filler text for the time being)

I think the home page is overcrowded with text.
It makes me feel like I am reading a blog or some sort of PDF .

Adding to this is the monotonicity of using only the green color..

I think if we take as example Fedora or Gnome sites, you can see they look more colorful and less intimidating (less text in-your-face and the text is down the page, where whoever is really interested in it can read it).

Of course we're not talking about a desktop shell site here, but I think more graphics would make it more pleasant to look at.

Also I would add some screenshots/screencasts (maybe even a section where more can be viewed) since it really helps visualize what the product is and what it does.

> > 
> > Items #5 & #6 should both have a way to subscribe so that someone
> > could
> > access this information without visiting oVirt.org. Twitter solves
> > the
> > news component for us; we have to make sure the calendar is able to
> > be
> > subscribed to as well.
> > 
> > 
> > -=-=-
> > 
> > Thanks for reading all of this! I'm looking forward to all
> > conversations, especially if it's constructive (regardless of a
> > positive, negative, or neutral slant).
> > 
> > Garrett
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From danken at redhat.com  Mon Aug 20 06:54:45 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 20 Aug 2012 09:54:45 +0300
Subject: Host network management roadmap inquiry
In-Reply-To: <20120813114407.GC699@redhat.com>
References: <50192822.9030309@linux.vnet.ibm.com> <501D5694.7090103@redhat.com>
	<20120813114407.GC699@redhat.com>
Message-ID: <20120820065445.GA2561@redhat.com>

On Mon, Aug 13, 2012 at 02:44:07PM +0300, Dan Kenigsberg wrote:
> On Sat, Aug 04, 2012 at 08:06:28PM +0300, Livnat Peer wrote:
> > On 01/08/12 15:59, Mark Wu wrote:
> > > Sorry for cross-posting!
> > > 
> > > I would like to inquiry about the roadmap of host network management in
> > > oVirt in order to
> > > make sure the ideas to be worked on are welcomed by community.
> > > 
> > > I did some initial investigation on the following topics.  I am not very
> > > familiar with them, so the information may contain some inaccuracies or
> > > errors.
> > > 
> > 
> > Hi Mark,
> > 
> > My name is Livnat Peer, I'm focused on Networking in oVirt.
> > I am wondering if there is an interest for a monthly meeting on
> > networking in oVirt. I think we can discuss the current status in
> > networking features/bugs and the road map for future oVirt versions.
> > 
> > > netcf:
> > >     
> > >     It provides cross-platform network configuration library/tool by
> > > converting the XML definition of an interface into local config file.
> > > It's already used by libvirt to manage host network interfaces.It
> > > supports all network entities including bridge, vlan, bond, nic. And it
> > > also supports configuration rollback.  The benefit for vdsm is making
> > > host network stack configuration easy to port to other distros.
> > >     
> > > Problems found:
> > >     It doesn't restore interface live state during config transaction
> > > now. There's a feature request submit for it.
> > >     There're some advanced settings not supported in netcf, like
> > > 'NM_CONTROLLED' and some less used bonding options.
> > > 
> > >     It doesn't provide python binding officially. But we can use libvirt
> > > API to integrate it into vdsm. It shouldn't have any impact on engine side.
> > > 
> > 
> > Making it easy to consume vdsm in other distros has great value for the
> > ovirt project, I don't see a reason why not to do that.
> > I think we should start with mapping the gaps of the functionality
> > currently used by vdsm and see what is missing for us to use netcf.
> > I think there was a proposal to use Network Manager in Fedora that also
> > was supposed to work with netcf but I don't have more details on that,
> > 
> > danken  - do you recall something more specific?
> 
> I'm afraid not - netcf-in-NM has been in the planning phase for quite
> some time, but NetworkManager still does its own config file parsing.
> 
> Now that NM supports bridges,

I have to stand corrected - bridges are on NM agenda, but they are not
yet in. I'm not crazy about its dbus interface but the next statements
still stand:

> due to its ubiquitousness on the
> desktop, we may want to use it as an API to managing host networking,
> instead of asking it "don't touch our config, mister!"
> (NM_CONTROLLED=no).
> 
> Note that I haven't analysed NM's gaps for our use case, on top of my
> issues of trusting a package with an UpperCase name.


From dfediuck at redhat.com  Mon Aug 20 10:37:10 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 20 Aug 2012 06:37:10 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <1629476053.6079144.1344462091144.JavaMail.root@redhat.com>
Message-ID: <304932589.32541783.1345459030349.JavaMail.root@redhat.com>

Hi All,

Recently, we've been doing some thinking on commit message templates.
It seems that for commit subjects, vdsm is using a general concept of-
BZ#??????? some message

Whilst for the engine, we have something like:
<core | restapi | tools | history | engine | userportal | webadmin>: short summary under 50 chars (#xxxxxx)

Since several people are looking at writing some scripts to extract BZ numbers
from commit messages, I'd like to propose a minor change both for vdsm and engine,
which should benefit both projects.

The change, originally suggested by Alon Bar-Lev, is to remove BZ reference from
commit subject, and add it to the message body as "Bug-Id: BZ#?????? description".

* For engine, we'll have-
=====================================================================================
<core | restapi | tools | history | engine | userportal | webadmin>: short summary under 50 chars

...
 (message body)
...

    Bug-Id: BZ#888888 dummy bz1
    Bug-Id: BZ#888889 dummy bz2
    Bug-Id: BZ#888890 dummy bz2
    Change-Id: Ixxxxx
    Signed-off-by: Igor Lvovsky <ilvovsky at redhat.com>
    Reviewed-on: http://gerrit.ovirt.org/8888
    Reviewed-by: Dan Kenigsberg <danken at redhat.com>

=====================================================================================

* and for vdsm-
=====================================================================================
    networking: Fix some issue

...
 (message body)
...

    Bug-Id: BZ#888888 dummy bz1
    Bug-Id: BZ#888889 dummy bz2
    Bug-Id: BZ#888890 dummy bz2
    Change-Id: Ixxxxx
    Signed-off-by: Igor Lvovsky <ilvovsky at redhat.com>
    Reviewed-on: http://gerrit.ovirt.org/8888
    Reviewed-by: Dan Kenigsberg <danken at redhat.com>

=====================================================================================

As you can see, with this change:
 
1. We have more space for commit text;

2. We can document easily several bugs;

3. It is clear what bugs we solve as the description is embedded;

4. It is easy to automate fetching bug ids from commit message;

5. A commit msg hooks can be easily implemented to fetch the bug description and embed description.


Any objections?

Doron.


P.S.
Currently this is suggested for engine and vdsm projects.
Other projects are invited to adopt this proposal, but it's completely optional.


From emesika at redhat.com  Mon Aug 20 12:27:38 2012
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 20 Aug 2012 08:27:38 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <304932589.32541783.1345459030349.JavaMail.root@redhat.com>
Message-ID: <820174238.50804111.1345465658388.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: arch at ovirt.org
> Sent: Monday, August 20, 2012 1:37:10 PM
> Subject: Unifying (parts of) engine and vdsm commit templates.
> 
> Hi All,
> 
> Recently, we've been doing some thinking on commit message templates.
> It seems that for commit subjects, vdsm is using a general concept
> of-
> BZ#??????? some message
> 
> Whilst for the engine, we have something like:
> <core | restapi | tools | history | engine | userportal | webadmin>:
> short summary under 50 chars (#xxxxxx)
> 
> Since several people are looking at writing some scripts to extract
> BZ numbers
> from commit messages, I'd like to propose a minor change both for
> vdsm and engine,
> which should benefit both projects.
> 
> The change, originally suggested by Alon Bar-Lev, is to remove BZ
> reference from
> commit subject, and add it to the message body as "Bug-Id: BZ#??????
> description".
> 
> * For engine, we'll have-
> =====================================================================================
> <core | restapi | tools | history | engine | userportal | webadmin>:
> short summary under 50 chars
> 
> ...
>  (message body)
> ...
> 
>     Bug-Id: BZ#888888 dummy bz1
>     Bug-Id: BZ#888889 dummy bz2
>     Bug-Id: BZ#888890 dummy bz2
>     Change-Id: Ixxxxx
>     Signed-off-by: Igor Lvovsky <ilvovsky at redhat.com>
>     Reviewed-on: http://gerrit.ovirt.org/8888
>     Reviewed-by: Dan Kenigsberg <danken at redhat.com>
> 
> =====================================================================================
> 
> * and for vdsm-
> =====================================================================================
>     networking: Fix some issue
> 
> ...
>  (message body)
> ...
> 
>     Bug-Id: BZ#888888 dummy bz1
>     Bug-Id: BZ#888889 dummy bz2
>     Bug-Id: BZ#888890 dummy bz2
>     Change-Id: Ixxxxx
>     Signed-off-by: Igor Lvovsky <ilvovsky at redhat.com>
>     Reviewed-on: http://gerrit.ovirt.org/8888
>     Reviewed-by: Dan Kenigsberg <danken at redhat.com>
> 
> =====================================================================================
> 
> As you can see, with this change:
>  
> 1. We have more space for commit text;
> 
> 2. We can document easily several bugs;
> 
> 3. It is clear what bugs we solve as the description is embedded;
> 
> 4. It is easy to automate fetching bug ids from commit message;
> 
> 5. A commit msg hooks can be easily implemented to fetch the bug
> description and embed description.
> 
> 
> Any objections?
+1
> 
> Doron.
> 
> 
> P.S.
> Currently this is suggested for engine and vdsm projects.
> Other projects are invited to adopt this proposal, but it's
> completely optional.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From garrett at redhat.com  Mon Aug 20 15:12:36 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Mon, 20 Aug 2012 17:12:36 +0200
Subject: new design: request for comments
In-Reply-To: <470030258.7873819.1345364287649.JavaMail.root@redhat.com>
References: <470030258.7873819.1345364287649.JavaMail.root@redhat.com>
Message-ID: <503253E4.4060600@redhat.com>

On 08/19/2012 10:18 AM, Mike Kolesnik wrote:
> I think putting the "search box" in the bottom of the page makes it harder to find & notice.
> Usually search is amongst the topmost and/or central elements in the site, as it makes it much easier for people to navigate across the site & locate the information they want.

I made a deliberate decision to downplay the importance of search on the 
mockup for the front page for these reasons:
? Someone should be able to easily find the correct content without 
having to resort to search.
? Right now, the form only searches WordPress, which is not very useful. 
Searching the contents of the is a great thing, however.

Solutions for improving search:
1) Combined WordPress + MediaWiki search results. (If it's not easily 
possible [1], we could consider _only_ searching MediaWiki, perhaps.)
2) Highlight search in the documentation area. Basically, when someone 
clicks on documentation, it has the most common and useful documentation 
grouped on the page, and above that, a big search entry (which is 
prefocused, so one could simply type and hit enter, when visiting 
ovirt.org/documentation).

[1] There are several plugins for integrating the two, but they all seem 
to focus on embedding, adding comments, or using a single sign-in (which 
could still be useful for us).


I'm currently working on a designs for the sections, and will be 
including a large search at the top of the documentation page to make 
sure searching is more prominent. Hopefully this will address your concern.

Thanks for your feedback!

Garrett


From kanagaraj.rk at gmail.com  Tue Aug 21 01:03:29 2012
From: kanagaraj.rk at gmail.com (R.Kanagaraj (RK))
Date: Tue, 21 Aug 2012 06:33:29 +0530
Subject: Fwd: Speakers Needed: Upcoming Workshops
In-Reply-To: <CALVLwtb6b0OH6HMBNc6C+uzpuiV9xi4273J+GqeLNCB-ipiFXA@mail.gmail.com>
References: <5022DEDC.1090007@redhat.com>
	<CALVLwtbq3j9DggCwC=n+Vhu9MaiEedj56Qj7FMRYQt2=-RMeiA@mail.gmail.com>
	<5022EE33.7090504@redhat.com>
	<CALVLwtZFonW2pccYKiUtgqwQ87SojjMX_hpyAHk1zLti_7qLyw@mail.gmail.com>
	<50245E31.3000003@redhat.com>
	<CALVLwtb6b0OH6HMBNc6C+uzpuiV9xi4273J+GqeLNCB-ipiFXA@mail.gmail.com>
Message-ID: <CALVLwta88LOYOV5MVqgX+HRy0Fpq_DpkZimOKMXAeaMntR9gSA@mail.gmail.com>

Mistakenly I sent to lhawthor only, so I am forwarding it now.

---------- Forwarded message ----------
From: R.Kanagaraj (RK) <kanagaraj.rk at gmail.com>
Date: Thu, Aug 16, 2012 at 6:32 PM
Subject: Re: Speakers Needed: Upcoming Workshops
To: lhawthor at redhat.com


I am R Kanagaraj (RK) an open source enthusiast, stuck with Linux from my
10th  standard(7 years back) and started my IT career as linux desktop
admin and grown with technical expertise to deploy several RHEV and Redhat
Clustering in large production environments. Now got more interest in oVirt
and planned to contribute, thus joined this list indeed.

The session I am going to present in oVirt workshop at Banglore Red hat
campus will briefly discuss from prerequisites to setup simple test
environment to large scale oVirt deployment and explains in detail about
different user portals, creating VMs, templates, configuring HA, forming
clusters, adding storage.

This session will require 30 Mins approx.


On Fri, Aug 10, 2012 at 6:34 AM, Leslie Hawthorn <lhawthor at redhat.com>wrote:

>  On 08/09/2012 05:35 PM, R.Kanagaraj (RK) wrote:
>
> will update you soon.
>
> Excellent - thank you!
>
> Cheers,
>
> LH
>
>
> On Thu, Aug 9, 2012 at 4:24 AM, Leslie Hawthorn <lhawthor at redhat.com>wrote:
>
>>  On 08/08/2012 03:44 PM, R.Kanagaraj (RK) wrote:
>>
>> Dear all,
>>
>> I would like to give a live session on deploying ovirt node, engine and
>> perform basic tasks such as adding storage, creating data center etc.,.
>>
>>  Hi RK,
>>
>> Great to hear from you! Would you please send me an abstract so I can
>> take a look at it and determine how it would best fit into the program? A
>> speaker bio would also be a welcome addition. If you would like to take a
>> look at a sample, you can find one here:
>>
>> http://events.linuxfoundation.org/events/linuxcon/ovirt-architecture
>>
>> Best,
>> LH
>>
>>
>>
>>  On Thu, Aug 9, 2012 at 3:19 AM, Leslie Hawthorn <lhawthor at redhat.com>wrote:
>>
>>> Hello everyone,
>>>
>>> First of all, congratulations to the team on today's release of oVirt
>>> 3.1!
>>>
>>> As mentioned in today's weekly status IRC meeting, we would like to
>>> ensure we have broad community participation in upcoming workshops. [0] For
>>> KVM Forum + oVirt in Barcelona [1], a general call for papers will be
>>> issued within the next few days. I will send a note to these lists when
>>> details of the CFP have been announced.
>>>
>>> For the oVirt workshop to be hosted at Red Hat's Bangalore campus on 16
>>> October 2012, it would be wonderful if folks would propose sessions for
>>> this workshop. (We have chosen not to go through a formal CFP process for
>>> Bangalore so as to leave sufficient time for the KVM Forum + oVirt CFP
>>> process to run most smoothly.) If you would like to propose a session for
>>> oVirt Bangalore, please email me and I follow up with you.
>>>
>>> As usual, any questions, please let me know.
>>>
>>> [0] - http://wiki.ovirt.org/wiki/OVirt_Global_Workshops
>>> [1] - http://events.linuxfoundation.org/events/kvm-forum/
>>>
>>> Cheers,
>>> LH
>>>
>>> --
>>> Leslie Hawthorn
>>> Community Action and Impact
>>> Open Source and Standards @ Red Hat
>>>
>>> identi.ca/lh
>>> twitter.com/lhawthorn
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
>>
>>
>> --
>>
>> With Regards,
>> RK,
>> +91 98404 83044 <%2B91%2098404%2083044>
>>
>>
>>
>> --
>> Leslie Hawthorn
>> Community Action and Impact
>> Open Source and Standards @ Red Hat
>> identi.ca/lhtwitter.com/lhawthorn
>>
>>
>
>
> --
>
> With Regards,
> RK,
> +91 98404 83044
>
>
>
> --
> Leslie Hawthorn
> Community Action and Impact
> Open Source and Standards @ Red Hat
> identi.ca/lhtwitter.com/lhawthorn
>
>


-- 

With Regards,
RK,
+91 98404 83044




-- 

With Regards,
RK,
+91 98404 83044
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120821/74f4a317/attachment.html>

From iheim at redhat.com  Tue Aug 21 07:22:49 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 21 Aug 2012 10:22:49 +0300
Subject: [vdsm] Jenkins testing.
In-Reply-To: <5029FCA3.90109@linux.vnet.ibm.com>
References: <5029E56A.8070909@middleswarth.net>
	<5029FCA3.90109@linux.vnet.ibm.com>
Message-ID: <50333749.8070605@redhat.com>

On 08/14/2012 10:22 AM, Deepak C Shetty wrote:
> On 08/14/2012 11:13 AM, Robert Middleswarth wrote:
>> After a few false starts it looks like we have per patch testing
>> working on VDSM, oVirt-engine, oVirt-engine-sdk and oVirt-engine-cli.
>> There are 3 status a patch can get.  1) Success - Means the patch ran
>> though the tests without issue.  2) Failure - Means the tests failed.
>> 3) Aborted - Generally means the submitter is not in the whitelist and
>> the tests were never run.  If you have any questions please feel free
>> to ask.
>>
> So what is needed for the submitted to be in whitelist ?
> I once for Success for few of my patches.. then got failure for some
> other patch( maybe thats due to the false starts u had) and then for the
> latest patch of mine, it says aborted.
>
> So not sure if i am in whitelist or not ?
> If not, what do i need to do to be part of it ?

robert is adding these per failed jobs.
we track the whitelist as a git repo in gerrit:
http://gerrit.ovirt.org/gitweb?p=jenkins-whitelist.git;a=blob;f=jenkins-whitelist.txt

> If yes, why did the build abort for my latest patch ?
>
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra




From apevec at gmail.com  Tue Aug 21 09:20:11 2012
From: apevec at gmail.com (Alan Pevec)
Date: Tue, 21 Aug 2012 11:20:11 +0200
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <304932589.32541783.1345459030349.JavaMail.root@redhat.com>
References: <1629476053.6079144.1344462091144.JavaMail.root@redhat.com>
	<304932589.32541783.1345459030349.JavaMail.root@redhat.com>
Message-ID: <CAGi==UVeY3-W83LMQ36QzWdrXVTNA6vCY1oCGQUH8Jv4G-feMw@mail.gmail.com>

On Mon, Aug 20, 2012 at 12:37 PM, Doron Fediuck <dfediuck at redhat.com> wrote:
> The change, originally suggested by Alon Bar-Lev, is to remove BZ reference from
> commit subject, and add it to the message body as "Bug-Id: BZ#?????? description".

Very good suggestion, subject space is precious and should help the
reader to immediately see if she's interesed in the patch or not
without additional lookup.

I'd also suggest to permanently document in ovirt wiki how good commit
message should look like, you could reuse parts of danpb's excellent
write-up http://wiki.openstack.org/GitCommitMessages

Cheers,
Alan


From danken at redhat.com  Tue Aug 21 10:49:18 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 21 Aug 2012 13:49:18 +0300
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <304932589.32541783.1345459030349.JavaMail.root@redhat.com>
References: <1629476053.6079144.1344462091144.JavaMail.root@redhat.com>
	<304932589.32541783.1345459030349.JavaMail.root@redhat.com>
Message-ID: <20120821104918.GG30843@redhat.com>

On Mon, Aug 20, 2012 at 06:37:10AM -0400, Doron Fediuck wrote:
> Hi All,
> 
> Recently, we've been doing some thinking on commit message templates.
> It seems that for commit subjects, vdsm is using a general concept of-
> BZ#??????? some message
> 
> Whilst for the engine, we have something like:
> <core | restapi | tools | history | engine | userportal | webadmin>: short summary under 50 chars (#xxxxxx)
> 
> Since several people are looking at writing some scripts to extract BZ numbers
> from commit messages, I'd like to propose a minor change both for vdsm and engine,
> which should benefit both projects.
> 
> The change, originally suggested by Alon Bar-Lev, is to remove BZ reference from
> commit subject, and add it to the message body as "Bug-Id: BZ#?????? description".
> 
> * For engine, we'll have-
> =====================================================================================
> <core | restapi | tools | history | engine | userportal | webadmin>: short summary under 50 chars
> 
> ...
>  (message body)
> ...
> 
>     Bug-Id: BZ#888888 dummy bz1
>     Bug-Id: BZ#888889 dummy bz2
>     Bug-Id: BZ#888890 dummy bz2
>     Change-Id: Ixxxxx
>     Signed-off-by: Igor Lvovsky <ilvovsky at redhat.com>
>     Reviewed-on: http://gerrit.ovirt.org/8888
>     Reviewed-by: Dan Kenigsberg <danken at redhat.com>
> 
> =====================================================================================
> 
> * and for vdsm-
> =====================================================================================
>     networking: Fix some issue
> 
> ...
>  (message body)
> ...
> 
>     Bug-Id: BZ#888888 dummy bz1
>     Bug-Id: BZ#888889 dummy bz2
>     Bug-Id: BZ#888890 dummy bz2

I think it's fine, though I find the "BZ#" string quite redundant when
it appears after "Bug-Id: "

>     Change-Id: Ixxxxx
>     Signed-off-by: Igor Lvovsky <ilvovsky at redhat.com>
>     Reviewed-on: http://gerrit.ovirt.org/8888
>     Reviewed-by: Dan Kenigsberg <danken at redhat.com>
> 
> =====================================================================================
> 
> As you can see, with this change:
>  
> 1. We have more space for commit text;
> 
> 2. We can document easily several bugs;
> 
> 3. It is clear what bugs we solve as the description is embedded;
> 
> 4. It is easy to automate fetching bug ids from commit message;
> 
> 5. A commit msg hooks can be easily implemented to fetch the bug description and embed description.
> 
> 
> Any objections?




From alonbl at redhat.com  Tue Aug 21 10:53:57 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 21 Aug 2012 06:53:57 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <20120821104918.GG30843@redhat.com>
Message-ID: <622920120.2366806.1345546437662.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>, "Igor Lvovsky" <ilvovsky at redhat.com>
> Sent: Tuesday, August 21, 2012 1:49:18 PM
> Subject: Re: Unifying (parts of) engine and vdsm commit templates.

<snip>

> > 
> >     Bug-Id: BZ#888888 dummy bz1
> >     Bug-Id: BZ#888889 dummy bz2
> >     Bug-Id: BZ#888890 dummy bz2
> 
> I think it's fine, though I find the "BZ#" string quite redundant
> when
> it appears after "Bug-Id: "
> 

The BZ# was added (or kept) in order to allow <some> flexibility when referencing to different bug tracking systems (multiple name-spaces). For example, we may accept conventions of LP# for ubuntu launchpad.

Regards,
Alon.


From mkolesni at redhat.com  Tue Aug 21 11:27:05 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 21 Aug 2012 07:27:05 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <622920120.2366806.1345546437662.JavaMail.root@redhat.com>
Message-ID: <15304977.8857202.1345548425631.JavaMail.root@redhat.com>

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>, "Igor
> > Lvovsky" <ilvovsky at redhat.com>
> > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> <snip>
> 
> > > 
> > >     Bug-Id: BZ#888888 dummy bz1
> > >     Bug-Id: BZ#888889 dummy bz2
> > >     Bug-Id: BZ#888890 dummy bz2
> > 
> > I think it's fine, though I find the "BZ#" string quite redundant
> > when
> > it appears after "Bug-Id: "
> > 
> 
> The BZ# was added (or kept) in order to allow <some> flexibility when
> referencing to different bug tracking systems (multiple
> name-spaces). For example, we may accept conventions of LP# for
> ubuntu launchpad.

Why not simply use a bug link, then?

> 
> Regards,
> Alon.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From alonbl at redhat.com  Tue Aug 21 11:29:33 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 21 Aug 2012 07:29:33 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <15304977.8857202.1345548425631.JavaMail.root@redhat.com>
Message-ID: <1294680683.2372174.1345548573330.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: arch at ovirt.org, "Dan Kenigsberg" <danken at redhat.com>
> Sent: Tuesday, August 21, 2012 2:27:05 PM
> Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>, "Igor
> > > Lvovsky" <ilvovsky at redhat.com>
> > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > templates.
> > 
> > <snip>
> > 
> > > > 
> > > >     Bug-Id: BZ#888888 dummy bz1
> > > >     Bug-Id: BZ#888889 dummy bz2
> > > >     Bug-Id: BZ#888890 dummy bz2
> > > 
> > > I think it's fine, though I find the "BZ#" string quite redundant
> > > when
> > > it appears after "Bug-Id: "
> > > 
> > 
> > The BZ# was added (or kept) in order to allow <some> flexibility
> > when
> > referencing to different bug tracking systems (multiple
> > name-spaces). For example, we may accept conventions of LP# for
> > ubuntu launchpad.
> 
> Why not simply use a bug link, then?

It is long... I think the bug description is more important, providing both URL and description will make way too long.

I am fine with dropping the prefix as well, just wanted to explain why I suggested to use it.

Regards,
Alon.


From mkolesni at redhat.com  Tue Aug 21 11:36:13 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 21 Aug 2012 07:36:13 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <1294680683.2372174.1345548573330.JavaMail.root@redhat.com>
Message-ID: <1399724983.8864875.1345548973175.JavaMail.root@redhat.com>

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: arch at ovirt.org, "Dan Kenigsberg" <danken at redhat.com>
> > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>, "Igor
> > > > Lvovsky" <ilvovsky at redhat.com>
> > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > templates.
> > > 
> > > <snip>
> > > 
> > > > > 
> > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > 
> > > > I think it's fine, though I find the "BZ#" string quite
> > > > redundant
> > > > when
> > > > it appears after "Bug-Id: "
> > > > 
> > > 
> > > The BZ# was added (or kept) in order to allow <some> flexibility
> > > when
> > > referencing to different bug tracking systems (multiple
> > > name-spaces). For example, we may accept conventions of LP# for
> > > ubuntu launchpad.
> > 
> > Why not simply use a bug link, then?
> 
> It is long... I think the bug description is more important,
> providing both URL and description will make way too long.

Bug titles aren't constant. Also they provide little value as most of the time the bug decription and reproduction steps are much more informative than what the title says.

Also in the engine we have lived a long time with bug URL in the comment and it was very convenient.

> 
> I am fine with dropping the prefix as well, just wanted to explain
> why I suggested to use it.
> 
> Regards,
> Alon.
> 


From danken at redhat.com  Tue Aug 21 12:27:07 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 21 Aug 2012 15:27:07 +0300
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <622920120.2366806.1345546437662.JavaMail.root@redhat.com>
References: <20120821104918.GG30843@redhat.com>
	<622920120.2366806.1345546437662.JavaMail.root@redhat.com>
Message-ID: <20120821122707.GA32572@redhat.com>

On Tue, Aug 21, 2012 at 06:53:57AM -0400, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>, "Igor Lvovsky" <ilvovsky at redhat.com>
> > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> <snip>
> 
> > > 
> > >     Bug-Id: BZ#888888 dummy bz1
> > >     Bug-Id: BZ#888889 dummy bz2
> > >     Bug-Id: BZ#888890 dummy bz2
> > 
> > I think it's fine, though I find the "BZ#" string quite redundant
> > when
> > it appears after "Bug-Id: "
> > 
> 
> The BZ# was added (or kept) in order to allow <some> flexibility when referencing to different bug tracking systems (multiple name-spaces). For example, we may accept conventions of LP# for ubuntu launchpad.

Makes sense. I've seen rhbz# being used for that purpose.


From ofrenkel at redhat.com  Tue Aug 21 15:36:54 2012
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Tue, 21 Aug 2012 11:36:54 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <1399724983.8864875.1345548973175.JavaMail.root@redhat.com>
Message-ID: <1615227765.36951483.1345563414527.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: arch at ovirt.org
> Sent: Tuesday, August 21, 2012 2:36:13 PM
> Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: arch at ovirt.org, "Dan Kenigsberg" <danken at redhat.com>
> > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > templates.
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>, "Igor
> > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > templates.
> > > > 
> > > > <snip>
> > > > 
> > > > > > 
> > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > 
> > > > > I think it's fine, though I find the "BZ#" string quite
> > > > > redundant
> > > > > when
> > > > > it appears after "Bug-Id: "
> > > > > 
> > > > 
> > > > The BZ# was added (or kept) in order to allow <some>
> > > > flexibility
> > > > when
> > > > referencing to different bug tracking systems (multiple
> > > > name-spaces). For example, we may accept conventions of LP# for
> > > > ubuntu launchpad.
> > > 
> > > Why not simply use a bug link, then?
> > 
> > It is long... I think the bug description is more important,
> > providing both URL and description will make way too long.
> 
> Bug titles aren't constant. Also they provide little value as most of
> the time the bug decription and reproduction steps are much more
> informative than what the title says.
> 
> Also in the engine we have lived a long time with bug URL in the
> comment and it was very convenient.
>

I agree, i find bug url much more convenient than bug title
 
> > 
> > I am fine with dropping the prefix as well, just wanted to explain
> > why I suggested to use it.
> > 
> > Regards,
> > Alon.
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From smizrahi at redhat.com  Tue Aug 21 18:54:28 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 21 Aug 2012 14:54:28 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <1615227765.36951483.1345563414527.JavaMail.root@redhat.com>
Message-ID: <222981603.12287075.1345575268877.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Cc: arch at ovirt.org
> Sent: Tuesday, August 21, 2012 11:36:54 AM
> Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> 
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Tuesday, August 21, 2012 2:36:13 PM
> > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: arch at ovirt.org, "Dan Kenigsberg" <danken at redhat.com>
> > > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > templates.
> > > > 
> > > > ----- Original Message -----
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>,
> > > > > > "Igor
> > > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > templates.
> > > > > 
> > > > > <snip>
> > > > > 
> > > > > > > 
> > > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > > 
> > > > > > I think it's fine, though I find the "BZ#" string quite
> > > > > > redundant
> > > > > > when
> > > > > > it appears after "Bug-Id: "
> > > > > > 
> > > > > 
> > > > > The BZ# was added (or kept) in order to allow <some>
> > > > > flexibility
> > > > > when
> > > > > referencing to different bug tracking systems (multiple
> > > > > name-spaces). For example, we may accept conventions of LP#
> > > > > for
> > > > > ubuntu launchpad.
> > > > 
> > > > Why not simply use a bug link, then?
> > > 
> > > It is long... I think the bug description is more important,
> > > providing both URL and description will make way too long.
> > 
> > Bug titles aren't constant. Also they provide little value as most
> > of
> > the time the bug decription and reproduction steps are much more
> > informative than what the title says.
> > 
> > Also in the engine we have lived a long time with bug URL in the
> > comment and it was very convenient.
> >
> 
> I agree, i find bug url much more convenient than bug title
+1, most of the time the bug titles don't actually even point to what the problem actually was but rather what the reporter thought it was.
>  
> > > 
> > > I am fine with dropping the prefix as well, just wanted to
> > > explain
> > > why I suggested to use it.
> > > 
> > > Regards,
> > > Alon.
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From alonbl at redhat.com  Tue Aug 21 18:59:16 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 21 Aug 2012 14:59:16 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <222981603.12287075.1345575268877.JavaMail.root@redhat.com>
Message-ID: <1971319159.2475836.1345575556171.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: arch at ovirt.org
> Sent: Tuesday, August 21, 2012 9:54:28 PM
> Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> 
> 
> ----- Original Message -----
> > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Tuesday, August 21, 2012 11:36:54 AM
> > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Tuesday, August 21, 2012 2:36:13 PM
> > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > templates.
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > Cc: arch at ovirt.org, "Dan Kenigsberg" <danken at redhat.com>
> > > > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > templates.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>,
> > > > > > > "Igor
> > > > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > templates.
> > > > > > 
> > > > > > <snip>
> > > > > > 
> > > > > > > > 
> > > > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > > > 
> > > > > > > I think it's fine, though I find the "BZ#" string quite
> > > > > > > redundant
> > > > > > > when
> > > > > > > it appears after "Bug-Id: "
> > > > > > > 
> > > > > > 
> > > > > > The BZ# was added (or kept) in order to allow <some>
> > > > > > flexibility
> > > > > > when
> > > > > > referencing to different bug tracking systems (multiple
> > > > > > name-spaces). For example, we may accept conventions of LP#
> > > > > > for
> > > > > > ubuntu launchpad.
> > > > > 
> > > > > Why not simply use a bug link, then?
> > > > 
> > > > It is long... I think the bug description is more important,
> > > > providing both URL and description will make way too long.
> > > 
> > > Bug titles aren't constant. Also they provide little value as
> > > most
> > > of
> > > the time the bug decription and reproduction steps are much more
> > > informative than what the title says.
> > > 
> > > Also in the engine we have lived a long time with bug URL in the
> > > comment and it was very convenient.
> > >
> > 
> > I agree, i find bug url much more convenient than bug title
> +1, most of the time the bug titles don't actually even point to what
> the problem actually was but rather what the reporter thought it
> was.

Hi,

You are awrae that the original suggestion was the bug# and bug title.

One can always refer to the bug if he likes, the URL is well known.

Alon.


From robert at middleswarth.net  Wed Aug 22 02:10:02 2012
From: robert at middleswarth.net (Robert Middleswarth)
Date: Tue, 21 Aug 2012 22:10:02 -0400
Subject: [vdsm] Jenkins testing.
In-Reply-To: <502A1247.3060508@linux.vnet.ibm.com>
References: <5029E56A.8070909@middleswarth.net>
	<5029FCA3.90109@linux.vnet.ibm.com>
	<502A1247.3060508@linux.vnet.ibm.com>
Message-ID: <50343F7A.1070508@middleswarth.net>

On 08/14/2012 04:54 AM, Deepak C Shetty wrote:
> On 08/14/2012 12:52 PM, Deepak C Shetty wrote:
>> On 08/14/2012 11:13 AM, Robert Middleswarth wrote:
>>> After a few false starts it looks like we have per patch testing
>>> working on VDSM, oVirt-engine, oVirt-engine-sdk and
>>> oVirt-engine-cli.  There are 3 status a patch can get.  1) Success -
>>> Means the patch ran though the tests without issue.  2) Failure -
>>> Means the tests failed.  3) Aborted - Generally means the submitter
>>> is not in the whitelist and the tests were never run.  If you have
>>> any questions please feel free to ask.
>>>
>> So what is needed for the submitted to be in whitelist ?
>> I once for Success for few of my patches.. then got failure for some
>> other patch( maybe thats due to the false starts u had) and then for
>> the latest patch of mine, it says aborted.
>>
>> So not sure if i am in whitelist or not ?
>> If not, what do i need to do to be part of it ?
>> If yes, why did the build abort for my latest patch ?
>>
> Pls see http://gerrit.ovirt.org/#/c/6856/
> For patch1 it says build success, for patch 2, it says aborted.. why ?
>
All the abort means as a protective measure we don't run the tests 
unless we know the committer.  With that said you are now in the 
whitelist so it shouldn't be an issue in the feature.

-- 
Thanks
Robert Middleswarth
@rmiddle (twitter/Freenode IRC)
@RobertM (OFTC IRC)



From deepakcs at linux.vnet.ibm.com  Wed Aug 22 04:03:20 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Wed, 22 Aug 2012 09:33:20 +0530
Subject: [vdsm] Jenkins testing.
In-Reply-To: <50343F7A.1070508@middleswarth.net>
References: <5029E56A.8070909@middleswarth.net>
	<5029FCA3.90109@linux.vnet.ibm.com>
	<502A1247.3060508@linux.vnet.ibm.com>
	<50343F7A.1070508@middleswarth.net>
Message-ID: <50345A08.7020602@linux.vnet.ibm.com>

On 08/22/2012 07:40 AM, Robert Middleswarth wrote:
> On 08/14/2012 04:54 AM, Deepak C Shetty wrote:
>> On 08/14/2012 12:52 PM, Deepak C Shetty wrote:
>>> On 08/14/2012 11:13 AM, Robert Middleswarth wrote:
>>>> After a few false starts it looks like we have per patch testing
>>>> working on VDSM, oVirt-engine, oVirt-engine-sdk and
>>>> oVirt-engine-cli.  There are 3 status a patch can get.  1) Success -
>>>> Means the patch ran though the tests without issue.  2) Failure -
>>>> Means the tests failed.  3) Aborted - Generally means the submitter
>>>> is not in the whitelist and the tests were never run.  If you have
>>>> any questions please feel free to ask.
>>>>
>>> So what is needed for the submitted to be in whitelist ?
>>> I once for Success for few of my patches.. then got failure for some
>>> other patch( maybe thats due to the false starts u had) and then for
>>> the latest patch of mine, it says aborted.
>>>
>>> So not sure if i am in whitelist or not ?
>>> If not, what do i need to do to be part of it ?
>>> If yes, why did the build abort for my latest patch ?
>>>
>> Pls see http://gerrit.ovirt.org/#/c/6856/
>> For patch1 it says build success, for patch 2, it says aborted.. why ?
>>
> All the abort means as a protective measure we don't run the tests 
> unless we know the committer.  With that said you are now in the 
> whitelist so it shouldn't be an issue in the feature.
>
Thanks for putting me in the whitelist.
But it still doesn't clarify how patch 1 got build success and 
subsequent patch 2 had abort ?



From robert at middleswarth.net  Wed Aug 22 04:44:22 2012
From: robert at middleswarth.net (Robert Middleswarth)
Date: Wed, 22 Aug 2012 00:44:22 -0400
Subject: [vdsm] Jenkins testing.
In-Reply-To: <50345A08.7020602@linux.vnet.ibm.com>
References: <5029E56A.8070909@middleswarth.net>
	<5029FCA3.90109@linux.vnet.ibm.com>
	<502A1247.3060508@linux.vnet.ibm.com>
	<50343F7A.1070508@middleswarth.net>
	<50345A08.7020602@linux.vnet.ibm.com>
Message-ID: <503463A6.7070205@middleswarth.net>

On 08/22/2012 12:03 AM, Deepak C Shetty wrote:
> On 08/22/2012 07:40 AM, Robert Middleswarth wrote:
>> On 08/14/2012 04:54 AM, Deepak C Shetty wrote:
>>> On 08/14/2012 12:52 PM, Deepak C Shetty wrote:
>>>> On 08/14/2012 11:13 AM, Robert Middleswarth wrote:
>>>>> After a few false starts it looks like we have per patch testing
>>>>> working on VDSM, oVirt-engine, oVirt-engine-sdk and
>>>>> oVirt-engine-cli.  There are 3 status a patch can get.  1) Success -
>>>>> Means the patch ran though the tests without issue.  2) Failure -
>>>>> Means the tests failed.  3) Aborted - Generally means the submitter
>>>>> is not in the whitelist and the tests were never run.  If you have
>>>>> any questions please feel free to ask.
>>>>>
>>>> So what is needed for the submitted to be in whitelist ?
>>>> I once for Success for few of my patches.. then got failure for some
>>>> other patch( maybe thats due to the false starts u had) and then for
>>>> the latest patch of mine, it says aborted.
>>>>
>>>> So not sure if i am in whitelist or not ?
>>>> If not, what do i need to do to be part of it ?
>>>> If yes, why did the build abort for my latest patch ?
>>>>
>>> Pls see http://gerrit.ovirt.org/#/c/6856/
>>> For patch1 it says build success, for patch 2, it says aborted.. why ?
>>>
>> All the abort means as a protective measure we don't run the tests 
>> unless we know the committer.  With that said you are now in the 
>> whitelist so it shouldn't be an issue in the feature.
>>
> Thanks for putting me in the whitelist.
> But it still doesn't clarify how patch 1 got build success and 
> subsequent patch 2 had abort ?
>
Patch 1 happened in the small window well I was testing before the 
whitelist went live.  Patch 2 happened after the whitelist went live.  
Since you are now in the whitelist all new patches for you will run.

-- 
Thanks
Robert Middleswarth
@rmiddle (twitter/Freenode IRC)
@RobertM (OFTC IRC)



From garrett at redhat.com  Wed Aug 22 19:17:05 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Wed, 22 Aug 2012 21:17:05 +0200
Subject: "Download" page: new design
Message-ID: <50353031.6070503@redhat.com>

# Designing the download section #

In this email, I will explain the the mockup for the download page and 
the ideas that went into making the design.

First, a link to the mockup:
http://people.redhat.com/glesage/oVirt/website/mockup-1/download.html

Remember, this is a work in progress, and everything is open for 
discussion... and also subject to change.

As for this particular mockup, while the text is somewhat accurate, it 
mainly exists to convey concepts for this page.



## Background ##

Goal: To make it easy for anyone visiting oVirt.org to download and use 
oVirt.

By "use", I mean *both* trying oVirt on existing hardware as well as 
installing it to a hard drive.

To accomplish this, we need to:
* make it _extremely_ clear how to download oVirt
* provide a quick getting started guide to walk through a few steps
* inform the user what sort of hardware is expected



### Reasons to focus on an all-in-one "appliance" model ###

Having one favored, easy-to-use download allows us to:

* Eliminate the risks of things going wrong when a user sets up oVirt on 
their own system.
* Isolate oVirt from the distribution kernel and subsystem changes in 
distributions which may break functionality.
* Provide the latest and greatest features to oVirt users independent of 
waiting for distributions to play catch-up.
* Test a known stack of software to ensure that oVirt works as intended.


Possible downsides of focusing on this all-in-one approach:

1) "It doesn't run on _my_ distribution"

Answer: oVirt + a very basic version of Fedora is a virtualization 
platform that is just enough to run hosts inside of. Sitting on top of a 
distro (even a very stripped-down one) and the fact that it's running on 
top of the Linux kernel are both basically implementation details. Any 
operating system, including all the different flavors of Linux, can 
easily run inside ? oVirt plays nicely with whatever anyone wants to run.

Furthermore, it doesn't make sense to run a mail server, web server, or 
any other service parallel to oVirt. Those services should be running 
inside of hosts running on top of oVirt.

As a result, it doesn't matter what distribution oVirt runs on top of.


2) The all-in-one image isn't development-focused (but that's okay)

Answer: We need a user-focused website, especially for the download 
page. It should be as easy as possible to download and set up oVirt. 
Right now, we're assuming that people have some sort of system knowledge 
of maintaining a Linux server. The download page, for this reason, 
should not include how to build from source. (That belongs on the 
website, sure, but in whatever we call the "develop" section... not in 
"download")

It will still obviously be possible to develop for and run oVirt on any 
distribution of choice. It shouldn't be the default (for reasons 
outlined above), but it should be possible.



## Design of the page ##

At the very top, you see a summary, and a big button which makes it 
obvious that oVirt can be downloaded. Clicking the button will 
immediately download the ISO. There's a size listed, so people know how 
long it will take (roughly), and a hash (either MD5 or SHA1, but not 
both) so that users can verify the download was successful.

Next, the page is split into two columns. As "what should I do with this 
file?" is so very important, it has a prominent position on the page. At 
the end, there's a paragraph about consulting documentation for more 
information, as well as some quick links to a few commonly used 
documents (in this case, I think it would be neat to see how people are 
using oVirt, for the common use cases).

Hardware requirements / suggestions are very important, so they're at 
the top too.

Regardless of having an easy-to-install image, many people will want to 
install oVirt on their distribution of choice. We do want to make things 
as easy as possible, but we should provide a path for advanced users to 
install oVirt on Debian, Fedora (existing installation), openSUSE, 
Ubuntu, and other distributions. Therefore, I made an "Alternate 
installation methods" section on the page.

Provided we get permission for using the logos in this way (and I'm 
pretty sure we can), it provides a simple, clear approach for others who 
want to download oVirt for their existing machines.


## In closing ##

Thanks for taking the time to read this! I'm looking forward to what you 
have to say about the ideas expressed in the mockup.

Garrett


From dneary at redhat.com  Fri Aug 24 15:19:48 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 24 Aug 2012 17:19:48 +0200
Subject: "Download" page: new design
In-Reply-To: <50353031.6070503@redhat.com>
References: <50353031.6070503@redhat.com>
Message-ID: <50379B94.6020906@redhat.com>

Hi Garrett,

On 08/22/2012 09:17 PM, Garrett LeSage wrote:
> First, a link to the mockup:
> http://people.redhat.com/glesage/oVirt/website/mockup-1/download.html

I think it looks nice! It does raise a few questions, though.

<snip>

> ### Reasons to focus on an all-in-one "appliance" model ###
>
> Having one favored, easy-to-use download allows us to:
>
> * Eliminate the risks of things going wrong when a user sets up oVirt on
> their own system.
> * Isolate oVirt from the distribution kernel and subsystem changes in
> distributions which may break functionality.
> * Provide the latest and greatest features to oVirt users independent of
> waiting for distributions to play catch-up.
> * Test a known stack of software to ensure that oVirt works as intended.

In the mock-up there's a download link for "oVirt live image" - you 
indicate here it's the all-in-one version, downloadable as a runnable 
ISO liveCD. You also suggest that it should be possible to install oVirt 
from that image.

My question is: do we have this? And if not, how much engineering work 
would be required to create an image which allows you to run all-in-one 
from a LiveCD, and also enable you to install both Engine and Node? And 
how would that work? Specifically, how will it work with storage 
domains, etc?

I realise you might not have the answers - but I don't think we have an 
all-in-one DVD/CD image right now, never mind one which will handle all 
of the finnicky things you need to do when installing an engine and 
setting up nodes.

In any case, the design looks great! I just want to make sure we're 
designing something we can deliver.

Thanks,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13




From jbrooks at redhat.com  Fri Aug 24 15:57:57 2012
From: jbrooks at redhat.com (Jason Brooks)
Date: Fri, 24 Aug 2012 08:57:57 -0700
Subject: "Download" page: new design
In-Reply-To: <50379B94.6020906@redhat.com>
References: <50353031.6070503@redhat.com> <50379B94.6020906@redhat.com>
Message-ID: <5037A485.2050705@redhat.com>

On 08/24/2012 08:19 AM, Dave Neary wrote:
> Hi Garrett,
>
> On 08/22/2012 09:17 PM, Garrett LeSage wrote:
>> First, a link to the mockup:
>> http://people.redhat.com/glesage/oVirt/website/mockup-1/download.html
>
> I think it looks nice! It does raise a few questions, though.

+1 this looks great

>
> <snip>
>
>> ### Reasons to focus on an all-in-one "appliance" model ###
>>
>> Having one favored, easy-to-use download allows us to:
>>
>> * Eliminate the risks of things going wrong when a user sets up oVirt on
>> their own system.
>> * Isolate oVirt from the distribution kernel and subsystem changes in
>> distributions which may break functionality.
>> * Provide the latest and greatest features to oVirt users independent of
>> waiting for distributions to play catch-up.
>> * Test a known stack of software to ensure that oVirt works as intended.
>
> In the mock-up there's a download link for "oVirt live image" - you
> indicate here it's the all-in-one version, downloadable as a runnable
> ISO liveCD. You also suggest that it should be possible to install oVirt
> from that image.
>
> My question is: do we have this? And if not, how much engineering work
> would be required to create an image which allows you to run all-in-one
> from a LiveCD, and also enable you to install both Engine and Node? And
> how would that work? Specifically, how will it work with storage
> domains, etc?

I've played around with creating an all in one live image. All the 
needed packages on a livecd image, I can run engine-setup from the live 
environment, and it looks like I can configure everything. I don't have 
it all nailed down yet, and I'm finding that after making a certain 
number of changes, packages downloaded, etc., in the live environment, 
I'm running out of space. I'm not sure if there's a way to increase the 
available space, like, if you boost the RAM, will the livecd 
automatically provide you with more space?

After I do a bit more fiddling, I'll blog about it. Combined with the 
vdsm-faqemu package and a couple config file tweaks, you would be able 
to run it all in a VM (do everything, all the setup and storage config, 
etc., just short of actually running a VM)

>
> I realise you might not have the answers - but I don't think we have an
> all-in-one DVD/CD image right now, never mind one which will handle all
> of the finnicky things you need to do when installing an engine and
> setting up nodes.
>
> In any case, the design looks great!

Again, +1 -- I'm stoked about these new designs.

Jason


I just want to make sure we're
> designing something we can deliver.
>
> Thanks,
> Dave.
>


-- 

@jasonbrooks


From garrett at redhat.com  Fri Aug 24 16:21:14 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Fri, 24 Aug 2012 18:21:14 +0200
Subject: "Download" page: new design
In-Reply-To: <5037A485.2050705@redhat.com>
References: <50353031.6070503@redhat.com> <50379B94.6020906@redhat.com>
	<5037A485.2050705@redhat.com>
Message-ID: <5037A9FA.2060409@redhat.com>

Thanks! I'm glad you like it, and that you and Dave both noticed the 
implications of the design for the ?Download? page.

For oVirt to be really successful, it needs to be super-simple for 
installation and set up. We have to be user-focused, from one end to 
the other ? this includes the website, delivery method (one ISO for 
CDs/USB sticks), and installation (as simple as possible). Of course, 
oVirt itself, when it's up and running also needs to be usable too, but 
I think the RHEV folks put some time into that already, so I'm 
concentrating on the rest for now.

If we can't deliver a really polished all-in-one, installable ISO, then 
we should spend effort to try to make it happen soon. (And, if it's not 
feasible to do this in the immediate future, then I can also work on an 
interim design that bridges the gap a bit too.)

I'm really glad to hear that it sounds like this will be possible.

Garrett


From dneary at redhat.com  Fri Aug 24 16:29:08 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 24 Aug 2012 18:29:08 +0200
Subject: Mailing list scope proposal
In-Reply-To: <5034FA0F.5030107@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com>
Message-ID: <5037ABD4.2030103@redhat.com>

Hi all,

Over on infra@, we were having a discussion about whether it was best 
policy to subscribe lists to each other to help reduce the amount of 
cross-posting going on in the project (I for one find it a bit annoying 
to get 4 copies of a single email).

The answer to the technical question is that it's not, there are lots of 
good reasons to avoid subscribing lists to another mailing list, but 
that led to a discussion about whether we could tighten the scope of 
each of the lists, and reduce cross-posting that way, by making it 
clearer where people should be subscribed/where a topic is on- and 
off-topic.

So - here's my suggestion for that (and as per my suggestion, let's have 
this discussion here, and when we reach a consensus ask for the opinion 
of the board):

users@ - User issues - help, troubleshooting, configuration issues, 
sharing experiences, etc. Users at will have mostly technical users of 
oVirt or people in the process of installing it, plus some of the oVirt 
developers (but we'd like to encourage our more technical users to 
answer questions). The list could also serve as a gateway drug to 
contribution, and we should ask here for help for initiatives which do 
not require intimate knowledge of the code base - VDSM hooks, wiki 
editing, documentation drives, etc.

arch@ - rename to developers@ - This will be the key developer mailing 
list for oVirt, the place where we discuss project-wide changes, the 
roadmap for future versions, release planning, where people can perhaps 
propose patches for discussion, and where any issue affecting the 
developer governance of the project will be discussed.

board@ - Issues related to the non-technical governance of the project 
(ie things which require board approval). In the case of the website 
redesign, for example, a final design, discussed beforehand on 
developers@, would be submitted to board@ for approval.

infra@ - issues related to the management of oVirt infrastructure - web 
services, developer infrastructure, etc.

vdsm-devel, node-devel, engine-devel, *-devel: Low-traffic lists related 
to the specific implementation issues of the individual components.

In this schema, if you want to talk to the developers, you email 
developers@ - if you have a suggestion specific to vdsm, you might 
contact developers@ or vdsm-devel@ - but not both. Any mailing list 
thread to vdsm-devel@ which requires feedback from the maintainers of 
other projects should move to developers@ once that's ascertained.

How does that sound? Does anyone have other/better suggestions?

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From dneary at redhat.com  Fri Aug 24 16:46:40 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 24 Aug 2012 18:46:40 +0200
Subject: new design: request for comments
In-Reply-To: <502D2B16.6090401@redhat.com>
References: <502D2B16.6090401@redhat.com>
Message-ID: <5037AFF0.4000801@redhat.com>

Hi Garrett,

I love the new design - it's clean, and addresses most of the reasons 
we've identified why people might come to the oVirt website. The sitemap 
details that even better, and I think the latest version is very good.

On 08/16/2012 07:17 PM, Garrett LeSage wrote:
> The website mockup is at:
> http://people.redhat.com/glesage/oVirt/website/mockup-1/
> (This is simply a static PNG exported from Inkscape, wrapped in a very
> simple HTML page. Therefore, don't expect it to scale with your browser,
> have selectable text, etc.)
>
> The mockup has many different sections and updates, and I will explain
> each change, as well as the thought process that went into each, below.

I agree with Mike that it's a bit text heavy, but that's something we 
can fix pretty easily. The key bits are the top of the front page (great 
call to action), and the way we address the key use-cases for a website:

* Find out more about oVirt
* Get and try out oVirt
* Get help when I have a problem
* Tell the developers about a problem/suggest an improvement (broadly, 
"get involved")
* Learn about the code and architecture/build development 
versions/propose a patch (broadly: "Develop")


> = Site structure =
>
> A revised site structure is hinted at in the front page mockup. You can
> see this reflected in the top navigation. I did some overall
> categorization, strongly influenced by Dave Neary's pre-existing work on
> the topic.
>
> You can see a proposed sitemap here:
> http://people.redhat.com/glesage/oVirt/website/ovirt-sitemap.txt
>
> This is a general grouping of types of content, not necessarily a view
> of the top-level page, or of sub-pages. In some cases, these items would
> be sub-level pages, in others, they would be part of the navigation page.
>
> The documentation page would highlight the best documentation available,
> regardless of format - e.g. wiki, blog posts, etc. - and also have a
> prominent link to the wiki. Other sub-pages may also link to the wiki,
> if there is pertinent information (such as live docs for developers,
> linked to from the develop section).

As Livnat said, I think that Download is an important word to have 
there. I think we can do better than "Documentation" though - that's 
pretty broad, how about a "Get help" header, which points to user 
documentation, a FAQ, and points people to the IRC channel and users@ 
mailing list for in-person help?

I think "Developers" is good enough - developers know what that means, 
and we can add links to developer documentation, source code, patch 
review tools, Jenkins, etc there.

Personally, I also think that "Community" isn't very clickable - I'd 
prefer to have some kind of call to action: "Get involved" or "Talk to 
the community" or something... I have no really good ideas, because I 
can imagine (say) someone who wants to talk to the community to suggest 
a feature, but who doesn't want to get involved as such.

That section could point to mailing lists, how to edit a wiki page, help 
work in the bug tracker, and various information about future versions, 
release and infrastructure management, how to propose a feature, joining 
devel mailing lists, etc.

I imagine that we could end up with a "Documentation" section for each 
of users, developers and non-developer contributors.

> = Front-page sections =
>
> The order of the front-page sections is important too. A goal with this
> design was to:
> 1) Introduce people to oVirt, with a simple explanation
> 2) Let people know right upfront that it's an active project (release
> blurb)
> 3) Detail some of the most important features
> 4) Make it clear that it's a community project
> 5) Provide timely news & a way to easily get more info
> 6) Publish information on upcoming oVirt-related events (currently, in the
> mockup, there's filler text for the time being)
>
> Items #5 & #6 should both have a way to subscribe so that someone could
> access this information without visiting oVirt.org. Twitter solves the
> news component for us; we have to make sure the calendar is able to be
> subscribed to as well.

I think we can show some more activity (or different) on the front page 
too - I don't know if we have active bloggers among the team, but 
certainly we could feed blogs as well as Twitter, G+, Facebook, etc. 
content into an RSS aggregator, in addition we also have all of the 
activity (actual work!) going on in the projects - is there a way we can 
use Bugzilla, Gerrit, Jenkins, git (or the commits list) and wiki recent 
changes to populate an activity view?

> Thanks for reading all of this! I'm looking forward to all
> conversations, especially if it's constructive (regardless of a
> positive, negative, or neutral slant).

Thank you garrett! I appreciate the effort you've put into this, and if 
we put it as-is on ovirt.org now, I'd be happy. There's some room for 
improvement, but it is a great start.

Thanks!
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13




From garrett at redhat.com  Fri Aug 24 17:19:31 2012
From: garrett at redhat.com (Garrett LeSage)
Date: Fri, 24 Aug 2012 19:19:31 +0200
Subject: vacation next week
Message-ID: <5037B7A3.2070105@redhat.com>

Hi everyone,

I will be on vacation next week.

You can expect more designs the week following. (There are a few 
*almost* ready-to-post.)

Please feel free to send replies to the design emails, including the 
design for the new download page (and proposed all-in-one delivery 
method). I'll read and respond when I return.

Thanks!
Garrett


From lpeer at redhat.com  Sun Aug 26 07:07:16 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 26 Aug 2012 10:07:16 +0300
Subject: Mailing list scope proposal
In-Reply-To: <5037ABD4.2030103@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com> <5037ABD4.2030103@redhat.com>
Message-ID: <5039CB24.6000704@redhat.com>

On 24/08/12 19:29, Dave Neary wrote:
> Hi all,
> 
> Over on infra@, we were having a discussion about whether it was best
> policy to subscribe lists to each other to help reduce the amount of
> cross-posting going on in the project (I for one find it a bit annoying
> to get 4 copies of a single email).
> 
> The answer to the technical question is that it's not, there are lots of
> good reasons to avoid subscribing lists to another mailing list, but
> that led to a discussion about whether we could tighten the scope of
> each of the lists, and reduce cross-posting that way, by making it
> clearer where people should be subscribed/where a topic is on- and
> off-topic.
> 
> So - here's my suggestion for that (and as per my suggestion, let's have
> this discussion here, and when we reach a consensus ask for the opinion
> of the board):
> 
> users@ - User issues - help, troubleshooting, configuration issues,
> sharing experiences, etc. Users at will have mostly technical users of
> oVirt or people in the process of installing it, plus some of the oVirt
> developers (but we'd like to encourage our more technical users to
> answer questions). The list could also serve as a gateway drug to
> contribution, and we should ask here for help for initiatives which do
> not require intimate knowledge of the code base - VDSM hooks, wiki
> editing, documentation drives, etc.
> 
> arch@ - rename to developers@ - This will be the key developer mailing
> list for oVirt, the place where we discuss project-wide changes, the
> roadmap for future versions, release planning, where people can perhaps
> propose patches for discussion, and where any issue affecting the
> developer governance of the project will be discussed.
> 
> board@ - Issues related to the non-technical governance of the project
> (ie things which require board approval). In the case of the website
> redesign, for example, a final design, discussed beforehand on
> developers@, would be submitted to board@ for approval.
> 
> infra@ - issues related to the management of oVirt infrastructure - web
> services, developer infrastructure, etc.
> 
> vdsm-devel, node-devel, engine-devel, *-devel: Low-traffic lists related
> to the specific implementation issues of the individual components.
> 
> In this schema, if you want to talk to the developers, you email
> developers@ - if you have a suggestion specific to vdsm, you might
> contact developers@ or vdsm-devel@ - but not both. Any mailing list
> thread to vdsm-devel@ which requires feedback from the maintainers of
> other projects should move to developers@ once that's ascertained.
> 
> How does that sound? Does anyone have other/better suggestions?
> 

+1, I think this is a good proposal.
I would try to avoid discussing patches on the developers list and try
to keep it more high level like design discussions etc.

Livnat



> Cheers,
> Dave.
> 



From danken at redhat.com  Mon Aug 27 11:20:46 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 27 Aug 2012 14:20:46 +0300
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <1971319159.2475836.1345575556171.JavaMail.root@redhat.com>
References: <222981603.12287075.1345575268877.JavaMail.root@redhat.com>
	<1971319159.2475836.1345575556171.JavaMail.root@redhat.com>
Message-ID: <20120827112046.GE22256@redhat.com>

On Tue, Aug 21, 2012 at 02:59:16PM -0400, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
> > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Tuesday, August 21, 2012 9:54:28 PM
> > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Tuesday, August 21, 2012 11:36:54 AM
> > > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Tuesday, August 21, 2012 2:36:13 PM
> > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > templates.
> > > > 
> > > > ----- Original Message -----
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > Cc: arch at ovirt.org, "Dan Kenigsberg" <danken at redhat.com>
> > > > > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > templates.
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > > Cc: arch at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>,
> > > > > > > > "Igor
> > > > > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > > templates.
> > > > > > > 
> > > > > > > <snip>
> > > > > > > 
> > > > > > > > > 
> > > > > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > > > > 
> > > > > > > > I think it's fine, though I find the "BZ#" string quite
> > > > > > > > redundant
> > > > > > > > when
> > > > > > > > it appears after "Bug-Id: "
> > > > > > > > 
> > > > > > > 
> > > > > > > The BZ# was added (or kept) in order to allow <some>
> > > > > > > flexibility
> > > > > > > when
> > > > > > > referencing to different bug tracking systems (multiple
> > > > > > > name-spaces). For example, we may accept conventions of LP#
> > > > > > > for
> > > > > > > ubuntu launchpad.
> > > > > > 
> > > > > > Why not simply use a bug link, then?
> > > > > 
> > > > > It is long... I think the bug description is more important,
> > > > > providing both URL and description will make way too long.
> > > > 
> > > > Bug titles aren't constant. Also they provide little value as
> > > > most
> > > > of
> > > > the time the bug decription and reproduction steps are much more
> > > > informative than what the title says.
> > > > 
> > > > Also in the engine we have lived a long time with bug URL in the
> > > > comment and it was very convenient.
> > > >
> > > 
> > > I agree, i find bug url much more convenient than bug title
> > +1, most of the time the bug titles don't actually even point to what
> > the problem actually was but rather what the reporter thought it
> > was.

Ok. Before this thread finds it way to the land of undecided
discussions, let's sum it up:

  Bug-Id: https://bugzilla.redhat.com/888890

The commit message should be explicit enough to describe the nature of
the fixed bug.

Dan.


From dfediuck at redhat.com  Mon Aug 27 11:46:31 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 27 Aug 2012 07:46:31 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <20120827112046.GE22256@redhat.com>
Message-ID: <576909443.1352417.1346067991449.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Federico Simoncelli" <fsimonce at redhat.com>
> Cc: arch at ovirt.org
> Sent: Monday, August 27, 2012 2:20:46 PM
> Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> 
> On Tue, Aug 21, 2012 at 02:59:16PM -0400, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > > Cc: arch at ovirt.org
> > > Sent: Tuesday, August 21, 2012 9:54:28 PM
> > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > templates.
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Tuesday, August 21, 2012 11:36:54 AM
> > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > templates.
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > Cc: arch at ovirt.org
> > > > > Sent: Tuesday, August 21, 2012 2:36:13 PM
> > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > templates.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > Cc: arch at ovirt.org, "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > templates.
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > > > Cc: arch at ovirt.org, "Alon Bar-Lev"
> > > > > > > > > <alonbl at redhat.com>,
> > > > > > > > > "Igor
> > > > > > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm
> > > > > > > > > commit
> > > > > > > > > templates.
> > > > > > > > 
> > > > > > > > <snip>
> > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > > > > > 
> > > > > > > > > I think it's fine, though I find the "BZ#" string
> > > > > > > > > quite
> > > > > > > > > redundant
> > > > > > > > > when
> > > > > > > > > it appears after "Bug-Id: "
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > The BZ# was added (or kept) in order to allow <some>
> > > > > > > > flexibility
> > > > > > > > when
> > > > > > > > referencing to different bug tracking systems (multiple
> > > > > > > > name-spaces). For example, we may accept conventions of
> > > > > > > > LP#
> > > > > > > > for
> > > > > > > > ubuntu launchpad.
> > > > > > > 
> > > > > > > Why not simply use a bug link, then?
> > > > > > 
> > > > > > It is long... I think the bug description is more
> > > > > > important,
> > > > > > providing both URL and description will make way too long.
> > > > > 
> > > > > Bug titles aren't constant. Also they provide little value as
> > > > > most
> > > > > of
> > > > > the time the bug decription and reproduction steps are much
> > > > > more
> > > > > informative than what the title says.
> > > > > 
> > > > > Also in the engine we have lived a long time with bug URL in
> > > > > the
> > > > > comment and it was very convenient.
> > > > >
> > > > 
> > > > I agree, i find bug url much more convenient than bug title
> > > +1, most of the time the bug titles don't actually even point to
> > > what
> > > the problem actually was but rather what the reporter thought it
> > > was.
> 
> Ok. Before this thread finds it way to the land of undecided
> discussions, let's sum it up:
> 
>   Bug-Id: https://bugzilla.redhat.com/888890
> 
> The commit message should be explicit enough to describe the nature
> of
> the fixed bug.
> 
> Dan.

+1.
Looks very good, as indeed BZ $SUBJECT does not always reflect the real issue.

If anyone objects, please respond.


From mkolesni at redhat.com  Mon Aug 27 11:53:33 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 27 Aug 2012 07:53:33 -0400 (EDT)
Subject: Unifying (parts of) engine and vdsm commit templates.
In-Reply-To: <576909443.1352417.1346067991449.JavaMail.root@redhat.com>
Message-ID: <45855113.12576701.1346068413495.JavaMail.root@redhat.com>

----- Original Message -----
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>, "Federico Simoncelli"
> > <fsimonce at redhat.com>
> > Cc: arch at ovirt.org
> > Sent: Monday, August 27, 2012 2:20:46 PM
> > Subject: Re: Unifying (parts of) engine and vdsm commit templates.
> > 
> > On Tue, Aug 21, 2012 at 02:59:16PM -0400, Alon Bar-Lev wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Tuesday, August 21, 2012 9:54:28 PM
> > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > templates.
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > Cc: arch at ovirt.org
> > > > > Sent: Tuesday, August 21, 2012 11:36:54 AM
> > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > templates.
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > Cc: arch at ovirt.org
> > > > > > Sent: Tuesday, August 21, 2012 2:36:13 PM
> > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > templates.
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > > Cc: arch at ovirt.org, "Dan Kenigsberg"
> > > > > > > > <danken at redhat.com>
> > > > > > > > Sent: Tuesday, August 21, 2012 2:27:05 PM
> > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm commit
> > > > > > > > templates.
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > > > > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > > > > Cc: arch at ovirt.org, "Alon Bar-Lev"
> > > > > > > > > > <alonbl at redhat.com>,
> > > > > > > > > > "Igor
> > > > > > > > > > Lvovsky" <ilvovsky at redhat.com>
> > > > > > > > > > Sent: Tuesday, August 21, 2012 1:49:18 PM
> > > > > > > > > > Subject: Re: Unifying (parts of) engine and vdsm
> > > > > > > > > > commit
> > > > > > > > > > templates.
> > > > > > > > > 
> > > > > > > > > <snip>
> > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > >     Bug-Id: BZ#888888 dummy bz1
> > > > > > > > > > >     Bug-Id: BZ#888889 dummy bz2
> > > > > > > > > > >     Bug-Id: BZ#888890 dummy bz2
> > > > > > > > > > 
> > > > > > > > > > I think it's fine, though I find the "BZ#" string
> > > > > > > > > > quite
> > > > > > > > > > redundant
> > > > > > > > > > when
> > > > > > > > > > it appears after "Bug-Id: "
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The BZ# was added (or kept) in order to allow <some>
> > > > > > > > > flexibility
> > > > > > > > > when
> > > > > > > > > referencing to different bug tracking systems
> > > > > > > > > (multiple
> > > > > > > > > name-spaces). For example, we may accept conventions
> > > > > > > > > of
> > > > > > > > > LP#
> > > > > > > > > for
> > > > > > > > > ubuntu launchpad.
> > > > > > > > 
> > > > > > > > Why not simply use a bug link, then?
> > > > > > > 
> > > > > > > It is long... I think the bug description is more
> > > > > > > important,
> > > > > > > providing both URL and description will make way too
> > > > > > > long.
> > > > > > 
> > > > > > Bug titles aren't constant. Also they provide little value
> > > > > > as
> > > > > > most
> > > > > > of
> > > > > > the time the bug decription and reproduction steps are much
> > > > > > more
> > > > > > informative than what the title says.
> > > > > > 
> > > > > > Also in the engine we have lived a long time with bug URL
> > > > > > in
> > > > > > the
> > > > > > comment and it was very convenient.
> > > > > >
> > > > > 
> > > > > I agree, i find bug url much more convenient than bug title
> > > > +1, most of the time the bug titles don't actually even point
> > > > to
> > > > what
> > > > the problem actually was but rather what the reporter thought
> > > > it
> > > > was.
> > 
> > Ok. Before this thread finds it way to the land of undecided
> > discussions, let's sum it up:
> > 
> >   Bug-Id: https://bugzilla.redhat.com/888890
> > 
> > The commit message should be explicit enough to describe the nature
> > of
> > the fixed bug.
> > 
> > Dan.
> 
> +1.
> Looks very good, as indeed BZ $SUBJECT does not always reflect the
> real issue.

+1

Although maybe Bug-Url key is more appropriate ;)

> 
> If anyone objects, please respond.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From kwade at redhat.com  Mon Aug 27 20:31:47 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Mon, 27 Aug 2012 13:31:47 -0700
Subject: Mailing list scope proposal
In-Reply-To: <5039CB24.6000704@redhat.com>
References: <502AB424.3010709@redhat.com> <50328DA8.10206@redhat.com>
	<5034FA0F.5030107@redhat.com> <5037ABD4.2030103@redhat.com>
	<5039CB24.6000704@redhat.com>
Message-ID: <503BD933.3020501@redhat.com>

On 08/26/2012 12:07 AM, Livnat Peer wrote:
> On 24/08/12 19:29, Dave Neary wrote:
>> Hi all,
>>
>> Over on infra@, we were having a discussion about whether it was best
>> policy to subscribe lists to each other to help reduce the amount of
>> cross-posting going on in the project (I for one find it a bit annoying
>> to get 4 copies of a single email).
>>
>> The answer to the technical question is that it's not, there are lots of
>> good reasons to avoid subscribing lists to another mailing list, but
>> that led to a discussion about whether we could tighten the scope of
>> each of the lists, and reduce cross-posting that way, by making it
>> clearer where people should be subscribed/where a topic is on- and
>> off-topic.
>>
>> So - here's my suggestion for that (and as per my suggestion, let's have
>> this discussion here, and when we reach a consensus ask for the opinion
>> of the board):
>>
>> users@ - User issues - help, troubleshooting, configuration issues,
>> sharing experiences, etc. Users at will have mostly technical users of
>> oVirt or people in the process of installing it, plus some of the oVirt
>> developers (but we'd like to encourage our more technical users to
>> answer questions). The list could also serve as a gateway drug to
>> contribution, and we should ask here for help for initiatives which do
>> not require intimate knowledge of the code base - VDSM hooks, wiki
>> editing, documentation drives, etc.
>>
>> arch@ - rename to developers@ - This will be the key developer mailing
>> list for oVirt, the place where we discuss project-wide changes, the
>> roadmap for future versions, release planning, where people can perhaps
>> propose patches for discussion, and where any issue affecting the
>> developer governance of the project will be discussed.
>>
>> board@ - Issues related to the non-technical governance of the project
>> (ie things which require board approval). In the case of the website
>> redesign, for example, a final design, discussed beforehand on
>> developers@, would be submitted to board@ for approval.
>>
>> infra@ - issues related to the management of oVirt infrastructure - web
>> services, developer infrastructure, etc.
>>
>> vdsm-devel, node-devel, engine-devel, *-devel: Low-traffic lists related
>> to the specific implementation issues of the individual components.
>>
>> In this schema, if you want to talk to the developers, you email
>> developers@ - if you have a suggestion specific to vdsm, you might
>> contact developers@ or vdsm-devel@ - but not both. Any mailing list
>> thread to vdsm-devel@ which requires feedback from the maintainers of
>> other projects should move to developers@ once that's ascertained.
>>
>> How does that sound? Does anyone have other/better suggestions?
>>
> 
> +1, I think this is a good proposal.
> I would try to avoid discussing patches on the developers list and try
> to keep it more high level like design discussions etc.

+1 Yes, that makes sense - keep patch discussions in the project, and
keep discussions that affect oVirt overall on the developers list.

Also, I'm +1 to renaming this list; I reckon arch@ is confusing, dev@ or
developers@ is a more common Big Main List name.

- Karsten

> Livnat
> 
> 
> 
>> Cheers,
>> Dave.
>>
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120827/3ccddc50/attachment.sig>

From smizrahi at redhat.com  Thu Aug 30 21:19:46 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 30 Aug 2012 17:19:46 -0400 (EDT)
Subject: [RFC] Implied UUIDs in API
In-Reply-To: <1700817155.15552304.1346353899259.JavaMail.root@redhat.com>
Message-ID: <213167067.15587136.1346361586741.JavaMail.root@redhat.com>

Hi, in the API a lot of IDs get passed around are UUIDs.
The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you.
I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs.
It's another restriction we can remove from the interface simplifying the code and the interface.

Just to be clear I'm not saying that we should stop using UUIDs.
For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value.
If for some reason we choose to change the format of task IDs. There will be no need to change the interface.

The same goes for VM IDs. Currently the engine uses UUIDs but there is no reason for VDSM to enforce this and limit the engine from ever changing it in the future and using other string values.


From berrange at redhat.com  Thu Aug 30 21:23:54 2012
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 30 Aug 2012 14:23:54 -0700
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <213167067.15587136.1346361586741.JavaMail.root@redhat.com>
References: <1700817155.15552304.1346353899259.JavaMail.root@redhat.com>
	<213167067.15587136.1346361586741.JavaMail.root@redhat.com>
Message-ID: <20120830212354.GB3297@redhat.com>

On Thu, Aug 30, 2012 at 05:19:46PM -0400, Saggi Mizrahi wrote:
> Hi, in the API a lot of IDs get passed around are UUIDs.
> The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you.
> I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs.
> It's another restriction we can remove from the interface simplifying the code and the interface.
> 
> Just to be clear I'm not saying that we should stop using UUIDs.
> For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value.
> If for some reason we choose to change the format of task IDs. There will be no need to change the interface.

IMHO it is worth having strict UUIDs in preference to arbitrary strings,
since their fixed size lets you deal with them more efficiently and
predictably.

> The same goes for VM IDs. Currently the engine uses UUIDs but there
> is no reason for VDSM to enforce this and limit the engine from ever
> changing it in the future and using other string values.

I'm not sure this is correct. IIUC the vmId value is used set the <uuid>
element in the libvirt VM XML configuration, and libvirt will strictly
validate for a well formed UUID string.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


From alonbl at redhat.com  Thu Aug 30 21:33:24 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 30 Aug 2012 17:33:24 -0400 (EDT)
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <213167067.15587136.1346361586741.JavaMail.root@redhat.com>
Message-ID: <1397620231.4045595.1346362404271.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "arch" <arch at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Friday, August 31, 2012 12:19:46 AM
> Subject: [vdsm] [RFC] Implied UUIDs in API
> 
> Hi, in the API a lot of IDs get passed around are UUIDs.
> The point is that as long as you are not the entity generating the
> UUIDs the fact that these are UUIDs have no real significance to
> you.
> I suggest removing the validation of UUIDs from the receiving end.
> There is no real reason to make sure these are real UUIDs.
> It's another restriction we can remove from the interface simplifying
> the code and the interface.
> 
> Just to be clear I'm not saying that we should stop using UUIDs.
> For example, vdsm will keep generating task IDs as UUIDs. But the
> documentation will state that it could be *any* string value.
> If for some reason we choose to change the format of task IDs. There
> will be no need to change the interface.
> 
> The same goes for VM IDs. Currently the engine uses UUIDs but there
> is no reason for VDSM to enforce this and limit the engine from ever
> changing it in the future and using other string values.

I agree that UUID is just a method of generating unique strings, there is no reason to validate the value nor the format.

Thanks,
Alon.


From iheim at redhat.com  Fri Aug 31 09:23:38 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 31 Aug 2012 12:23:38 +0300
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <1397620231.4045595.1346362404271.JavaMail.root@redhat.com>
References: <1397620231.4045595.1346362404271.JavaMail.root@redhat.com>
Message-ID: <5040829A.8060904@redhat.com>

On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
>> To: "arch" <arch at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
>> Sent: Friday, August 31, 2012 12:19:46 AM
>> Subject: [vdsm] [RFC] Implied UUIDs in API
>>
>> Hi, in the API a lot of IDs get passed around are UUIDs.
>> The point is that as long as you are not the entity generating the
>> UUIDs the fact that these are UUIDs have no real significance to
>> you.
>> I suggest removing the validation of UUIDs from the receiving end.
>> There is no real reason to make sure these are real UUIDs.
>> It's another restriction we can remove from the interface simplifying
>> the code and the interface.
>>
>> Just to be clear I'm not saying that we should stop using UUIDs.
>> For example, vdsm will keep generating task IDs as UUIDs. But the
>> documentation will state that it could be *any* string value.
>> If for some reason we choose to change the format of task IDs. There
>> will be no need to change the interface.
>>
>> The same goes for VM IDs. Currently the engine uses UUIDs but there
>> is no reason for VDSM to enforce this and limit the engine from ever
>> changing it in the future and using other string values.
>
> I agree that UUID is just a method of generating unique strings, there is no reason to validate the value nor the format.

I'm with daniel on this one - knowing a field is a uuid makes it easier 
to deal with in the db and code around it compared to a string (stored 
binary instead of string representation, etc.)


From alonbl at redhat.com  Fri Aug 31 09:27:32 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 31 Aug 2012 05:27:32 -0400 (EDT)
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <5040829A.8060904@redhat.com>
Message-ID: <1992507157.4126840.1346405252832.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Friday, August 31, 2012 12:23:38 PM
> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> 
> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> >> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> >> <vdsm-devel at lists.fedorahosted.org>
> >> Sent: Friday, August 31, 2012 12:19:46 AM
> >> Subject: [vdsm] [RFC] Implied UUIDs in API
> >>
> >> Hi, in the API a lot of IDs get passed around are UUIDs.
> >> The point is that as long as you are not the entity generating the
> >> UUIDs the fact that these are UUIDs have no real significance to
> >> you.
> >> I suggest removing the validation of UUIDs from the receiving end.
> >> There is no real reason to make sure these are real UUIDs.
> >> It's another restriction we can remove from the interface
> >> simplifying
> >> the code and the interface.
> >>
> >> Just to be clear I'm not saying that we should stop using UUIDs.
> >> For example, vdsm will keep generating task IDs as UUIDs. But the
> >> documentation will state that it could be *any* string value.
> >> If for some reason we choose to change the format of task IDs.
> >> There
> >> will be no need to change the interface.
> >>
> >> The same goes for VM IDs. Currently the engine uses UUIDs but
> >> there
> >> is no reason for VDSM to enforce this and limit the engine from
> >> ever
> >> changing it in the future and using other string values.
> >
> > I agree that UUID is just a method of generating unique strings,
> > there is no reason to validate the value nor the format.
> 
> I'm with daniel on this one - knowing a field is a uuid makes it
> easier
> to deal with in the db and code around it compared to a string
> (stored
> binary instead of string representation, etc.)
> 

Why to store binary?

Alon.


From jhernand at redhat.com  Fri Aug 31 09:36:10 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 31 Aug 2012 11:36:10 +0200
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <1992507157.4126840.1346405252832.JavaMail.root@redhat.com>
References: <1992507157.4126840.1346405252832.JavaMail.root@redhat.com>
Message-ID: <5040858A.2090602@redhat.com>

On 08/31/2012 11:27 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
>> <vdsm-devel at lists.fedorahosted.org>
>> Sent: Friday, August 31, 2012 12:23:38 PM
>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>
>> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
>>>> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
>>>> <vdsm-devel at lists.fedorahosted.org>
>>>> Sent: Friday, August 31, 2012 12:19:46 AM
>>>> Subject: [vdsm] [RFC] Implied UUIDs in API
>>>>
>>>> Hi, in the API a lot of IDs get passed around are UUIDs.
>>>> The point is that as long as you are not the entity generating the
>>>> UUIDs the fact that these are UUIDs have no real significance to
>>>> you.
>>>> I suggest removing the validation of UUIDs from the receiving end.
>>>> There is no real reason to make sure these are real UUIDs.
>>>> It's another restriction we can remove from the interface
>>>> simplifying
>>>> the code and the interface.
>>>>
>>>> Just to be clear I'm not saying that we should stop using UUIDs.
>>>> For example, vdsm will keep generating task IDs as UUIDs. But the
>>>> documentation will state that it could be *any* string value.
>>>> If for some reason we choose to change the format of task IDs.
>>>> There
>>>> will be no need to change the interface.
>>>>
>>>> The same goes for VM IDs. Currently the engine uses UUIDs but
>>>> there
>>>> is no reason for VDSM to enforce this and limit the engine from
>>>> ever
>>>> changing it in the future and using other string values.
>>>
>>> I agree that UUID is just a method of generating unique strings,
>>> there is no reason to validate the value nor the format.
>>
>> I'm with daniel on this one - knowing a field is a uuid makes it
>> easier
>> to deal with in the db and code around it compared to a string
>> (stored
>> binary instead of string representation, etc.)
>>
> 
> Why to store binary?

An UUID stored in its binary format takes 16 bytes. Stored as an string
it takes 36 bytes, and more than 72 bytes in memory in the engine. The
amount of CPU needed to create/compare/etc is proportional.

The engine takes advantage of this and uses an specialized UUID class
and a specialized database type to manage them. If we change to
arbitrary strings then a *lot* of changes have to be done to the engine.

-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From alonbl at redhat.com  Fri Aug 31 12:36:45 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 31 Aug 2012 08:36:45 -0400 (EDT)
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <5040858A.2090602@redhat.com>
Message-ID: <356320509.4150036.1346416605322.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Friday, August 31, 2012 12:36:10 PM
> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> 
> On 08/31/2012 11:27 AM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch"
> >> <arch at ovirt.org>, "VDSM Project Development"
> >> <vdsm-devel at lists.fedorahosted.org>
> >> Sent: Friday, August 31, 2012 12:23:38 PM
> >> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> >>
> >> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> >>>> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> >>>> <vdsm-devel at lists.fedorahosted.org>
> >>>> Sent: Friday, August 31, 2012 12:19:46 AM
> >>>> Subject: [vdsm] [RFC] Implied UUIDs in API
> >>>>
> >>>> Hi, in the API a lot of IDs get passed around are UUIDs.
> >>>> The point is that as long as you are not the entity generating
> >>>> the
> >>>> UUIDs the fact that these are UUIDs have no real significance to
> >>>> you.
> >>>> I suggest removing the validation of UUIDs from the receiving
> >>>> end.
> >>>> There is no real reason to make sure these are real UUIDs.
> >>>> It's another restriction we can remove from the interface
> >>>> simplifying
> >>>> the code and the interface.
> >>>>
> >>>> Just to be clear I'm not saying that we should stop using UUIDs.
> >>>> For example, vdsm will keep generating task IDs as UUIDs. But
> >>>> the
> >>>> documentation will state that it could be *any* string value.
> >>>> If for some reason we choose to change the format of task IDs.
> >>>> There
> >>>> will be no need to change the interface.
> >>>>
> >>>> The same goes for VM IDs. Currently the engine uses UUIDs but
> >>>> there
> >>>> is no reason for VDSM to enforce this and limit the engine from
> >>>> ever
> >>>> changing it in the future and using other string values.
> >>>
> >>> I agree that UUID is just a method of generating unique strings,
> >>> there is no reason to validate the value nor the format.
> >>
> >> I'm with daniel on this one - knowing a field is a uuid makes it
> >> easier
> >> to deal with in the db and code around it compared to a string
> >> (stored
> >> binary instead of string representation, etc.)
> >>
> > 
> > Why to store binary?
> 
> An UUID stored in its binary format takes 16 bytes. Stored as an
> string
> it takes 36 bytes, and more than 72 bytes in memory in the engine.
> The
> amount of CPU needed to create/compare/etc is proportional.
> 
> The engine takes advantage of this and uses an specialized UUID class
> and a specialized database type to manage them. If we change to
> arbitrary strings then a *lot* of changes have to be done to the
> engine.

We are trying to reduce types of vdsm to simplify the VDSM-next API.

I guess it will derive a lot of changes in the engine anyway...

32->72 bytes in memory of JVM is not something that I care, JVM is not optimized for memory use in any sense.

I am not sure that compare in database of binary or string has significant impact, if there is a proper indexing, and if foreign key is used to cascade.

Regards,
Alon.


From iheim at redhat.com  Fri Aug 31 13:22:14 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 31 Aug 2012 16:22:14 +0300
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <356320509.4150036.1346416605322.JavaMail.root@redhat.com>
References: <356320509.4150036.1346416605322.JavaMail.root@redhat.com>
Message-ID: <5040BA86.7010402@redhat.com>

On 08/31/2012 03:36 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
>> <vdsm-devel at lists.fedorahosted.org>
>> Sent: Friday, August 31, 2012 12:36:10 PM
>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>
>> On 08/31/2012 11:27 AM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch"
>>>> <arch at ovirt.org>, "VDSM Project Development"
>>>> <vdsm-devel at lists.fedorahosted.org>
>>>> Sent: Friday, August 31, 2012 12:23:38 PM
>>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>>>
>>>> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
>>>>>> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
>>>>>> <vdsm-devel at lists.fedorahosted.org>
>>>>>> Sent: Friday, August 31, 2012 12:19:46 AM
>>>>>> Subject: [vdsm] [RFC] Implied UUIDs in API
>>>>>>
>>>>>> Hi, in the API a lot of IDs get passed around are UUIDs.
>>>>>> The point is that as long as you are not the entity generating
>>>>>> the
>>>>>> UUIDs the fact that these are UUIDs have no real significance to
>>>>>> you.
>>>>>> I suggest removing the validation of UUIDs from the receiving
>>>>>> end.
>>>>>> There is no real reason to make sure these are real UUIDs.
>>>>>> It's another restriction we can remove from the interface
>>>>>> simplifying
>>>>>> the code and the interface.
>>>>>>
>>>>>> Just to be clear I'm not saying that we should stop using UUIDs.
>>>>>> For example, vdsm will keep generating task IDs as UUIDs. But
>>>>>> the
>>>>>> documentation will state that it could be *any* string value.
>>>>>> If for some reason we choose to change the format of task IDs.
>>>>>> There
>>>>>> will be no need to change the interface.
>>>>>>
>>>>>> The same goes for VM IDs. Currently the engine uses UUIDs but
>>>>>> there
>>>>>> is no reason for VDSM to enforce this and limit the engine from
>>>>>> ever
>>>>>> changing it in the future and using other string values.
>>>>>
>>>>> I agree that UUID is just a method of generating unique strings,
>>>>> there is no reason to validate the value nor the format.
>>>>
>>>> I'm with daniel on this one - knowing a field is a uuid makes it
>>>> easier
>>>> to deal with in the db and code around it compared to a string
>>>> (stored
>>>> binary instead of string representation, etc.)
>>>>
>>>
>>> Why to store binary?
>>
>> An UUID stored in its binary format takes 16 bytes. Stored as an
>> string
>> it takes 36 bytes, and more than 72 bytes in memory in the engine.
>> The
>> amount of CPU needed to create/compare/etc is proportional.
>>
>> The engine takes advantage of this and uses an specialized UUID class
>> and a specialized database type to manage them. If we change to
>> arbitrary strings then a *lot* of changes have to be done to the
>> engine.
>
> We are trying to reduce types of vdsm to simplify the VDSM-next API.
>
> I guess it will derive a lot of changes in the engine anyway...
>
> 32->72 bytes in memory of JVM is not something that I care, JVM is not optimized for memory use in any sense.

that doesn't mean you should abuse it. it's not a single item. its all 
the items.


>
> I am not sure that compare in database of binary or string has significant impact, if there is a proper indexing, and if foreign key is used to cascade.
>
> Regards,
> Alon.
>




From alonbl at redhat.com  Fri Aug 31 13:52:33 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 31 Aug 2012 09:52:33 -0400 (EDT)
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <5040BA86.7010402@redhat.com>
Message-ID: <1103712619.4172295.1346421153430.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Friday, August 31, 2012 4:22:14 PM
> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> 
> On 08/31/2012 03:36 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>,
> >> "VDSM Project Development"
> >> <vdsm-devel at lists.fedorahosted.org>
> >> Sent: Friday, August 31, 2012 12:36:10 PM
> >> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> >>
> >> On 08/31/2012 11:27 AM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch"
> >>>> <arch at ovirt.org>, "VDSM Project Development"
> >>>> <vdsm-devel at lists.fedorahosted.org>
> >>>> Sent: Friday, August 31, 2012 12:23:38 PM
> >>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> >>>>
> >>>> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> >>>>>> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> >>>>>> <vdsm-devel at lists.fedorahosted.org>
> >>>>>> Sent: Friday, August 31, 2012 12:19:46 AM
> >>>>>> Subject: [vdsm] [RFC] Implied UUIDs in API
> >>>>>>
> >>>>>> Hi, in the API a lot of IDs get passed around are UUIDs.
> >>>>>> The point is that as long as you are not the entity generating
> >>>>>> the
> >>>>>> UUIDs the fact that these are UUIDs have no real significance
> >>>>>> to
> >>>>>> you.
> >>>>>> I suggest removing the validation of UUIDs from the receiving
> >>>>>> end.
> >>>>>> There is no real reason to make sure these are real UUIDs.
> >>>>>> It's another restriction we can remove from the interface
> >>>>>> simplifying
> >>>>>> the code and the interface.
> >>>>>>
> >>>>>> Just to be clear I'm not saying that we should stop using
> >>>>>> UUIDs.
> >>>>>> For example, vdsm will keep generating task IDs as UUIDs. But
> >>>>>> the
> >>>>>> documentation will state that it could be *any* string value.
> >>>>>> If for some reason we choose to change the format of task IDs.
> >>>>>> There
> >>>>>> will be no need to change the interface.
> >>>>>>
> >>>>>> The same goes for VM IDs. Currently the engine uses UUIDs but
> >>>>>> there
> >>>>>> is no reason for VDSM to enforce this and limit the engine
> >>>>>> from
> >>>>>> ever
> >>>>>> changing it in the future and using other string values.
> >>>>>
> >>>>> I agree that UUID is just a method of generating unique
> >>>>> strings,
> >>>>> there is no reason to validate the value nor the format.
> >>>>
> >>>> I'm with daniel on this one - knowing a field is a uuid makes it
> >>>> easier
> >>>> to deal with in the db and code around it compared to a string
> >>>> (stored
> >>>> binary instead of string representation, etc.)
> >>>>
> >>>
> >>> Why to store binary?
> >>
> >> An UUID stored in its binary format takes 16 bytes. Stored as an
> >> string
> >> it takes 36 bytes, and more than 72 bytes in memory in the engine.
> >> The
> >> amount of CPU needed to create/compare/etc is proportional.
> >>
> >> The engine takes advantage of this and uses an specialized UUID
> >> class
> >> and a specialized database type to manage them. If we change to
> >> arbitrary strings then a *lot* of changes have to be done to the
> >> engine.
> >
> > We are trying to reduce types of vdsm to simplify the VDSM-next
> > API.
> >
> > I guess it will derive a lot of changes in the engine anyway...
> >
> > 32->72 bytes in memory of JVM is not something that I care, JVM is
> > not optimized for memory use in any sense.
> 
> that doesn't mean you should abuse it. it's not a single item. its
> all
> the items.

I guess you want me to analyse our current implementation and find optimizations that can be done... or in different words, find entities we abuse now... :)
 
> 
> >
> > I am not sure that compare in database of binary or string has
> > significant impact, if there is a proper indexing, and if foreign
> > key is used to cascade.
> >
> > Regards,
> > Alon.
> >
> 
> 
> 


From smizrahi at redhat.com  Fri Aug 31 14:58:29 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Fri, 31 Aug 2012 10:58:29 -0400 (EDT)
Subject: [vdsm] [RFC] Implied UUIDs in API
In-Reply-To: <1103712619.4172295.1346421153430.JavaMail.root@redhat.com>
Message-ID: <1811692057.16247296.1346425109172.JavaMail.root@redhat.com>

In my opinion the implications on the engine database storage are not relevant, the engine can still choose to store everything as UUID if it finds it more easier.
The only change would be that VDMS wouldn't care if they are UUIDs or not. They can still *be* UUIDs.
The only problem is that if other managers start creating entities you will have to be able to gracefully handle that in API responses.

I also wonder why libvirt chose to validate UUIDs. Because as I said, as long as you don't generate them the fact that the are *possibly* unique is of no consequence to you. Seeing as the field comes to libvirt from an XML stream there is no real issue with parsing and putting it in a properly null terminated buffer.

The main reason I want to rid away the UUID restriction is that I think that it will help us have namespacing.

As VDSM's API becomes open and the ovirt-engine less centralized it will be harder to know which VDSM side resources are owned by which managing entity.
Being able to mangle in you data (eg. OVIRT_ENGINE_0003-321321-321321-3213) will make it easier to know which VMs, domains, storage connections, are owned by which entity without actually going into implementing access controls on VDSM resources.

Further more, subsystems that might generate IDs in a different way could be fitted more easily.

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Friday, August 31, 2012 9:52:33 AM
> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> 
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "arch"
> > <arch at ovirt.org>, "VDSM Project Development"
> > <vdsm-devel at lists.fedorahosted.org>
> > Sent: Friday, August 31, 2012 4:22:14 PM
> > Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> > 
> > On 08/31/2012 03:36 PM, Alon Bar-Lev wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Juan Hernandez" <jhernand at redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>,
> > >> "VDSM Project Development"
> > >> <vdsm-devel at lists.fedorahosted.org>
> > >> Sent: Friday, August 31, 2012 12:36:10 PM
> > >> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> > >>
> > >> On 08/31/2012 11:27 AM, Alon Bar-Lev wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Itamar Heim" <iheim at redhat.com>
> > >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch"
> > >>>> <arch at ovirt.org>, "VDSM Project Development"
> > >>>> <vdsm-devel at lists.fedorahosted.org>
> > >>>> Sent: Friday, August 31, 2012 12:23:38 PM
> > >>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> > >>>>
> > >>>> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > >>>>>> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> > >>>>>> <vdsm-devel at lists.fedorahosted.org>
> > >>>>>> Sent: Friday, August 31, 2012 12:19:46 AM
> > >>>>>> Subject: [vdsm] [RFC] Implied UUIDs in API
> > >>>>>>
> > >>>>>> Hi, in the API a lot of IDs get passed around are UUIDs.
> > >>>>>> The point is that as long as you are not the entity
> > >>>>>> generating
> > >>>>>> the
> > >>>>>> UUIDs the fact that these are UUIDs have no real
> > >>>>>> significance
> > >>>>>> to
> > >>>>>> you.
> > >>>>>> I suggest removing the validation of UUIDs from the
> > >>>>>> receiving
> > >>>>>> end.
> > >>>>>> There is no real reason to make sure these are real UUIDs.
> > >>>>>> It's another restriction we can remove from the interface
> > >>>>>> simplifying
> > >>>>>> the code and the interface.
> > >>>>>>
> > >>>>>> Just to be clear I'm not saying that we should stop using
> > >>>>>> UUIDs.
> > >>>>>> For example, vdsm will keep generating task IDs as UUIDs.
> > >>>>>> But
> > >>>>>> the
> > >>>>>> documentation will state that it could be *any* string
> > >>>>>> value.
> > >>>>>> If for some reason we choose to change the format of task
> > >>>>>> IDs.
> > >>>>>> There
> > >>>>>> will be no need to change the interface.
> > >>>>>>
> > >>>>>> The same goes for VM IDs. Currently the engine uses UUIDs
> > >>>>>> but
> > >>>>>> there
> > >>>>>> is no reason for VDSM to enforce this and limit the engine
> > >>>>>> from
> > >>>>>> ever
> > >>>>>> changing it in the future and using other string values.
> > >>>>>
> > >>>>> I agree that UUID is just a method of generating unique
> > >>>>> strings,
> > >>>>> there is no reason to validate the value nor the format.
> > >>>>
> > >>>> I'm with daniel on this one - knowing a field is a uuid makes
> > >>>> it
> > >>>> easier
> > >>>> to deal with in the db and code around it compared to a string
> > >>>> (stored
> > >>>> binary instead of string representation, etc.)
> > >>>>
> > >>>
> > >>> Why to store binary?
> > >>
> > >> An UUID stored in its binary format takes 16 bytes. Stored as an
> > >> string
> > >> it takes 36 bytes, and more than 72 bytes in memory in the
> > >> engine.
> > >> The
> > >> amount of CPU needed to create/compare/etc is proportional.
> > >>
> > >> The engine takes advantage of this and uses an specialized UUID
> > >> class
> > >> and a specialized database type to manage them. If we change to
> > >> arbitrary strings then a *lot* of changes have to be done to the
> > >> engine.
> > >
> > > We are trying to reduce types of vdsm to simplify the VDSM-next
> > > API.
> > >
> > > I guess it will derive a lot of changes in the engine anyway...
> > >
> > > 32->72 bytes in memory of JVM is not something that I care, JVM
> > > is
> > > not optimized for memory use in any sense.
> > 
> > that doesn't mean you should abuse it. it's not a single item. its
> > all
> > the items.
> 
> I guess you want me to analyse our current implementation and find
> optimizations that can be done... or in different words, find
> entities we abuse now... :)
>  
> > 
> > >
> > > I am not sure that compare in database of binary or string has
> > > significant impact, if there is a proper indexing, and if foreign
> > > key is used to cascade.
> > >
> > > Regards,
> > > Alon.
> > >
> > 
> > 
> > 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From jclift at redhat.com  Mon Aug  6 10:50:16 2012
From: jclift at redhat.com (Justin Clift)
Date: Mon, 06 Aug 2012 10:50:16 -0000
Subject: [Users] Looking for help: Demo videos
In-Reply-To: <2005779743.85826.1344104498773.JavaMail.root@redhat.com>
References: <2005779743.85826.1344104498773.JavaMail.root@redhat.com>
Message-ID: <CAF8DE3E-F586-4C83-9C1D-CA9C755798BA@redhat.com>

On 05/08/2012, at 4:21 AM, Jason Brooks wrote:
> Hey everyone:
> 
> I've made a screencast of creating VMs in oVirt 3.1: http://www.youtube.com/watch?v=C4gayV6dYK4
> 
> I wrote a blog post about the tools and process I used: http://blog.jebpages.com/archives/screencasting-ovirt/
> 
> Now that I have the process down (and my oVirt 3.1 rig in shape), I'll do a few more of these before the 3.1 launch.


Very good work Jason. :)

Do you reckon inline embedded video's would be
acceptable for the press release?

i.e. using iframe approach, same as on your
blog page

Regards and best wishes,

Justin Clift

--
Aeolus Community Manager
http://www.aeolusproject.org



From ewoud+ovirt at kohlvanwijngaarden.nl  Tue Aug 14 10:28:53 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Tue, 14 Aug 2012 10:28:53 -0000
Subject: [Engine-devel] [vdsm] Jenkins testing.
In-Reply-To: <560190193.4470348.1344939611714.JavaMail.root@redhat.com>
References: <502A1247.3060508@linux.vnet.ibm.com>
	<560190193.4470348.1344939611714.JavaMail.root@redhat.com>
Message-ID: <20120814102836.GH25069@bogey.xentower.nl>

On Tue, Aug 14, 2012 at 06:20:11AM -0400, Eyal Edri wrote:
> Deepak C Shetty wrote:
> > On 08/14/2012 12:52 PM, Deepak C Shetty wrote:
> > > On 08/14/2012 11:13 AM, Robert Middleswarth wrote:
> > >> After a few false starts it looks like we have per patch testing
> > >> working on VDSM, oVirt-engine, oVirt-engine-sdk and
> > >> oVirt-engine-cli.  There are 3 status a patch can get.  1) Success
> > >> -
> > >> Means the patch ran though the tests without issue.  2) Failure -
> > >> Means the tests failed.  3) Aborted - Generally means the
> > >> submitter
> > >> is not in the whitelist and the tests were never run.  If you have
> > >> any questions please feel free to ask.
> > >>
> > > So what is needed for the submitted to be in whitelist ?
> > > I once for Success for few of my patches.. then got failure for
> > > some
> > > other patch( maybe thats due to the false starts u had) and then
> > > for
> > > the latest patch of mine, it says aborted.
> > >
> > > So not sure if i am in whitelist or not ?
> > > If not, what do i need to do to be part of it ?
> > > If yes, why did the build abort for my latest patch ?
> > >
> > Pls see http://gerrit.ovirt.org/#/c/6856/
> > For patch1 it says build success, for patch 2, it says aborted.. why
> > ?
> >
>
> it's because your email address wasn't in the jenkins-whitelist.txt file.
> this file includes emails address for users that jenkins will allow
> running test jobs on thier patches.  this was introduced as a way for
> defending the jenkins from malicious users that might send harmful
> patches to jenkins.
>
> i've added you to the whitelist, you should be ok now.
>
> the list was generated automaticly from git log, so it still might
> missing known people, if anyone sees this aborted msg in the gerrit,
> please contact infra team so he can be added to the whitelist.

Note that the whitelist is in the jenkins-whitelist repo so see
http://gerrit.ovirt.org/gitweb?p=jenkins-whitelist.git and
http://gerrit.ovirt.org/#/q/project:jenkins-whitelist,n,z for more
details.


From sgrinber at redhat.com  Fri Aug 31 08:57:53 2012
From: sgrinber at redhat.com (Simon Grinberg)
Date: Fri, 31 Aug 2012 04:57:53 -0400 (EDT)
Subject: [RFC] Implied UUIDs in API
In-Reply-To: <213167067.15587136.1346361586741.JavaMail.root@redhat.com>
References: <213167067.15587136.1346361586741.JavaMail.root@redhat.com>
Message-ID: <96CCAEAC-C9AD-44D5-B217-A59A04DB9ACD@redhat.com>

+1

Long ago it was not enforced and then changed.
The motivation for the enforcing as I recall was that for VMs this was also the guest system ID. I don't know if this is the case now days.


Regards,
Simon

Sent from my iPhone, please excuse any typos.

?-31 ???? 2012, ???? 00:19, Saggi Mizrahi <smizrahi at redhat.com> ???/?:

> Hi, in the API a lot of IDs get passed around are UUIDs.
> The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you.
> I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs.
> It's another restriction we can remove from the interface simplifying the code and the interface.
> 
> Just to be clear I'm not saying that we should stop using UUIDs.
> For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value.
> If for some reason we choose to change the format of task IDs. There will be no need to change the interface.
> 
> The same goes for VM IDs. Currently the engine uses UUIDs but there is no reason for VDSM to enforce this and limit the engine from ever changing it in the future and using other string values.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120831/3216949a/attachment.html>