From kwade at redhat.com  Thu Nov  1 17:37:54 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 01 Nov 2012 10:37:54 -0700
Subject: oVirt Weekly Meeting 2012-11-07 -- Cancel or hold?
In-Reply-To: <1351695867.4661.12.camel@beelzebub.mburnsfire.net>
References: <1351695867.4661.12.camel@beelzebub.mburnsfire.net>
Message-ID: <5092B372.3010906@redhat.com>

On 10/31/2012 08:04 AM, Mike Burns wrote:
> Should we consider canceling the weekly meeting next week since most of
> the major decision makers are all going to be tied up with KVM
> Forum/oVirt Workshop in Barcelona?

+1 for me - any extra time in the week is welcome, eh?

- Karsten
-- 
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: 251 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121101/41f71cc1/attachment.sig>

From sgordon at redhat.com  Thu Nov  1 20:45:21 2012
From: sgordon at redhat.com (Steve Gordon)
Date: Thu, 1 Nov 2012 16:45:21 -0400 (EDT)
Subject: oVirt Weekly Meeting 2012-11-07 -- Cancel or hold?
In-Reply-To: <5092B372.3010906@redhat.com>
Message-ID: <551071878.25652204.1351802721935.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Karsten 'quaid' Wade" <kwade at redhat.com>
> To: "<arch at ovirt.org>" <arch at ovirt.org>
> Sent: Thursday, November 1, 2012 1:37:54 PM
> Subject: Re: oVirt Weekly Meeting 2012-11-07 -- Cancel or hold?
> 
> On 10/31/2012 08:04 AM, Mike Burns wrote:
> > Should we consider canceling the weekly meeting next week since
> > most of
> > the major decision makers are all going to be tied up with KVM
> > Forum/oVirt Workshop in Barcelona?
> 
> +1 for me - any extra time in the week is welcome, eh?
> 
> - Karsten

Can't argue with that, +1.


From mburns at redhat.com  Fri Nov  2 01:22:58 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 01 Nov 2012 21:22:58 -0400
Subject: oVirt Weekly Meeting 2012-11-07 -- Cancel or hold?
In-Reply-To: <551071878.25652204.1351802721935.JavaMail.root@redhat.com>
References: <551071878.25652204.1351802721935.JavaMail.root@redhat.com>
Message-ID: <1351819378.11987.15.camel@mburns-laptop.usersys.redhat.com>

On Thu, 2012-11-01 at 16:45 -0400, Steve Gordon wrote:
> ----- Original Message -----
> > From: "Karsten 'quaid' Wade" <kwade at redhat.com>
> > To: "<arch at ovirt.org>" <arch at ovirt.org>
> > Sent: Thursday, November 1, 2012 1:37:54 PM
> > Subject: Re: oVirt Weekly Meeting 2012-11-07 -- Cancel or hold?
> > 
> > On 10/31/2012 08:04 AM, Mike Burns wrote:
> > > Should we consider canceling the weekly meeting next week since
> > > most of
> > > the major decision makers are all going to be tied up with KVM
> > > Forum/oVirt Workshop in Barcelona?
> > 
> > +1 for me - any extra time in the week is welcome, eh?
> > 
> > - Karsten
> 
> Can't argue with that, +1.

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




From jhernand at redhat.com  Mon Nov  5 16:28:43 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 05 Nov 2012 17:28:43 +0100
Subject: oVirt 3.2 on fedora 18
In-Reply-To: <1753024779.21667958.1352128100401.JavaMail.root@redhat.com>
References: <1753024779.21667958.1352128100401.JavaMail.root@redhat.com>
Message-ID: <5097E93B.5070704@redhat.com>

On 11/05/2012 04:08 PM, Ohad Basan wrote:
> 
> 
> 
> 
> ----- Original Message -----
>> From: "Ohad Basan" <obasan at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "Federico Simoncelli"
>> <fsimonce at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Itamar Heim" <iheim at redhat.com>, arch at ovirt.org, "Moran Goldboim" <mgoldboi at redhat.com>
>> Sent: Sunday, November 4, 2012 6:59:53 PM
>> Subject: Re: oVirt 3.2 on fedora 18
>>
>> Here is a progress upgrade of engine+upgrade from f17 to f18
>>
>> F17 to F18 upgrade engine
>>
>> -installation -
>>
>>     upgrade to F18 with --exclude=ovirt* and --exclude=vdsm* or
>>     otherwise it won't work.
>>     upgrade to f18 using the following guide
>>     https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum?rd=YumUpgradeFaq#Fedora_17_-.3E_Fedora_18
>>     httpd won't start at the beginning. it is a must to correctly
>>     merge ssl.conf and ssl.conf.rpmnew. NOTE: SSLMutex parameter has
>>     to be removed or apache won't start.
>>     Postgresql won't start. db structure has to be converted to the
>>     structure of the new version of the pg. we'll have to see what
>>     is the best way to handle it. basically
>>     http://www.postgresql.org/docs/current/static/pgupgrade.html is
>>     required but it can't be run since the pg server can't be
>>     started. might have to dump the db prior the dist upgrade though
>>     I'm not sure it's the best way to take care of it.
> walkaround for db upgrade:
> I didn't get pg_upgrade to work so the steps are as following.
> 
> 1. pg_dumpall to a file.
> 2. drop database engine;
> 3. upgrade to fedora18
> 4. move psql data library. /var/lib/pgsql to another location (backup)
> 5. run postgresql-setup initdb
> 6. make sure that pg_hba.conf is configured correctly and restart the db.
> 7. restore the backed up dump file. psql -f <Filename> -U postgres.
> 8. restart engine
> 
> despite the fact that the database is in place with the correct owner. engine still has issues accessing the db.
> engine.log is attached. plz see the end of the file
> 
> 2012-11-05 16:40:50,974 ERROR [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-1) Error in getting DB connection. The database is inaccessible. Original exception is: DataAccessResourceFailureException: Error retreiving database metadata; nested exception is org.springframework.jdbc.support.MetaDataAccessException: Could not get Connection for extracting meta data; nested exception is org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/ENGINEDataSource
> 2012-11-05 16:40:56,329 INFO  [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-1) Start time: 11/5/12 4:40 PM
> 2012-11-05 16:40:56,498 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: CbcCheckOnVdsChange
> 2012-11-05 16:40:56,509 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: CAEngineKey
> 2012-11-05 16:40:56,918 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: SQLServerI18NPrefix
> 2012-11-05 16:40:57,172 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: ScriptsPath
> 2012-11-05 16:40:57,203 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-1) Could not parse option AutoRecoveryAllowedTypes value.
> 2012-11-05 16:40:57,205 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: MinimalETLVersion
> 2012-11-05 16:40:57,262 ERROR [org.ovirt.engine.core.engineencryptutils.EncryptionUtils] (MSC service thread 1-1) Failed to decrypt Data must start with zero
> 2012-11-05 16:40:57,262 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-1) Failed to decrypt value for property TruststorePass will be used encrypted value
> 2012-11-05 16:40:57,263 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: ENGINEEARLib
> 2012-11-05 16:40:57,355 INFO  [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-1) VDSBrokerFrontend: 11/5/12 4:40 PM
> 2012-11-05 16:40:57,366 INFO  [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-1) CpuFlagsManager: 11/5/12 4:40 PM
> 2012-11-05 16:40:57,370 INFO  [org.ovirt.engine.core.bll.AuditLogCleanupManager] (MSC service thread 1-1) Setting audit clean up manager to run at: 35 35 3 * * ?
> 2012-11-05 16:40:57,371 ERROR [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy] (MSC service thread 1-1) Failed to lookup resource type: SCHEDULER. JNDI name: java:global/engine/engine-scheduler/Scheduler: javax.naming.NameNotFoundException: Error looking up engine/engine-scheduler/Scheduler, service service jboss.naming.context.java.global.engine.engine-scheduler.Scheduler is not started
>         at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
>         at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
>         at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_09-icedtea]
>         at org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104) [engine-utils.jar:]
>         at org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23) [engine-utils.jar:]
>         at org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl.getInstance(SchedulerUtilQuartzImpl.java:106) [engine-scheduler.jar:]
>         at org.ovirt.engine.core.bll.AuditLogCleanupManager.<init>(AuditLogCleanupManager.java:34) [engine-bll.jar:]
>         at org.ovirt.engine.core.bll.AuditLogCleanupManager.<clinit>(AuditLogCleanupManager.java:19) [engine-bll.jar:]
>         at org.ovirt.engine.core.bll.Backend.Initialize(Backend.java:180) [engine-bll.jar:]
>         at org.ovirt.engine.core.bll.Backend.create(Backend.java:118) [engine-bll.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
>         at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> 
> 
>>
>> -basic operation
>>
>>
>> ----- Original Message -----
>>> From: "Ohad Basan" <obasan at redhat.com>
>>> To: "Eli Mesika" <emesika at redhat.com>, "Juan Hernandez"
>>> <jhernand at redhat.com>, "Federico Simoncelli"
>>> <fsimonce at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: "Itamar Heim" <iheim at redhat.com>, arch at ovirt.org, "Moran
>>> Goldboim" <mgoldboi at redhat.com>
>>> Sent: Thursday, November 1, 2012 6:09:43 PM
>>> Subject: oVirt 3.2 on fedora 18
>>>
>>> Status:
>>>
>>>  
>>> Clean F18 engine
>>>
>>> Status:
>>>
>>> -installation -
>>>
>>>     passed RPM installation
>>>     failed engine-setup
>>>         Can't find systemct.conf - workaround
>>>         http://gerrit.ovirt.org/#/c/8705/
>>>         can't create a database due to wrong template1 encoding -
>>>         workaround > change tempalte1 encoding to UTF8 -
>>>
>>>         UPDATE pg_database SET datistemplate = FALSE WHERE datname
>>>         =
>>>         'template1';
>>>
>>>         DROP DATABASE template1;
>>>
>>>         CREATE DATABASE template1 WITH TEMPLATE = template0
>>>         ENCODING
>>>         = 'UNICODE';
>>>
>>>         UPDATE pg_database SET datistemplate = TRUE WHERE datname =
>>>         'template1';
>>>
>>>         Patch that should solve it is here:
>>>         https://bugzilla.redhat.com/show_bug.cgi?id=870056
>>>
>>>     can't find uuid-extension  (The uuid-ossp extension is not
>>>     available.
>>> It is possible the 'postgresql-contrib' package was not installed)
>>> -
>>> should also be solved by the patch above.
>>>
>>> -basic operation - not started
>>>
>>>
>>> Bugs:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=867833
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=869221
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=870056
>>>
>>>  
>>> Clean F18 vdsm
>>>
>>> -Installation -
>>>
>>>     Passed RPM installation
>>>     Bootstrapping fails. unable to create bridge. - workaround -
>>>     create bridge manually. (if networking daemon doesn't start -
>>>     try disabling selinux)
>>>
>>> -Basic Operation
>>>
>>>     Added f18 host to engine > host doesn't reboot. workaround >
>>>     reboot manually.
>>>     Failed to set iptables due to the switch to firewalld
>>>     Failed to attach storage domain.
>>>
>>> Bugs
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=869963
>>>
>>>
>>>
>>> Logs are attached.
>>> note the exception:
>>>
>>> Thread-103::ERROR::2012-11-01
>>> 13:58:53,630::task::833::TaskManager.Task::(_setError)
>>> Task=`5a51a266-2f10-4f1d-84f6-03417a41be2d`::Unexpected error
>>> Traceback (most recent call last):
>>>   File "/usr/share/vdsm/storage/task.py", line 840, in _run
>>>     return fn(*args, **kargs)
>>>   File "/usr/share/vdsm/logUtils.py", line 38, in wrapper
>>>     res = f(*args, **kwargs)
>>>   File "/usr/share/vdsm/storage/hsm.py", line 801, in
>>>   createStoragePool
>>>     return sp.StoragePool(spUUID, self.taskMng).create(poolName,
>>>     masterDom, domList, masterVersion, safeLease)
>>>   File "/usr/share/vdsm/storage/sp.py", line 569, in create
>>>     self._acquireTemporaryClusterLock(msdUUID, safeLease)
>>>   File "/usr/share/vdsm/storage/sp.py", line 510, in
>>>   _acquireTemporaryClusterLock
>>>     msd.acquireHostId(self.id)
>>>   File "/usr/share/vdsm/storage/sd.py", line 426, in acquireHostId
>>>     self._clusterLock.acquireHostId(hostId, async)
>>>   File "/usr/share/vdsm/storage/safelease.py", line 175, in
>>>   acquireHostId
>>>     raise se.AcquireHostIdFailure(self._sdUUID, e)
>>> AcquireHostIdFailure: Cannot acquire host id:
>>> ('7653059f-1141-444a-b5d6-9459d6d76638', SanlockException(-203,
>>> 'Sanlock lockspace add failure', 'Sanlock exception'))
>>>
>>>
>>> F17 to F18 upgrade engine
>>>
>>> -installation - Not started
>>>
>>> -basic operation
>>>
>>>
>>>  
>>> F17 to F18 upgrade vdsm
>>>
>>> -installation - Not started
>>>
>>> -basic operation
>>>
>>>
>>> Thank you
>>

Would it be possible to test the following command in order to verify
that the database is accessible using TCP:

psql --host the_name_of_the_host --user engine engine

That should ask for the password and then should give you a database
prompt. If it doesn't then something is wrong with authentication in the
pg_hba.conf file.

-- 
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 jhernand at redhat.com  Mon Nov  5 16:57:14 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 05 Nov 2012 17:57:14 +0100
Subject: oVirt 3.2 on fedora 18
In-Reply-To: <5097E93B.5070704@redhat.com>
References: <1753024779.21667958.1352128100401.JavaMail.root@redhat.com>
	<5097E93B.5070704@redhat.com>
Message-ID: <5097EFEA.2060904@redhat.com>

On 11/05/2012 05:28 PM, Juan Hernandez wrote:
> On 11/05/2012 04:08 PM, Ohad Basan wrote:
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: "Ohad Basan" <obasan at redhat.com>
>>> To: "Eli Mesika" <emesika at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "Federico Simoncelli"
>>> <fsimonce at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: "Itamar Heim" <iheim at redhat.com>, arch at ovirt.org, "Moran Goldboim" <mgoldboi at redhat.com>
>>> Sent: Sunday, November 4, 2012 6:59:53 PM
>>> Subject: Re: oVirt 3.2 on fedora 18
>>>
>>> Here is a progress upgrade of engine+upgrade from f17 to f18
>>>
>>> F17 to F18 upgrade engine
>>>
>>> -installation -
>>>
>>>     upgrade to F18 with --exclude=ovirt* and --exclude=vdsm* or
>>>     otherwise it won't work.
>>>     upgrade to f18 using the following guide
>>>     https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum?rd=YumUpgradeFaq#Fedora_17_-.3E_Fedora_18
>>>     httpd won't start at the beginning. it is a must to correctly
>>>     merge ssl.conf and ssl.conf.rpmnew. NOTE: SSLMutex parameter has
>>>     to be removed or apache won't start.
>>>     Postgresql won't start. db structure has to be converted to the
>>>     structure of the new version of the pg. we'll have to see what
>>>     is the best way to handle it. basically
>>>     http://www.postgresql.org/docs/current/static/pgupgrade.html is
>>>     required but it can't be run since the pg server can't be
>>>     started. might have to dump the db prior the dist upgrade though
>>>     I'm not sure it's the best way to take care of it.
>> walkaround for db upgrade:
>> I didn't get pg_upgrade to work so the steps are as following.
>>
>> 1. pg_dumpall to a file.
>> 2. drop database engine;
>> 3. upgrade to fedora18
>> 4. move psql data library. /var/lib/pgsql to another location (backup)
>> 5. run postgresql-setup initdb
>> 6. make sure that pg_hba.conf is configured correctly and restart the db.
>> 7. restore the backed up dump file. psql -f <Filename> -U postgres.
>> 8. restart engine
>>
>> despite the fact that the database is in place with the correct owner. engine still has issues accessing the db.
>> engine.log is attached. plz see the end of the file
>>
>> 2012-11-05 16:40:50,974 ERROR [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-1) Error in getting DB connection. The database is inaccessible. Original exception is: DataAccessResourceFailureException: Error retreiving database metadata; nested exception is org.springframework.jdbc.support.MetaDataAccessException: Could not get Connection for extracting meta data; nested exception is org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/ENGINEDataSource
>> 2012-11-05 16:40:56,329 INFO  [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-1) Start time: 11/5/12 4:40 PM
>> 2012-11-05 16:40:56,498 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: CbcCheckOnVdsChange
>> 2012-11-05 16:40:56,509 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: CAEngineKey
>> 2012-11-05 16:40:56,918 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: SQLServerI18NPrefix
>> 2012-11-05 16:40:57,172 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: ScriptsPath
>> 2012-11-05 16:40:57,203 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-1) Could not parse option AutoRecoveryAllowedTypes value.
>> 2012-11-05 16:40:57,205 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: MinimalETLVersion
>> 2012-11-05 16:40:57,262 ERROR [org.ovirt.engine.core.engineencryptutils.EncryptionUtils] (MSC service thread 1-1) Failed to decrypt Data must start with zero
>> 2012-11-05 16:40:57,262 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-1) Failed to decrypt value for property TruststorePass will be used encrypted value
>> 2012-11-05 16:40:57,263 WARN  [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-1) Could not find enum value for option: ENGINEEARLib
>> 2012-11-05 16:40:57,355 INFO  [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-1) VDSBrokerFrontend: 11/5/12 4:40 PM
>> 2012-11-05 16:40:57,366 INFO  [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-1) CpuFlagsManager: 11/5/12 4:40 PM
>> 2012-11-05 16:40:57,370 INFO  [org.ovirt.engine.core.bll.AuditLogCleanupManager] (MSC service thread 1-1) Setting audit clean up manager to run at: 35 35 3 * * ?
>> 2012-11-05 16:40:57,371 ERROR [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy] (MSC service thread 1-1) Failed to lookup resource type: SCHEDULER. JNDI name: java:global/engine/engine-scheduler/Scheduler: javax.naming.NameNotFoundException: Error looking up engine/engine-scheduler/Scheduler, service service jboss.naming.context.java.global.engine.engine-scheduler.Scheduler is not started
>>         at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
>>         at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
>>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
>>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
>>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
>>         at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_09-icedtea]
>>         at org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104) [engine-utils.jar:]
>>         at org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23) [engine-utils.jar:]
>>         at org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl.getInstance(SchedulerUtilQuartzImpl.java:106) [engine-scheduler.jar:]
>>         at org.ovirt.engine.core.bll.AuditLogCleanupManager.<init>(AuditLogCleanupManager.java:34) [engine-bll.jar:]
>>         at org.ovirt.engine.core.bll.AuditLogCleanupManager.<clinit>(AuditLogCleanupManager.java:19) [engine-bll.jar:]
>>         at org.ovirt.engine.core.bll.Backend.Initialize(Backend.java:180) [engine-bll.jar:]
>>         at org.ovirt.engine.core.bll.Backend.create(Backend.java:118) [engine-bll.jar:]
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
>>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
>>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
>>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
>>         at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
>>
>>
>>>
>>> -basic operation
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Ohad Basan" <obasan at redhat.com>
>>>> To: "Eli Mesika" <emesika at redhat.com>, "Juan Hernandez"
>>>> <jhernand at redhat.com>, "Federico Simoncelli"
>>>> <fsimonce at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "Itamar Heim" <iheim at redhat.com>, arch at ovirt.org, "Moran
>>>> Goldboim" <mgoldboi at redhat.com>
>>>> Sent: Thursday, November 1, 2012 6:09:43 PM
>>>> Subject: oVirt 3.2 on fedora 18
>>>>
>>>> Status:
>>>>
>>>>  
>>>> Clean F18 engine
>>>>
>>>> Status:
>>>>
>>>> -installation -
>>>>
>>>>     passed RPM installation
>>>>     failed engine-setup
>>>>         Can't find systemct.conf - workaround
>>>>         http://gerrit.ovirt.org/#/c/8705/
>>>>         can't create a database due to wrong template1 encoding -
>>>>         workaround > change tempalte1 encoding to UTF8 -
>>>>
>>>>         UPDATE pg_database SET datistemplate = FALSE WHERE datname
>>>>         =
>>>>         'template1';
>>>>
>>>>         DROP DATABASE template1;
>>>>
>>>>         CREATE DATABASE template1 WITH TEMPLATE = template0
>>>>         ENCODING
>>>>         = 'UNICODE';
>>>>
>>>>         UPDATE pg_database SET datistemplate = TRUE WHERE datname =
>>>>         'template1';
>>>>
>>>>         Patch that should solve it is here:
>>>>         https://bugzilla.redhat.com/show_bug.cgi?id=870056
>>>>
>>>>     can't find uuid-extension  (The uuid-ossp extension is not
>>>>     available.
>>>> It is possible the 'postgresql-contrib' package was not installed)
>>>> -
>>>> should also be solved by the patch above.
>>>>
>>>> -basic operation - not started
>>>>
>>>>
>>>> Bugs:
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=867833
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=869221
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=870056
>>>>
>>>>  
>>>> Clean F18 vdsm
>>>>
>>>> -Installation -
>>>>
>>>>     Passed RPM installation
>>>>     Bootstrapping fails. unable to create bridge. - workaround -
>>>>     create bridge manually. (if networking daemon doesn't start -
>>>>     try disabling selinux)
>>>>
>>>> -Basic Operation
>>>>
>>>>     Added f18 host to engine > host doesn't reboot. workaround >
>>>>     reboot manually.
>>>>     Failed to set iptables due to the switch to firewalld
>>>>     Failed to attach storage domain.
>>>>
>>>> Bugs
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=869963
>>>>
>>>>
>>>>
>>>> Logs are attached.
>>>> note the exception:
>>>>
>>>> Thread-103::ERROR::2012-11-01
>>>> 13:58:53,630::task::833::TaskManager.Task::(_setError)
>>>> Task=`5a51a266-2f10-4f1d-84f6-03417a41be2d`::Unexpected error
>>>> Traceback (most recent call last):
>>>>   File "/usr/share/vdsm/storage/task.py", line 840, in _run
>>>>     return fn(*args, **kargs)
>>>>   File "/usr/share/vdsm/logUtils.py", line 38, in wrapper
>>>>     res = f(*args, **kwargs)
>>>>   File "/usr/share/vdsm/storage/hsm.py", line 801, in
>>>>   createStoragePool
>>>>     return sp.StoragePool(spUUID, self.taskMng).create(poolName,
>>>>     masterDom, domList, masterVersion, safeLease)
>>>>   File "/usr/share/vdsm/storage/sp.py", line 569, in create
>>>>     self._acquireTemporaryClusterLock(msdUUID, safeLease)
>>>>   File "/usr/share/vdsm/storage/sp.py", line 510, in
>>>>   _acquireTemporaryClusterLock
>>>>     msd.acquireHostId(self.id)
>>>>   File "/usr/share/vdsm/storage/sd.py", line 426, in acquireHostId
>>>>     self._clusterLock.acquireHostId(hostId, async)
>>>>   File "/usr/share/vdsm/storage/safelease.py", line 175, in
>>>>   acquireHostId
>>>>     raise se.AcquireHostIdFailure(self._sdUUID, e)
>>>> AcquireHostIdFailure: Cannot acquire host id:
>>>> ('7653059f-1141-444a-b5d6-9459d6d76638', SanlockException(-203,
>>>> 'Sanlock lockspace add failure', 'Sanlock exception'))
>>>>
>>>>
>>>> F17 to F18 upgrade engine
>>>>
>>>> -installation - Not started
>>>>
>>>> -basic operation
>>>>
>>>>
>>>>  
>>>> F17 to F18 upgrade vdsm
>>>>
>>>> -installation - Not started
>>>>
>>>> -basic operation
>>>>
>>>>
>>>> Thank you
>>>
> 
> Would it be possible to test the following command in order to verify
> that the database is accessible using TCP:
> 
> psql --host the_name_of_the_host --user engine engine
> 
> That should ask for the password and then should give you a database
> prompt. If it doesn't then something is wrong with authentication in the
> pg_hba.conf file.
> 

By the way, there are other issues to build/run in Fedora 18 that I had
to solve when I built the "official" package. You can take a look at the
patches that I had to prepare here:

http://pkgs.fedoraproject.org/cgit/ovirt-engine.git/tree/?h=f18

Note that these apply to 3.1, but most should apply to 3.2 as well.
-- 
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 iheim at redhat.com  Tue Nov  6 05:47:03 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 06 Nov 2012 06:47:03 +0100
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <50988A29.4010802@linux.vnet.ibm.com>
References: <508F5F02.2060100@linux.vnet.ibm.com>
	<50988A29.4010802@linux.vnet.ibm.com>
Message-ID: <5098A457.5090302@redhat.com>

On 11/06/2012 04:55 AM, Sheldon wrote:
> On 10/30/2012 01:00 PM, Sheldon wrote:
>> Looking for some review on this patch.
>>
>> http://gerrit.ovirt.org/#/c/7535/
>>
>> Thanks.
>
> Add a feature page on wiki.http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device

(moved to arch)
thanks.
I'm missing where this will be in the engine dialog (in new/edit vm), 
and that engine should probably get the log event on the watchdog event, 
not only vdsm.

thanks,
    Itamar

>
>> --
>> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
>> IBM Linux Technology Center
>>
>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
>
> --
> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
> IBM Linux Technology Center
>
>
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>




From ppinatti at linux.vnet.ibm.com  Wed Nov  7 15:17:26 2012
From: ppinatti at linux.vnet.ibm.com (Paulo de Rezende Pinatti)
Date: Wed, 07 Nov 2012 13:17:26 -0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50839EBA.1080301@redhat.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
Message-ID: <509A7B86.4050700@linux.vnet.ibm.com>

Hello all,

I have consolidated the ideas for enabling ppc64 in ovirt-engine in a 
feature page: http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64

Suggestions and comments are greatly appreciated.

Thanks,

Paulo de Rezende Pinatti
Staff Software Engineer
IBM Linux Technology Center

On 10/21/2012 05:05 AM, Itamar Heim wrote:
> On 09/09/2012 07:38 PM, Pradipta Kumar Banerjee wrote:
>> Dear All,
>> Request your comments and suggestions on managing KVM on IBM POWER 
>> (PPC64) via
>> ovirt/vdsm
>>
>> Please find the feature page here -
>> http://wiki.ovirt.org/wiki/Features/Vdsm_for_PPC64
>>
>> The vdsm changes are under discussion and can be found here
>> http://gerrit.ovirt.org/7072
>>
>
> was in my queue for a while, finally got to it.
> thanks for the feature page.
> some comments on the text i copy/pasted from the wiki:
>
>> Managing KVM on IBM POWER processors requires changes to both vdsm 
>> and ovirt-engine. However the intent is to keep ovirt-engine changes 
>> to the minimum
>>
>> Following are the key changes that will be required
>>
>>     Enhancing the bootstrapping mechanism in VDSM to handle IBM POWER 
>> processor and ppc64 specifics (like cpuid, cpu speed, cpu flags)
>>     Adding a new CPU type (IBM POWER) to ovirt-engine
>
> so would this be something like intel/amd/ppc7 type of a thing?
> the current cpu types are indeed separated into intel and amd, but 
> this only affects the cpu level compatibility feature at the cluster 
> level.
> but they are both x86_64, so all other aspects of hardware are the 
> same for them.
> i think you need a new 'arch' parameter for cluster.
> then you need the config to be both version and arch dependent, so you 
> could specify things like disk/network/display/audio drives available 
> per version, per arch.
> now i'm not sure i would call this 'arch', since it would make the 
> change to the config too specific, but maybe a more general 'filter' 
> column which allows to specify various filters on the config (arch 
> would be one of them.
> maybe make filter notation a convention of "arch:x86_64" to specify 
> what the filter is about.
>
>>     Enhancing the VM templates based on guest device models (disk, 
>> network, video) supported by KVM on IBM POWER
>>
>> KVM on IBM POWER supports the following device models for guest
>>
>>     virt-io, spapr-vscsi for disk
>>     virt-io, e1000, rtl and spapr-vlan for network
>>     vga device is supported for guest video
>>     Only VNC backend is supported for guest console access.
>>
>> There is currently no support for SPICE protocol and USB support in 
>> guests.
>>
>> Both NFS and SAN storage is supported for the hosts. iSCSI support is 
>> currently work in progress
>> User Interface
>>
>> No new user interfaces are required to be added. However few of the 
>> existing interfaces needs to be updated to reflect KVM on IBM POWER 
>> related specifics.
>
> i think the arch field is needed at cluster, level, but that's indeed 
> a small ui change.
> but you probably also need to add the arch to the VM/template 
> entities, and to the OVF.
> all places using configs (that are relevant) would need to be fixed to 
> use the filter.
> logic of moving VMs between clusters, creation of VMs from template, 
> import/export, etc. would need to validate arch as well.
>
>>
>> At the minimum following user interfaces will be affected
>>
>>     New Server/New Desktop Virtual Machine in userportal
>>     New Server/New Desktop Virtual Machine in webadmin
>>     Make Template in userportal and webadmin
>>     Editing Virtual Disks and Editing Network Interfaces in webadmin
>>     New Cluster in webadmin
>
> so actually, these would be affected in having more options, but these 
> options would come from enum's.
> only change to look and feel of them would probably be the arch field 
> (derived from template/cluster, not something user should be able to 
> set, just view?)
> logic changes would be based on the filtering of relevant values as 
> mentioned above.
>
> thanks,
>    Itamar
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From neo988fa at neowiz.com  Mon Nov  5 03:13:58 2012
From: neo988fa at neowiz.com (=?utf-8?B?7JWIIOykgO2YuA==?=)
Date: Mon, 5 Nov 2012 03:13:58 +0000
Subject: [Q&A] Installing oVirt 3.1 and GPFS
Message-ID: <CD9D8C05CF16BA47A5396F3EF6C7A9485E04BAAC@melon.ds.neowiz.com>

Hello
I?m a Linux System Engineer in Korea.
Sorry but, my English is not good.
Nevertheless, I send a mail to oVirt.org because want to get the solution for my questions
Our team began to design cloud system and chose the KVM for hypervisor / the oVirt for management Tool.
In storage part, we?re going to set-up a distributed storage system like GPFS and GlusterFS.

The oVirt 3.1 supports the POSIX compliant FS.
Thus, we thought that the GPFS can be porting the oVirt engine. For the more, we found that the GPFS can be used for storage on the rhev system docs.


1.     Make Datacenter

-       Name : Datacenter1

-       Type : POSIX compliant FS


2.     Make Clusters

-       Name : Cluster1


3.     Add Hosts

-       Name : kvm1.nwz.kr

-       Mount gpfs at kvm1.nwz.kr -->

-       Filesystem            Size  Used Avail Use% Mounted on

-       /dev/hohogpfs         768G   15G  753G   2% /hohogpfs


4.     Add Storage Domain

-       Name : GPFS1

-       Storage Type : Data / POSIX compliant FS

-       Use Host : kvm1.nwz.kr

-       Path : kvm1.nwz.kr:/hohogpfs

-       VFS : gpfs

However, we failed to porting the GPFS. --> Can we use the GPFS on the oVirt 3.1 ?? / I want to detailed process. / If the oVirt 3.1 has some bugs, I want to get the bug fix.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121105/10068286/attachment.html>

From shaohef at linux.vnet.ibm.com  Wed Nov  7 15:29:36 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Wed, 07 Nov 2012 23:29:36 +0800
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <5098A457.5090302@redhat.com>
References: <508F5F02.2060100@linux.vnet.ibm.com>
	<50988A29.4010802@linux.vnet.ibm.com> <5098A457.5090302@redhat.com>
Message-ID: <509A7E60.4090906@linux.vnet.ibm.com>

On 11/06/2012 01:47 PM, Itamar Heim wrote:
> On 11/06/2012 04:55 AM, Sheldon wrote:
>> On 10/30/2012 01:00 PM, Sheldon wrote:
>>> Looking for some review on this patch.
>>>
>>> http://gerrit.ovirt.org/#/c/7535/
>>>
>>> Thanks.
>>
>> Add a feature page on 
>> wiki.http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device
>
> (moved to arch)
> thanks.
> I'm missing where this will be in the engine dialog (in new/edit vm), 
> and that engine should probably get the log event on the watchdog 
> event, not only vdsm.
>

Watchdog event is very important for high reliability. It can tell 
what's wrong on the guest.

I'm  considering a new patch after this patch was merged. It can support 
a new API or channel to notify the watchdog event to the engine.

Seems there is not an asynchronous event channel for engine.

Maybe a new API for the engine.  Engine can poll it to check the 
watchdog event.

I will discuss it on the ovirt IRC channel  with the engine expert.


Currently, we do not have any plans to implement the engine side of the 
feature.
But I will add a watchdog feature page to describe how engine enable 
this feature. It's definitely great if any engine guy would like to take 
the engine part. I will be glad to provide help if needed.
> thanks,
>    Itamar
>
>>
>>> -- 
>>> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
>>> IBM Linux Technology Center
>>>
>>>
>>> _______________________________________________
>>> vdsm-devel mailing list
>>> vdsm-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>
>>
>> -- 
>> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
>> IBM Linux Technology Center
>>
>>
>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>
>
>


-- 
Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center

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

From iheim at redhat.com  Fri Nov  9 06:35:29 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 09 Nov 2012 07:35:29 +0100
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <509A7B86.4050700@linux.vnet.ibm.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>
Message-ID: <509CA431.8080405@redhat.com>

On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
> Hello all,
>
> I have consolidated the ideas for enabling ppc64 in ovirt-engine in a
> feature page: http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>
> Suggestions and comments are greatly appreciated.

iiuc, the most obvious change to mention is addition of an 'arch' field 
to cluster, which would affect the list of supported cpu families, etc.?
(and to later know to filter all other aspects of entities based on this 
arch field)?

list of possible arch's would be per cluster compatibility level.
i'd expect default for API of this field to be x86_64 for backward 
compatibility, so it is not mandatory.
I'd also prefer this field to be disabled or hidden if there is only one 
option available in it.

it gets more complicated, as VMs can be moved around between clusters, 
exported/imported, etc.

you would need to validate a VM isn't moved to a cluster with a 
different arch, or imported into a cluster with a different arch as well.
(probably more like that).

i assume the config to filter device types per arch like the network 
devices is also for console (spice), audio, etc.

the system already has the concept of filtering per cluster level, so 
filtering per cluster level and arch would mean reviewing all places in 
code for that.


From iheim at redhat.com  Tue Nov 13 06:35:02 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 08:35:02 +0200
Subject: [Q&A] Installing oVirt 3.1 and GPFS
In-Reply-To: <CD9D8C05CF16BA47A5396F3EF6C7A9485E04BAAC@melon.ds.neowiz.com>
References: <CD9D8C05CF16BA47A5396F3EF6C7A9485E04BAAC@melon.ds.neowiz.com>
Message-ID: <50A1EA16.50904@redhat.com>

On 11/05/2012 05:13 AM, ? ?? wrote:
> Hello
>
> I?m a Linux System Engineer in Korea.
>
> Sorry but, my English is not good.
>
> Nevertheless, I send a mail to oVirt.org because want to get the
> solution for my questions
>
> Our team began to design cloud system and chose the KVM for hypervisor /
> the oVirt for management Tool.
>
> In storage part, we?re going to set-up a distributed storage system like
> GPFS and GlusterFS.
>
> The oVirt 3.1 supports the POSIX compliant FS.
>
> Thus, *_we thought that the GPFS can be porting the oVirt engine._* For
> the more, we found that the GPFS can be used for storage on the rhev
> system docs.
>
> 1.Make Datacenter
>
> -Name : Datacenter1
>
> -Type : POSIX compliant FS
>
> 2.Make Clusters
>
> -Name : Cluster1
>
> 3.Add Hosts
>
> -Name : kvm1.nwz.kr
>
> -Mount gpfs at kvm1.nwz.kr ?
>
> -Filesystem            Size  Used Avail Use% Mounted on
>
> -/dev/hohogpfs         768G   15G  753G   2% /hohogpfs
>
> 4.Add Storage Domain
>
> -Name : GPFS1
>
> -*Storage Type : Data / POSIX compliant FS*
>
> -Use Host : kvm1.nwz.kr
>
> -Path : kvm1.nwz.kr:/hohogpfs
>
> -*VFS : gpfs*
>
> *_However, we failed to porting the GPFS._*?*_Can we use the GPFS on the
> oVirt 3.1 ?? / I want to detailed process. / If the oVirt 3.1 has some
> bugs, I want to get the bug fix._*
>
> Thank you.
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

please check if you have this patch in your vdsm:
storage: can't create gpfs domain
http://gerrit.ovirt.org/#/c/8525/



From abaron at redhat.com  Tue Nov 13 06:53:03 2012
From: abaron at redhat.com (Ayal Baron)
Date: Tue, 13 Nov 2012 01:53:03 -0500 (EST)
Subject: [Q&A] Installing oVirt 3.1 and GPFS
In-Reply-To: <50A1EA16.50904@redhat.com>
Message-ID: <1307921878.9681162.1352789583121.JavaMail.root@redhat.com>



----- Original Message -----
> On 11/05/2012 05:13 AM, ? ?? wrote:
> > Hello
> >
> > I?m a Linux System Engineer in Korea.
> >
> > Sorry but, my English is not good.
> >
> > Nevertheless, I send a mail to oVirt.org because want to get the
> > solution for my questions
> >
> > Our team began to design cloud system and chose the KVM for
> > hypervisor /
> > the oVirt for management Tool.
> >
> > In storage part, we?re going to set-up a distributed storage system
> > like
> > GPFS and GlusterFS.
> >
> > The oVirt 3.1 supports the POSIX compliant FS.
> >
> > Thus, *_we thought that the GPFS can be porting the oVirt engine._*
> > For
> > the more, we found that the GPFS can be used for storage on the
> > rhev
> > system docs.
> >
> > 1.Make Datacenter
> >
> > -Name : Datacenter1
> >
> > -Type : POSIX compliant FS
> >
> > 2.Make Clusters
> >
> > -Name : Cluster1
> >
> > 3.Add Hosts
> >
> > -Name : kvm1.nwz.kr
> >
> > -Mount gpfs at kvm1.nwz.kr ?
> >
> > -Filesystem            Size  Used Avail Use% Mounted on
> >
> > -/dev/hohogpfs         768G   15G  753G   2% /hohogpfs
> >
> > 4.Add Storage Domain
> >
> > -Name : GPFS1
> >
> > -*Storage Type : Data / POSIX compliant FS*
> >
> > -Use Host : kvm1.nwz.kr
> >
> > -Path : kvm1.nwz.kr:/hohogpfs
> >
> > -*VFS : gpfs*
> >
> > *_However, we failed to porting the GPFS._*?*_Can we use the GPFS
> > on the
> > oVirt 3.1 ?? / I want to detailed process. / If the oVirt 3.1 has
> > some
> > bugs, I want to get the bug fix._*
> >
> > Thank you.
> >
> >
> >
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
> 
> please check if you have this patch in your vdsm:
> storage: can't create gpfs domain
> http://gerrit.ovirt.org/#/c/8525/
> 
> 

Also note that oVirt currently has to mount the filesystem itself.


From iheim at redhat.com  Tue Nov 13 07:05:37 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 09:05:37 +0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <509CA431.8080405@redhat.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com> <509CA431.8080405@redhat.com>
Message-ID: <50A1F141.9010500@redhat.com>

On 11/09/2012 08:35 AM, Itamar Heim wrote:
> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>> Hello all,
>>
>> I have consolidated the ideas for enabling ppc64 in ovirt-engine in a
>> feature page:
>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>
>> Suggestions and comments are greatly appreciated.
>
> iiuc, the most obvious change to mention is addition of an 'arch' field
> to cluster, which would affect the list of supported cpu families, etc.?
> (and to later know to filter all other aspects of entities based on this
> arch field)?
>
> list of possible arch's would be per cluster compatibility level.
> i'd expect default for API of this field to be x86_64 for backward
> compatibility, so it is not mandatory.
> I'd also prefer this field to be disabled or hidden if there is only one
> option available in it.
>
> it gets more complicated, as VMs can be moved around between clusters,
> exported/imported, etc.
>
> you would need to validate a VM isn't moved to a cluster with a
> different arch, or imported into a cluster with a different arch as well.
> (probably more like that).
>
> i assume the config to filter device types per arch like the network
> devices is also for console (spice), audio, etc.
>
> the system already has the concept of filtering per cluster level, so
> filtering per cluster level and arch would mean reviewing all places in
> code for that.

I'm adding roy/omer/michal as the work on libosinfo (patches in 
gerrit[1]) seems to make some of these changes not needed (if it is merged).
rather just need to extend libosinfo with the information on ppc.

for sure worth reviewing both approaches to make sure the chosen 
solution benefits both and we collaborate on same end goal.

[1] some of the patches are:
http://gerrit.ovirt.org/9065
http://gerrit.ovirt.org/9063
http://gerrit.ovirt.org/9049


From alonbl at redhat.com  Tue Nov 13 11:52:13 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 13 Nov 2012 06:52:13 -0500 (EST)
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <714689127.8271667.1352669109371.JavaMail.root@redhat.com>
Message-ID: <1160825470.8583546.1352807533048.JavaMail.root@redhat.com>

Hello All,

I am working on rewriting the vdsm-bootstrap process.

I found that most of the installer implementation is not vdsm specific, so I split the package into two:

 core installer
 vdsm-bootstrap

I would like to find a suitable name for the core installer.

In nat shell:
"""
Standalone plugin based installation framework to be used to setup
system components. The plugin nature provides simplicity to
add new installation functionality without the complexity of the state
and transaction management.

At the core of the implementation there is environment dictionary and
a flow of stages within plugins. The environment can be modified using
command-line parameters, configuration file, or dialog customization.
""" 

Sources are available at temporary location[1].

Names that we thought of:
1. ovirt-installer
2. virtulation (virtualization + installation)
3. virtaller (virtualization + installation)
4. TOPI (Task Oriented Pluggable Installer/Implementation)
5. PDF (Pluggable Deployment Framework)

I would also like to consider if we want to keep the vdsm-bootstrap name for the bootstrap package, or we should use something more generic, as it really bootstrap the host and not vdsm...:
1. ovirt-hypervisor-bootstrap
2. ovirt-host-setup
3. ovirt-deployer

Any other idea will be most welcome, we need to close this fast to progress.

Best Regards,
Alon Bar-Lev

[1] https://github.com/alonbl/ovirt-installer


From ppinatti at linux.vnet.ibm.com  Tue Nov 13 12:02:44 2012
From: ppinatti at linux.vnet.ibm.com (Paulo de Rezende Pinatti)
Date: Tue, 13 Nov 2012 10:02:44 -0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50A1F141.9010500@redhat.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>
	<509CA431.8080405@redhat.com> <50A1F141.9010500@redhat.com>
Message-ID: <50A236E4.1070304@linux.vnet.ibm.com>

On 11/13/2012 05:05 AM, Itamar Heim wrote:
> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>> Hello all,
>>>
>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine in a
>>> feature page:
>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>
>>> Suggestions and comments are greatly appreciated.
>>
>> iiuc, the most obvious change to mention is addition of an 'arch' field
>> to cluster, which would affect the list of supported cpu families, etc.?
>> (and to later know to filter all other aspects of entities based on this
>> arch field)?
>>
>> list of possible arch's would be per cluster compatibility level.
>> i'd expect default for API of this field to be x86_64 for backward
>> compatibility, so it is not mandatory.
>> I'd also prefer this field to be disabled or hidden if there is only one
>> option available in it.
>>
>> it gets more complicated, as VMs can be moved around between clusters,
>> exported/imported, etc.
>>
>> you would need to validate a VM isn't moved to a cluster with a
>> different arch, or imported into a cluster with a different arch as 
>> well.
>> (probably more like that).
>>
>> i assume the config to filter device types per arch like the network
>> devices is also for console (spice), audio, etc.
>>
>> the system already has the concept of filtering per cluster level, so
>> filtering per cluster level and arch would mean reviewing all places in
>> code for that.
>
> I'm adding roy/omer/michal as the work on libosinfo (patches in 
> gerrit[1]) seems to make some of these changes not needed (if it is 
> merged).
> rather just need to extend libosinfo with the information on ppc.
>
> for sure worth reviewing both approaches to make sure the chosen 
> solution benefits both and we collaborate on same end goal.

thanks, we will check these patches and possibly change the approach to 
use libosinfo.


>
> [1] some of the patches are:
> http://gerrit.ovirt.org/9065
> http://gerrit.ovirt.org/9063
> http://gerrit.ovirt.org/9049
>



From iheim at redhat.com  Tue Nov 13 16:21:15 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Nov 2012 18:21:15 +0200
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <1160825470.8583546.1352807533048.JavaMail.root@redhat.com>
References: <1160825470.8583546.1352807533048.JavaMail.root@redhat.com>
Message-ID: <50A2737B.7090808@redhat.com>

On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
> Hello All,
>
> I am working on rewriting the vdsm-bootstrap process.
>
> I found that most of the installer implementation is not vdsm specific, so I split the package into two:
>
>   core installer
>   vdsm-bootstrap
>
> I would like to find a suitable name for the core installer.
>
> In nat shell:
> """
> Standalone plugin based installation framework to be used to setup
> system components. The plugin nature provides simplicity to
> add new installation functionality without the complexity of the state
> and transaction management.
>
> At the core of the implementation there is environment dictionary and
> a flow of stages within plugins. The environment can be modified using
> command-line parameters, configuration file, or dialog customization.
> """
>
> Sources are available at temporary location[1].
>
> Names that we thought of:
> 1. ovirt-installer

hmmm, that's between being generic, and consumable by others.
question is how problematic it is if we keep our name...
would be nice if we can advertise ourselves a bit.
maybe we can compromise on:
ogi - ovirt generic installer

so name isn't directly with ovirt, but some marketing of ovirt from it 
may happen.

so +1 to OGI from me.

> 2. virtulation (virtualization + installation)
> 3. virtaller (virtualization + installation)
> 4. TOPI (Task Oriented Pluggable Installer/Implementation)

+1

hmmm, spinning #1:
OTOPI.
has a nice ring to it around utopia as well.


> 5. PDF (Pluggable Deployment Framework)

-1 due to PDF so widely known as something else

>
> I would also like to consider if we want to keep the vdsm-bootstrap name for the bootstrap package, or we should use something more generic, as it really bootstrap the host and not vdsm...:
> 1. ovirt-hypervisor-bootstrap
> 2. ovirt-host-setup

+1 to this one. not sure if critical to rename the rpm though.

> 3. ovirt-deployer
>
> Any other idea will be most welcome, we need to close this fast to progress.
>
> Best Regards,
> Alon Bar-Lev
>
> [1] https://github.com/alonbl/ovirt-installer
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>




From vfeenstr at redhat.com  Tue Nov 13 17:18:23 2012
From: vfeenstr at redhat.com (Vinzenz Feenstra)
Date: Tue, 13 Nov 2012 18:18:23 +0100
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <50A2737B.7090808@redhat.com>
References: <1160825470.8583546.1352807533048.JavaMail.root@redhat.com>
	<50A2737B.7090808@redhat.com>
Message-ID: <50A280DF.2010506@redhat.com>

On 11/13/2012 05:21 PM, Itamar Heim wrote:
> On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
>> Hello All,
>>
>> I am working on rewriting the vdsm-bootstrap process.
>>
>> I found that most of the installer implementation is not vdsm 
>> specific, so I split the package into two:
>>
>>   core installer
>>   vdsm-bootstrap
>>
>> I would like to find a suitable name for the core installer.
>>
>> In nat shell:
>> """
>> Standalone plugin based installation framework to be used to setup
>> system components. The plugin nature provides simplicity to
>> add new installation functionality without the complexity of the state
>> and transaction management.
>>
>> At the core of the implementation there is environment dictionary and
>> a flow of stages within plugins. The environment can be modified using
>> command-line parameters, configuration file, or dialog customization.
>> """
>>
>> Sources are available at temporary location[1].
>>
>> Names that we thought of:
>> 1. ovirt-installer
>
> hmmm, that's between being generic, and consumable by others.
> question is how problematic it is if we keep our name...
> would be nice if we can advertise ourselves a bit.
> maybe we can compromise on:
> ogi - ovirt generic installer
>
> so name isn't directly with ovirt, but some marketing of ovirt from it 
> may happen.
>
> so +1 to OGI from me.
>
>> 2. virtulation (virtualization + installation)
>> 3. virtaller (virtualization + installation)
>> 4. TOPI (Task Oriented Pluggable Installer/Implementation)
>
> +1
>
> hmmm, spinning #1:
> OTOPI.
> has a nice ring to it around utopia as well.
>
>
>> 5. PDF (Pluggable Deployment Framework)
>
> -1 due to PDF so widely known as something else
>
>>
>> I would also like to consider if we want to keep the vdsm-bootstrap 
>> name for the bootstrap package, or we should use something more 
>> generic, as it really bootstrap the host and not vdsm...:
>> 1. ovirt-hypervisor-bootstrap
>> 2. ovirt-host-setup
>
> +1 to this one. not sure if critical to rename the rpm though.
+1  for this one
>
>> 3. ovirt-deployer
>>
>> Any other idea will be most welcome, we need to close this fast to 
>> progress.
>>
>> Best Regards,
>> Alon Bar-Lev
>>
>> [1] https://github.com/alonbl/ovirt-installer
>> _______________________________________________

I would not call it just 'ovirt-installer' this is totally misleading. 
Also the name play does not make sense.
If you want to give it some cosy name, go ahead, but 'ovirt-installer' 
for example is counter intuitive and would suggest a full fledged 
installation of the engine, node...

-- 
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From agl at us.ibm.com  Tue Nov 13 20:20:21 2012
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 13 Nov 2012 14:20:21 -0600
Subject: Barcelona workshop slides
Message-ID: <20121113202021.GA3148@aglitke>

I want to start by saying Thank You! to the organizers and other presenters at
the oVirt Workshop in Barcelona.  I really enjoyed the event and found so many
of the presentations to be interesting and informative.

That being said, it would be fantastic if we could share the presentations with
those who were not able to attend.  Is there an active effort to gather all of
the slides from presenters so that they can be put up on the wiki?  I know some
folks sent slides out to the workshop-pc list.

If you presented and have not sent out your slides, could you do that now?  I
would be happy to collect them from the list and post them to a wiki page if we
all agree that is the best place to host them.

Comments, acks, nacks?

The mailing list address is: workshop-pc at ovirt.org

Thanks again for a great workshop.  I enjoyed the chance to reconnect with some
of you and also to meet some of you for the first time.

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



From iheim at redhat.com  Wed Nov 14 04:31:58 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Nov 2012 06:31:58 +0200
Subject: Barcelona workshop slides
In-Reply-To: <20121113202021.GA3148@aglitke>
References: <20121113202021.GA3148@aglitke>
Message-ID: <50A31EBE.4030308@redhat.com>

On 11/13/2012 10:20 PM, Adam Litke wrote:
> I want to start by saying Thank You! to the organizers and other presenters at
> the oVirt Workshop in Barcelona.  I really enjoyed the event and found so many
> of the presentations to be interesting and informative.
>
> That being said, it would be fantastic if we could share the presentations with
> those who were not able to attend.  Is there an active effort to gather all of
> the slides from presenters so that they can be put up on the wiki?  I know some
> folks sent slides out to the workshop-pc list.
>
> If you presented and have not sent out your slides, could you do that now?  I
> would be happy to collect them from the list and post them to a wiki page if we
> all agree that is the best place to host them.

it is.

>
> Comments, acks, nacks?
>
> The mailing list address is: workshop-pc at ovirt.org
>
> Thanks again for a great workshop.  I enjoyed the chance to reconnect with some
> of you and also to meet some of you for the first time.
>

i believe dave neary has been collecting them for posting them on the 
web site, but i'm sure he'll be happy if you'll do it as well.
whoever it is, just ping anyone for missing slides (I sent dave mine, 
can send them again if needed to you)


From dneary at redhat.com  Wed Nov 14 08:33:21 2012
From: dneary at redhat.com (Dave Neary)
Date: Wed, 14 Nov 2012 09:33:21 +0100
Subject: Barcelona workshop slides
In-Reply-To: <20121113202021.GA3148@aglitke>
References: <20121113202021.GA3148@aglitke>
Message-ID: <50A35751.7020204@redhat.com>

Hi Adam,

On 11/13/2012 09:20 PM, Adam Litke wrote:
> I want to start by saying Thank You! to the organizers and other presenters at
> the oVirt Workshop in Barcelona.  I really enjoyed the event and found so many
> of the presentations to be interesting and informative.
>
> That being said, it would be fantastic if we could share the presentations with
> those who were not able to attend.  Is there an active effort to gather all of
> the slides from presenters so that they can be put up on the wiki?  I know some
> folks sent slides out to the workshop-pc list.
>
> If you presented and have not sent out your slides, could you do that now?  I
> would be happy to collect them from the list and post them to a wiki page if we
> all agree that is the best place to host them.
>
> Comments, acks, nacks?

I plan to gather all the presentations on the wiki this week - it will 
be today or tomorrow, depending on how quickly I get through another 
couple of things.

We could just create the wiki page now, and add a cell to the schedule 
table for the Bangalore workshop, and let other people attach their 
presentation files if they get to it before me... which sounds like a 
good idea.

Definitely an ack from me!

Cheers,
Dave.

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


From neo988fa at neowiz.com  Thu Nov 15 02:53:44 2012
From: neo988fa at neowiz.com (=?utf-8?B?7JWIIOykgO2YuA==?=)
Date: Thu, 15 Nov 2012 02:53:44 +0000
Subject: [Q&A] Installing oVirt 3.1 and GPFS
In-Reply-To: <1307921878.9681162.1352789583121.JavaMail.root@redhat.com>
References: <50A1EA16.50904@redhat.com>
	<1307921878.9681162.1352789583121.JavaMail.root@redhat.com>
Message-ID: <CD9D8C05CF16BA47A5396F3EF6C7A9485E0576FE@melon.ds.neowiz.com>

I'd appreciate your reply.
Sorry but I have another question about VLAN.

Our network is comprised of VLAN.
Furthermore, the network is separate to 2 parts.

First part is the Internal Network.
We have to configure the eth0 interface for private communication in the servers. (IP : 10.X.X.X)
Second part is the External Network.
We must set-up the eth1 interface for public communication in the servers. (IP : 172.X.X.X)

I attach a jpg file about sketching for all interfaces in the servers.
A VM has 2 network interfaces and VLAN 175.

Question)
Single Interface is OK. (eth0 -- eth0.175 -- br0175 -- vnet0)
I want to use the eth1 interface, however, can't register bridge interface br1175 in the oVirt.
Because of the VLAN 175 is already registered number for eth0.

How do I register and assign two bridge interfaces with the same VLAN number ?


-----Original Message-----
From: Ayal Baron [mailto:abaron at redhat.com] 
Sent: Tuesday, November 13, 2012 3:53 PM
To: Itamar Heim
Cc: arch at oVirt.org; Greg Padgett; ? ??
Subject: Re: [Q&A] Installing oVirt 3.1 and GPFS



----- Original Message -----
> On 11/05/2012 05:13 AM, ? ?? wrote:
> > Hello
> >
> > I?m a Linux System Engineer in Korea.
> >
> > Sorry but, my English is not good.
> >
> > Nevertheless, I send a mail to oVirt.org because want to get the 
> > solution for my questions
> >
> > Our team began to design cloud system and chose the KVM for 
> > hypervisor / the oVirt for management Tool.
> >
> > In storage part, we?re going to set-up a distributed storage system 
> > like GPFS and GlusterFS.
> >
> > The oVirt 3.1 supports the POSIX compliant FS.
> >
> > Thus, *_we thought that the GPFS can be porting the oVirt engine._* 
> > For the more, we found that the GPFS can be used for storage on the 
> > rhev system docs.
> >
> > 1.Make Datacenter
> >
> > -Name : Datacenter1
> >
> > -Type : POSIX compliant FS
> >
> > 2.Make Clusters
> >
> > -Name : Cluster1
> >
> > 3.Add Hosts
> >
> > -Name : kvm1.nwz.kr
> >
> > -Mount gpfs at kvm1.nwz.kr ?
> >
> > -Filesystem            Size  Used Avail Use% Mounted on
> >
> > -/dev/hohogpfs         768G   15G  753G   2% /hohogpfs
> >
> > 4.Add Storage Domain
> >
> > -Name : GPFS1
> >
> > -*Storage Type : Data / POSIX compliant FS*
> >
> > -Use Host : kvm1.nwz.kr
> >
> > -Path : kvm1.nwz.kr:/hohogpfs
> >
> > -*VFS : gpfs*
> >
> > *_However, we failed to porting the GPFS._*?*_Can we use the GPFS on 
> > the oVirt 3.1 ?? / I want to detailed process. / If the oVirt 3.1 
> > has some bugs, I want to get the bug fix._*
> >
> > Thank you.
> >
> >
> >
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
> 
> please check if you have this patch in your vdsm:
> storage: can't create gpfs domain
> http://gerrit.ovirt.org/#/c/8525/
> 
> 

Also note that oVirt currently has to mount the filesystem itself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kvm.jpg
Type: image/jpeg
Size: 41681 bytes
Desc: kvm.jpg
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121115/eba7e316/attachment.jpg>

From iheim at redhat.com  Thu Nov 15 03:15:40 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Nov 2012 05:15:40 +0200
Subject: internal and external interfaces/ (was VLANs  [Q&A] Installing
	oVirt 3.1 and GPFS)
In-Reply-To: <CD9D8C05CF16BA47A5396F3EF6C7A9485E0576FE@melon.ds.neowiz.com>
References: <50A1EA16.50904@redhat.com>
	<1307921878.9681162.1352789583121.JavaMail.root@redhat.com>
	<CD9D8C05CF16BA47A5396F3EF6C7A9485E0576FE@melon.ds.neowiz.com>
Message-ID: <50A45E5C.7070903@redhat.com>

On 11/15/2012 04:53 AM, ? ?? wrote:
> I'd appreciate your reply.
> Sorry but I have another question about VLAN.

tip: in the future, i suggest sending a new email for a new topic.
it will both have a better eye catching subject, and will also not hide 
inside the GPFS thread which the networks folks may be less interested in.

>
> Our network is comprised of VLAN.
> Furthermore, the network is separate to 2 parts.
>
> First part is the Internal Network.
> We have to configure the eth0 interface for private communication in the servers. (IP : 10.X.X.X)
> Second part is the External Network.
> We must set-up the eth1 interface for public communication in the servers. (IP : 172.X.X.X)
>
> I attach a jpg file about sketching for all interfaces in the servers.
> A VM has 2 network interfaces and VLAN 175.
>
> Question)
> Single Interface is OK. (eth0 -- eth0.175 -- br0175 -- vnet0)
> I want to use the eth1 interface, however, can't register bridge interface br1175 in the oVirt.
> Because of the VLAN 175 is already registered number for eth0.
>
> How do I register and assign two bridge interfaces with the same VLAN number ?

that's an interesting use case, i don't think we encountered same vlan 
number in separate physical networks in same data center.
just wondering, any reason the vlan number is identical between internal 
and external networks (i mean, it is obviously not really the same vlan, 
as these are physically separate networks)?


>
>
> -----Original Message-----
> From: Ayal Baron [mailto:abaron at redhat.com]
> Sent: Tuesday, November 13, 2012 3:53 PM
> To: Itamar Heim
> Cc: arch at oVirt.org; Greg Padgett; ? ??
> Subject: Re: [Q&A] Installing oVirt 3.1 and GPFS
>
>
>
> ----- Original Message -----
>> On 11/05/2012 05:13 AM, ? ?? wrote:
>>> Hello
>>>
>>> I?m a Linux System Engineer in Korea.
>>>
>>> Sorry but, my English is not good.
>>>
>>> Nevertheless, I send a mail to oVirt.org because want to get the
>>> solution for my questions
>>>
>>> Our team began to design cloud system and chose the KVM for
>>> hypervisor / the oVirt for management Tool.
>>>
>>> In storage part, we?re going to set-up a distributed storage system
>>> like GPFS and GlusterFS.
>>>
>>> The oVirt 3.1 supports the POSIX compliant FS.
>>>
>>> Thus, *_we thought that the GPFS can be porting the oVirt engine._*
>>> For the more, we found that the GPFS can be used for storage on the
>>> rhev system docs.
>>>
>>> 1.Make Datacenter
>>>
>>> -Name : Datacenter1
>>>
>>> -Type : POSIX compliant FS
>>>
>>> 2.Make Clusters
>>>
>>> -Name : Cluster1
>>>
>>> 3.Add Hosts
>>>
>>> -Name : kvm1.nwz.kr
>>>
>>> -Mount gpfs at kvm1.nwz.kr ?
>>>
>>> -Filesystem            Size  Used Avail Use% Mounted on
>>>
>>> -/dev/hohogpfs         768G   15G  753G   2% /hohogpfs
>>>
>>> 4.Add Storage Domain
>>>
>>> -Name : GPFS1
>>>
>>> -*Storage Type : Data / POSIX compliant FS*
>>>
>>> -Use Host : kvm1.nwz.kr
>>>
>>> -Path : kvm1.nwz.kr:/hohogpfs
>>>
>>> -*VFS : gpfs*
>>>
>>> *_However, we failed to porting the GPFS._*?*_Can we use the GPFS on
>>> the oVirt 3.1 ?? / I want to detailed process. / If the oVirt 3.1
>>> has some bugs, I want to get the bug fix._*
>>>
>>> Thank you.
>>>
>>>
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
>> please check if you have this patch in your vdsm:
>> storage: can't create gpfs domain
>> http://gerrit.ovirt.org/#/c/8525/
>>
>>
>
> Also note that oVirt currently has to mount the filesystem itself.
>




From alonbl at redhat.com  Thu Nov 15 10:22:47 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 15 Nov 2012 05:22:47 -0500 (EST)
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <50A2737B.7090808@redhat.com>
Message-ID: <1903144707.9029887.1352974967951.JavaMail.root@redhat.com>

OK, we need to close this up...

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Tuesday, November 13, 2012 6:21:15 PM
> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> 
> On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
> > Hello All,
> >
> > I am working on rewriting the vdsm-bootstrap process.
> >
> > I found that most of the installer implementation is not vdsm
> > specific, so I split the package into two:
> >
> >   core installer
> >   vdsm-bootstrap
> >
> > I would like to find a suitable name for the core installer.
> >
> > In nat shell:
> > """
> > Standalone plugin based installation framework to be used to setup
> > system components. The plugin nature provides simplicity to
> > add new installation functionality without the complexity of the
> > state
> > and transaction management.
> >
> > At the core of the implementation there is environment dictionary
> > and
> > a flow of stages within plugins. The environment can be modified
> > using
> > command-line parameters, configuration file, or dialog
> > customization.
> > """
> >
> > Sources are available at temporary location[1].
> >
> > Names that we thought of:
> > 1. ovirt-installer
> 
> hmmm, that's between being generic, and consumable by others.
> question is how problematic it is if we keep our name...
> would be nice if we can advertise ourselves a bit.
> maybe we can compromise on:
> ogi - ovirt generic installer
> 
> so name isn't directly with ovirt, but some marketing of ovirt from
> it
> may happen.
> 
> so +1 to OGI from me.
> 
> > 2. virtulation (virtualization + installation)
> > 3. virtaller (virtualization + installation)
> > 4. TOPI (Task Oriented Pluggable Installer/Implementation)
> 
> +1
> 
> hmmm, spinning #1:
> OTOPI.
> has a nice ring to it around utopia as well.
>

So OTOPI it is, well actually lower case otopi.

> 
> > 5. PDF (Pluggable Deployment Framework)
> 
> -1 due to PDF so widely known as something else
> 
> >
> > I would also like to consider if we want to keep the vdsm-bootstrap
> > name for the bootstrap package, or we should use something more
> > generic, as it really bootstrap the host and not vdsm...:
> > 1. ovirt-hypervisor-bootstrap
> > 2. ovirt-host-setup
> 
> +1 to this one. not sure if critical to rename the rpm though.

I think that with all alternatives, renaming the package will make it easy procedurally.
As the old ovirt-engine will continue to pull the existing packages.
We do not need to handle conflicts or breakage.

So can we close up with ovirt-host-setup?
I personally, think ovirt-host-deploy is better than setup.

> 
> > 3. ovirt-deployer
> >
> > Any other idea will be most welcome, we need to close this fast to
> > progress.
> >
> > Best Regards,
> > Alon Bar-Lev

Thanks!
Alon


From iheim at redhat.com  Thu Nov 15 10:25:13 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Nov 2012 12:25:13 +0200
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <1903144707.9029887.1352974967951.JavaMail.root@redhat.com>
References: <1903144707.9029887.1352974967951.JavaMail.root@redhat.com>
Message-ID: <50A4C309.8060505@redhat.com>

On 11/15/2012 12:22 PM, Alon Bar-Lev wrote:
> OK, we need to close this up...
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "arch" <arch at ovirt.org>
>> Sent: Tuesday, November 13, 2012 6:21:15 PM
>> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
>>
>> On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
>>> Hello All,
>>>
>>> I am working on rewriting the vdsm-bootstrap process.
>>>
>>> I found that most of the installer implementation is not vdsm
>>> specific, so I split the package into two:
>>>
>>>    core installer
>>>    vdsm-bootstrap
>>>
>>> I would like to find a suitable name for the core installer.
>>>
>>> In nat shell:
>>> """
>>> Standalone plugin based installation framework to be used to setup
>>> system components. The plugin nature provides simplicity to
>>> add new installation functionality without the complexity of the
>>> state
>>> and transaction management.
>>>
>>> At the core of the implementation there is environment dictionary
>>> and
>>> a flow of stages within plugins. The environment can be modified
>>> using
>>> command-line parameters, configuration file, or dialog
>>> customization.
>>> """
>>>
>>> Sources are available at temporary location[1].
>>>
>>> Names that we thought of:
>>> 1. ovirt-installer
>>
>> hmmm, that's between being generic, and consumable by others.
>> question is how problematic it is if we keep our name...
>> would be nice if we can advertise ourselves a bit.
>> maybe we can compromise on:
>> ogi - ovirt generic installer
>>
>> so name isn't directly with ovirt, but some marketing of ovirt from
>> it
>> may happen.
>>
>> so +1 to OGI from me.
>>
>>> 2. virtulation (virtualization + installation)
>>> 3. virtaller (virtualization + installation)
>>> 4. TOPI (Task Oriented Pluggable Installer/Implementation)
>>
>> +1
>>
>> hmmm, spinning #1:
>> OTOPI.
>> has a nice ring to it around utopia as well.
>>
>
> So OTOPI it is, well actually lower case otopi.
>
>>
>>> 5. PDF (Pluggable Deployment Framework)
>>
>> -1 due to PDF so widely known as something else
>>
>>>
>>> I would also like to consider if we want to keep the vdsm-bootstrap
>>> name for the bootstrap package, or we should use something more
>>> generic, as it really bootstrap the host and not vdsm...:
>>> 1. ovirt-hypervisor-bootstrap
>>> 2. ovirt-host-setup
>>
>> +1 to this one. not sure if critical to rename the rpm though.
>
> I think that with all alternatives, renaming the package will make it easy procedurally.
> As the old ovirt-engine will continue to pull the existing packages.
> We do not need to handle conflicts or breakage.
>
> So can we close up with ovirt-host-setup?
> I personally, think ovirt-host-deploy is better than setup.

i'm fine either way.

>
>>
>>> 3. ovirt-deployer
>>>
>>> Any other idea will be most welcome, we need to close this fast to
>>> progress.
>>>
>>> Best Regards,
>>> Alon Bar-Lev
>
> Thanks!
> Alon
>




From alonbl at redhat.com  Thu Nov 15 10:34:42 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 15 Nov 2012 05:34:42 -0500 (EST)
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <50A4C309.8060505@redhat.com>
Message-ID: <37776249.9030422.1352975682250.JavaMail.root@redhat.com>

Hello,

Summary:

Common infrastructure:
OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.

Deploy code (vdsm-bootstrap):
ovirt-host-deploy

I want to close this by Sunday to perform the rename, split, create repositories etc...

So if anyone has more ideas, please raise a flags as after renaming it will be very difficult to change.

Thanks,
Alon

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, November 15, 2012 12:25:13 PM
> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> 
> On 11/15/2012 12:22 PM, Alon Bar-Lev wrote:
> > OK, we need to close this up...
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "arch" <arch at ovirt.org>
> >> Sent: Tuesday, November 13, 2012 6:21:15 PM
> >> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> >>
> >> On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
> >>> Hello All,
> >>>
> >>> I am working on rewriting the vdsm-bootstrap process.
> >>>
> >>> I found that most of the installer implementation is not vdsm
> >>> specific, so I split the package into two:
> >>>
> >>>    core installer
> >>>    vdsm-bootstrap
> >>>
> >>> I would like to find a suitable name for the core installer.
> >>>
> >>> In nat shell:
> >>> """
> >>> Standalone plugin based installation framework to be used to
> >>> setup
> >>> system components. The plugin nature provides simplicity to
> >>> add new installation functionality without the complexity of the
> >>> state
> >>> and transaction management.
> >>>
> >>> At the core of the implementation there is environment dictionary
> >>> and
> >>> a flow of stages within plugins. The environment can be modified
> >>> using
> >>> command-line parameters, configuration file, or dialog
> >>> customization.
> >>> """
> >>>
> >>> Sources are available at temporary location[1].
> >>>
> >>> Names that we thought of:
> >>> 1. ovirt-installer
> >>
> >> hmmm, that's between being generic, and consumable by others.
> >> question is how problematic it is if we keep our name...
> >> would be nice if we can advertise ourselves a bit.
> >> maybe we can compromise on:
> >> ogi - ovirt generic installer
> >>
> >> so name isn't directly with ovirt, but some marketing of ovirt
> >> from
> >> it
> >> may happen.
> >>
> >> so +1 to OGI from me.
> >>
> >>> 2. virtulation (virtualization + installation)
> >>> 3. virtaller (virtualization + installation)
> >>> 4. TOPI (Task Oriented Pluggable Installer/Implementation)
> >>
> >> +1
> >>
> >> hmmm, spinning #1:
> >> OTOPI.
> >> has a nice ring to it around utopia as well.
> >>
> >
> > So OTOPI it is, well actually lower case otopi.
> >
> >>
> >>> 5. PDF (Pluggable Deployment Framework)
> >>
> >> -1 due to PDF so widely known as something else
> >>
> >>>
> >>> I would also like to consider if we want to keep the
> >>> vdsm-bootstrap
> >>> name for the bootstrap package, or we should use something more
> >>> generic, as it really bootstrap the host and not vdsm...:
> >>> 1. ovirt-hypervisor-bootstrap
> >>> 2. ovirt-host-setup
> >>
> >> +1 to this one. not sure if critical to rename the rpm though.
> >
> > I think that with all alternatives, renaming the package will make
> > it easy procedurally.
> > As the old ovirt-engine will continue to pull the existing
> > packages.
> > We do not need to handle conflicts or breakage.
> >
> > So can we close up with ovirt-host-setup?
> > I personally, think ovirt-host-deploy is better than setup.
> 
> i'm fine either way.

Great!
So ovirt-host-deploy it is.

> 
> >
> >>
> >>> 3. ovirt-deployer
> >>>
> >>> Any other idea will be most welcome, we need to close this fast
> >>> to
> >>> progress.
> >>>
> >>> Best Regards,
> >>> Alon Bar-Lev
> >
> > Thanks!
> > Alon
> >
> 
> 
> 


From derekh at redhat.com  Thu Nov 15 10:40:52 2012
From: derekh at redhat.com (Derek Higgins)
Date: Thu, 15 Nov 2012 10:40:52 +0000
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <37776249.9030422.1352975682250.JavaMail.root@redhat.com>
References: <37776249.9030422.1352975682250.JavaMail.root@redhat.com>
Message-ID: <50A4C6B4.1000906@redhat.com>

On 11/15/2012 10:34 AM, Alon Bar-Lev wrote:
> Hello,
> 
> Summary:
> 
> Common infrastructure:
> OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.

I'll be porting packstack[1] at some stage to use this, otopi looks like
a good name to me

[1] https://github.com/derekhiggins/packstack

> 
> Deploy code (vdsm-bootstrap):
> ovirt-host-deploy
> 
> I want to close this by Sunday to perform the rename, split, create repositories etc...
> 
> So if anyone has more ideas, please raise a flags as after renaming it will be very difficult to change.
> 
> Thanks,
> Alon



From alonbl at redhat.com  Thu Nov 15 11:14:52 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 15 Nov 2012 06:14:52 -0500 (EST)
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <37776249.9030422.1352975682250.JavaMail.root@redhat.com>
Message-ID: <2115911145.9035492.1352978092337.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, November 15, 2012 12:34:42 PM
> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> 
> Hello,
> 
> Summary:
> 
> Common infrastructure:
> OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.
> 
> Deploy code (vdsm-bootstrap):
> ovirt-host-deploy
> 
> I want to close this by Sunday to perform the rename, split, create
> repositories etc...
> 
> So if anyone has more ideas, please raise a flags as after renaming
> it will be very difficult to change.
> 
> Thanks,
> Alon

I forgot we need a namespace for the core specific java resources.

Should it be org.ovirt.otopi or drop the ovirt in favour of org.otopi?

Thanks,
Alon.

> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Thursday, November 15, 2012 12:25:13 PM
> > Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> > 
> > On 11/15/2012 12:22 PM, Alon Bar-Lev wrote:
> > > OK, we need to close this up...
> > >
> > > ----- Original Message -----
> > >> From: "Itamar Heim" <iheim at redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> Cc: "arch" <arch at ovirt.org>
> > >> Sent: Tuesday, November 13, 2012 6:21:15 PM
> > >> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> > >>
> > >> On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
> > >>> Hello All,
> > >>>
> > >>> I am working on rewriting the vdsm-bootstrap process.
> > >>>
> > >>> I found that most of the installer implementation is not vdsm
> > >>> specific, so I split the package into two:
> > >>>
> > >>>    core installer
> > >>>    vdsm-bootstrap
> > >>>
> > >>> I would like to find a suitable name for the core installer.
> > >>>
> > >>> In nat shell:
> > >>> """
> > >>> Standalone plugin based installation framework to be used to
> > >>> setup
> > >>> system components. The plugin nature provides simplicity to
> > >>> add new installation functionality without the complexity of
> > >>> the
> > >>> state
> > >>> and transaction management.
> > >>>
> > >>> At the core of the implementation there is environment
> > >>> dictionary
> > >>> and
> > >>> a flow of stages within plugins. The environment can be
> > >>> modified
> > >>> using
> > >>> command-line parameters, configuration file, or dialog
> > >>> customization.
> > >>> """
> > >>>
> > >>> Sources are available at temporary location[1].
> > >>>
> > >>> Names that we thought of:
> > >>> 1. ovirt-installer
> > >>
> > >> hmmm, that's between being generic, and consumable by others.
> > >> question is how problematic it is if we keep our name...
> > >> would be nice if we can advertise ourselves a bit.
> > >> maybe we can compromise on:
> > >> ogi - ovirt generic installer
> > >>
> > >> so name isn't directly with ovirt, but some marketing of ovirt
> > >> from
> > >> it
> > >> may happen.
> > >>
> > >> so +1 to OGI from me.
> > >>
> > >>> 2. virtulation (virtualization + installation)
> > >>> 3. virtaller (virtualization + installation)
> > >>> 4. TOPI (Task Oriented Pluggable Installer/Implementation)
> > >>
> > >> +1
> > >>
> > >> hmmm, spinning #1:
> > >> OTOPI.
> > >> has a nice ring to it around utopia as well.
> > >>
> > >
> > > So OTOPI it is, well actually lower case otopi.
> > >
> > >>
> > >>> 5. PDF (Pluggable Deployment Framework)
> > >>
> > >> -1 due to PDF so widely known as something else
> > >>
> > >>>
> > >>> I would also like to consider if we want to keep the
> > >>> vdsm-bootstrap
> > >>> name for the bootstrap package, or we should use something more
> > >>> generic, as it really bootstrap the host and not vdsm...:
> > >>> 1. ovirt-hypervisor-bootstrap
> > >>> 2. ovirt-host-setup
> > >>
> > >> +1 to this one. not sure if critical to rename the rpm though.
> > >
> > > I think that with all alternatives, renaming the package will
> > > make
> > > it easy procedurally.
> > > As the old ovirt-engine will continue to pull the existing
> > > packages.
> > > We do not need to handle conflicts or breakage.
> > >
> > > So can we close up with ovirt-host-setup?
> > > I personally, think ovirt-host-deploy is better than setup.
> > 
> > i'm fine either way.
> 
> Great!
> So ovirt-host-deploy it is.
> 
> > 
> > >
> > >>
> > >>> 3. ovirt-deployer
> > >>>
> > >>> Any other idea will be most welcome, we need to close this fast
> > >>> to
> > >>> progress.
> > >>>
> > >>> Best Regards,
> > >>> Alon Bar-Lev
> > >
> > > Thanks!
> > > Alon
> > >
> > 
> > 
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From dneary at redhat.com  Fri Nov 16 10:26:03 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 16 Nov 2012 11:26:03 +0100
Subject: Virtualization DevRoom @ FOSDEM
Message-ID: <50A614BB.8060108@redhat.com>

Hi all,

The call for participation for the Virtualization DevRoom (co-organised 
by Itamar and myself) is now open:

http://osvc.v2.cs.unibo.it/index.php/Main_Page

We are looking for content submissions related to machine 
virtualization, network virtualization, process-level virt and virt 
management (like oVirt). The target audience for the conference is free 
software enthusiasts who are also virt experts - very much the target 
audience of oVirt.

Please send your proposals before December 16th to 
virt-devroom at lists.fosdem.org (as described in the call for proposals).

Thanks,
Dave.


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


From fgranha at linux.vnet.ibm.com  Fri Nov 16 17:34:29 2012
From: fgranha at linux.vnet.ibm.com (Fernando Granha Jeronimo)
Date: Fri, 16 Nov 2012 15:34:29 -0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50A236E4.1070304@linux.vnet.ibm.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>	<509CA431.8080405@redhat.com>
	<50A1F141.9010500@redhat.com> <50A236E4.1070304@linux.vnet.ibm.com>
Message-ID: <50A67925.1010704@linux.vnet.ibm.com>

On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
> On 11/13/2012 05:05 AM, Itamar Heim wrote:
>> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>>> Hello all,
>>>>
>>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine in a
>>>> feature page:
>>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>>
>>>> Suggestions and comments are greatly appreciated.
>>>
>>> iiuc, the most obvious change to mention is addition of an 'arch' field
>>> to cluster, which would affect the list of supported cpu families, 
>>> etc.?
>>> (and to later know to filter all other aspects of entities based on 
>>> this
>>> arch field)?
>>>
>>> list of possible arch's would be per cluster compatibility level.
>>> i'd expect default for API of this field to be x86_64 for backward
>>> compatibility, so it is not mandatory.
>>> I'd also prefer this field to be disabled or hidden if there is only 
>>> one
>>> option available in it.
>>>
>>> it gets more complicated, as VMs can be moved around between clusters,
>>> exported/imported, etc.
>>>
>>> you would need to validate a VM isn't moved to a cluster with a
>>> different arch, or imported into a cluster with a different arch as 
>>> well.
>>> (probably more like that).
>>>
>>> i assume the config to filter device types per arch like the network
>>> devices is also for console (spice), audio, etc.
>>>
>>> the system already has the concept of filtering per cluster level, so
>>> filtering per cluster level and arch would mean reviewing all places in
>>> code for that.
>>
>> I'm adding roy/omer/michal as the work on libosinfo (patches in 
>> gerrit[1]) seems to make some of these changes not needed (if it is 
>> merged).
>> rather just need to extend libosinfo with the information on ppc.
>>
>> for sure worth reviewing both approaches to make sure the chosen 
>> solution benefits both and we collaborate on same end goal.
>
> thanks, we will check these patches and possibly change the approach 
> to use libosinfo.
>
Hello,

We have carefully analyzed the engine libosinfo patches and the 
libosinfo itself to devise
our conclusion. During this process, we found the following key points:

   * In order to have a clear notion of supported versions and devices, 
we would
     need to populate libosinfo's xmls for qemu and for devices, as well 
as implement logic in
     ovirt-engine to process the relationship between them. This would 
be basically partially
     reimplement the lib itself. In addition, given that we are not 
using the lib but actually processing
     the xmls directly there is no guarantee that their structure will 
be preserved in the future,
     which in the mid/long term may lead to code changes in the engine 
to adapt to it.
   * Even if libosinfo had all the information we needed in the xmls, we 
would still need to validate
     or filter values according to ovirt-engine's rules. For instance, 
if the list of network devices
     for PowerKVM in libosinfo had 5 elements and the engine only 
intended to support/expose 2 specific models,
     (for a given version for example) it has to be aware of these two 
models, meaning that even using libosinfo
     we still need something in engine to validate them (which 
reinforces Itamar's filter suggestion).

The primary concern of libosinfo patches is focused on virtual machine 
parameters validation based on OS.
With regard to Power KVM support it doesn't address other areas like 
hypervisor/cluster validation logic.
Based on that and the exposed in the previous items, an approach that 
seems to make sense if the libosinfo patches
are merged is to keep the focus of libosinfo usage as it is and for the 
other areas to use the suggested in the
PowerKVM feature page 
(http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64). This 
would benefit both and
converge to a project's solution.

Appreciate comments you may have.

Kind regards,
>>
>> [1] some of the patches are:
>> http://gerrit.ovirt.org/9065
>> http://gerrit.ovirt.org/9063
>> http://gerrit.ovirt.org/9049
>>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From dneary at redhat.com  Sat Nov 17 19:42:24 2012
From: dneary at redhat.com (Dave Neary)
Date: Sat, 17 Nov 2012 20:42:24 +0100
Subject: Slides online (some still missing)
Message-ID: <50A7E8A0.9030308@redhat.com>

Hi all,

I uploaded all the slides I found in my archives from the oVirt Workshop 
in Barcelona to the wiki:

http://wiki.ovirt.org/wiki/LinuxCon_Europe_workshop_schedule

There are about half the sessions for which I don't have slides - even 
though I am sure I saw some of them going through my mailbox.

For those of you who gave sessions and would like to attach the slides, 
here's how to do it:
* Click "Upload file", select the local file, and give it a name which 
is likely to be unique in the wiki - I used the format 
Surname-topic-title.<extension> myself
* In the schedule page, click "edit" for the section involved, and add a 
"Slides" entry for your slides, as so:
[[Media:<filename> | Slides]]

Using Media: prevents MediaWiki from trying to render the file, and 
treating it as a link instead.

If you prefer, you can send me the slides, and I can put them up there, 
but it'll probably be quicker if you do it yourselves :-)

Thanks,
Dave.

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


From iheim at redhat.com  Sun Nov 18 11:47:21 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 18 Nov 2012 13:47:21 +0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50A67925.1010704@linux.vnet.ibm.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>	<509CA431.8080405@redhat.com>
	<50A1F141.9010500@redhat.com> <50A236E4.1070304@linux.vnet.ibm.com>
	<50A67925.1010704@linux.vnet.ibm.com>
Message-ID: <50A8CAC9.9090403@redhat.com>

On 11/16/2012 07:34 PM, Fernando Granha Jeronimo wrote:
> On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
>> On 11/13/2012 05:05 AM, Itamar Heim wrote:
>>> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>>>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>>>> Hello all,
>>>>>
>>>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine in a
>>>>> feature page:
>>>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>>>
>>>>> Suggestions and comments are greatly appreciated.
>>>>
>>>> iiuc, the most obvious change to mention is addition of an 'arch' field
>>>> to cluster, which would affect the list of supported cpu families,
>>>> etc.?
>>>> (and to later know to filter all other aspects of entities based on
>>>> this
>>>> arch field)?
>>>>
>>>> list of possible arch's would be per cluster compatibility level.
>>>> i'd expect default for API of this field to be x86_64 for backward
>>>> compatibility, so it is not mandatory.
>>>> I'd also prefer this field to be disabled or hidden if there is only
>>>> one
>>>> option available in it.
>>>>
>>>> it gets more complicated, as VMs can be moved around between clusters,
>>>> exported/imported, etc.
>>>>
>>>> you would need to validate a VM isn't moved to a cluster with a
>>>> different arch, or imported into a cluster with a different arch as
>>>> well.
>>>> (probably more like that).
>>>>
>>>> i assume the config to filter device types per arch like the network
>>>> devices is also for console (spice), audio, etc.
>>>>
>>>> the system already has the concept of filtering per cluster level, so
>>>> filtering per cluster level and arch would mean reviewing all places in
>>>> code for that.
>>>
>>> I'm adding roy/omer/michal as the work on libosinfo (patches in
>>> gerrit[1]) seems to make some of these changes not needed (if it is
>>> merged).
>>> rather just need to extend libosinfo with the information on ppc.
>>>
>>> for sure worth reviewing both approaches to make sure the chosen
>>> solution benefits both and we collaborate on same end goal.
>>
>> thanks, we will check these patches and possibly change the approach
>> to use libosinfo.
>>
> Hello,
>
> We have carefully analyzed the engine libosinfo patches and the
> libosinfo itself to devise
> our conclusion. During this process, we found the following key points:
>
>    * In order to have a clear notion of supported versions and devices,
> we would
>      need to populate libosinfo's xmls for qemu and for devices, as well
> as implement logic in
>      ovirt-engine to process the relationship between them. This would
> be basically partially
>      reimplement the lib itself. In addition, given that we are not
> using the lib but actually processing
>      the xmls directly there is no guarantee that their structure will
> be preserved in the future,
>      which in the mid/long term may lead to code changes in the engine
> to adapt to it.

I thought that is what roy's patches are doing?
i agree about the concern if the xml is changing.

>    * Even if libosinfo had all the information we needed in the xmls, we
> would still need to validate
>      or filter values according to ovirt-engine's rules. For instance,
> if the list of network devices
>      for PowerKVM in libosinfo had 5 elements and the engine only
> intended to support/expose 2 specific models,
>      (for a given version for example) it has to be aware of these two
> models, meaning that even using libosinfo
>      we still need something in engine to validate them (which
> reinforces Itamar's filter suggestion).

good point - Roy, how would cluster level compatibility for features 
would work in your libosinfo approach?


>
> The primary concern of libosinfo patches is focused on virtual machine
> parameters validation based on OS.
> With regard to Power KVM support it doesn't address other areas like
> hypervisor/cluster validation logic.

well, this could just be since it wasn't populated for a non x86_64 
arch. would it make sense for you to discuss ppc support for libosinfo 
regardless?

> Based on that and the exposed in the previous items, an approach that
> seems to make sense if the libosinfo patches
> are merged is to keep the focus of libosinfo usage as it is and for the
> other areas to use the suggested in the
> PowerKVM feature page
> (http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64). This
> would benefit both and
> converge to a project's solution.
>
> Appreciate comments you may have.
>
> Kind regards,
>>>
>>> [1] some of the patches are:
>>> http://gerrit.ovirt.org/9065
>>> http://gerrit.ovirt.org/9063
>>> http://gerrit.ovirt.org/9049
>>>
>>
>> _______________________________________________
>> 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  Sun Nov 18 22:43:48 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 18 Nov 2012 17:43:48 -0500 (EST)
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <2115911145.9035492.1352978092337.JavaMail.root@redhat.com>
Message-ID: <2050448569.251059.1353278628812.JavaMail.root@redhat.com>

Hello,

Final details:

Common infrastructure

  OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.
  Java name space: org.ovirt.otopi
  License: GPL2+

Deploy code (aka vdsm-bootstrap)

  ovirt-host-deploy
  Java name space: org.ovirt.ovirt_host_deploy
  License: GPL2+

Thanks,
Alon.

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, November 15, 2012 1:14:52 PM
> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Thursday, November 15, 2012 12:34:42 PM
> > Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> > 
> > Hello,
> > 
> > Summary:
> > 
> > Common infrastructure:
> > OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.
> > 
> > Deploy code (vdsm-bootstrap):
> > ovirt-host-deploy
> > 
> > I want to close this by Sunday to perform the rename, split, create
> > repositories etc...
> > 
> > So if anyone has more ideas, please raise a flags as after renaming
> > it will be very difficult to change.
> > 
> > Thanks,
> > Alon
> 
> I forgot we need a namespace for the core specific java resources.
> 
> Should it be org.ovirt.otopi or drop the ovirt in favour of
> org.otopi?
> 
> Thanks,
> Alon.
> 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Thursday, November 15, 2012 12:25:13 PM
> > > Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> > > 
> > > On 11/15/2012 12:22 PM, Alon Bar-Lev wrote:
> > > > OK, we need to close this up...
> > > >
> > > > ----- Original Message -----
> > > >> From: "Itamar Heim" <iheim at redhat.com>
> > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >> Cc: "arch" <arch at ovirt.org>
> > > >> Sent: Tuesday, November 13, 2012 6:21:15 PM
> > > >> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> > > >>
> > > >> On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
> > > >>> Hello All,
> > > >>>
> > > >>> I am working on rewriting the vdsm-bootstrap process.
> > > >>>
> > > >>> I found that most of the installer implementation is not vdsm
> > > >>> specific, so I split the package into two:
> > > >>>
> > > >>>    core installer
> > > >>>    vdsm-bootstrap
> > > >>>
> > > >>> I would like to find a suitable name for the core installer.
> > > >>>
> > > >>> In nat shell:
> > > >>> """
> > > >>> Standalone plugin based installation framework to be used to
> > > >>> setup
> > > >>> system components. The plugin nature provides simplicity to
> > > >>> add new installation functionality without the complexity of
> > > >>> the
> > > >>> state
> > > >>> and transaction management.
> > > >>>
> > > >>> At the core of the implementation there is environment
> > > >>> dictionary
> > > >>> and
> > > >>> a flow of stages within plugins. The environment can be
> > > >>> modified
> > > >>> using
> > > >>> command-line parameters, configuration file, or dialog
> > > >>> customization.
> > > >>> """
> > > >>>
> > > >>> Sources are available at temporary location[1].
> > > >>>
> > > >>> Names that we thought of:
> > > >>> 1. ovirt-installer
> > > >>
> > > >> hmmm, that's between being generic, and consumable by others.
> > > >> question is how problematic it is if we keep our name...
> > > >> would be nice if we can advertise ourselves a bit.
> > > >> maybe we can compromise on:
> > > >> ogi - ovirt generic installer
> > > >>
> > > >> so name isn't directly with ovirt, but some marketing of ovirt
> > > >> from
> > > >> it
> > > >> may happen.
> > > >>
> > > >> so +1 to OGI from me.
> > > >>
> > > >>> 2. virtulation (virtualization + installation)
> > > >>> 3. virtaller (virtualization + installation)
> > > >>> 4. TOPI (Task Oriented Pluggable Installer/Implementation)
> > > >>
> > > >> +1
> > > >>
> > > >> hmmm, spinning #1:
> > > >> OTOPI.
> > > >> has a nice ring to it around utopia as well.
> > > >>
> > > >
> > > > So OTOPI it is, well actually lower case otopi.
> > > >
> > > >>
> > > >>> 5. PDF (Pluggable Deployment Framework)
> > > >>
> > > >> -1 due to PDF so widely known as something else
> > > >>
> > > >>>
> > > >>> I would also like to consider if we want to keep the
> > > >>> vdsm-bootstrap
> > > >>> name for the bootstrap package, or we should use something
> > > >>> more
> > > >>> generic, as it really bootstrap the host and not vdsm...:
> > > >>> 1. ovirt-hypervisor-bootstrap
> > > >>> 2. ovirt-host-setup
> > > >>
> > > >> +1 to this one. not sure if critical to rename the rpm though.
> > > >
> > > > I think that with all alternatives, renaming the package will
> > > > make
> > > > it easy procedurally.
> > > > As the old ovirt-engine will continue to pull the existing
> > > > packages.
> > > > We do not need to handle conflicts or breakage.
> > > >
> > > > So can we close up with ovirt-host-setup?
> > > > I personally, think ovirt-host-deploy is better than setup.
> > > 
> > > i'm fine either way.
> > 
> > Great!
> > So ovirt-host-deploy it is.
> > 
> > > 
> > > >
> > > >>
> > > >>> 3. ovirt-deployer
> > > >>>
> > > >>> Any other idea will be most welcome, we need to close this
> > > >>> fast
> > > >>> to
> > > >>> progress.
> > > >>>
> > > >>> Best Regards,
> > > >>> Alon Bar-Lev
> > > >
> > > > Thanks!
> > > > 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 ppinatti at linux.vnet.ibm.com  Mon Nov 19 13:25:35 2012
From: ppinatti at linux.vnet.ibm.com (Paulo de Rezende Pinatti)
Date: Mon, 19 Nov 2012 11:25:35 -0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50A8CAC9.9090403@redhat.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>	<509CA431.8080405@redhat.com>
	<50A1F141.9010500@redhat.com> <50A236E4.1070304@linux.vnet.ibm.com>
	<50A67925.1010704@linux.vnet.ibm.com> <50A8CAC9.9090403@redhat.com>
Message-ID: <50AA334F.6010203@linux.vnet.ibm.com>

On 11/18/2012 09:47 AM, Itamar Heim wrote:
> On 11/16/2012 07:34 PM, Fernando Granha Jeronimo wrote:
>> On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
>>> On 11/13/2012 05:05 AM, Itamar Heim wrote:
>>>> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>>>>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine 
>>>>>> in a
>>>>>> feature page:
>>>>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>>>>
>>>>>> Suggestions and comments are greatly appreciated.
>>>>>
>>>>> iiuc, the most obvious change to mention is addition of an 'arch' 
>>>>> field
>>>>> to cluster, which would affect the list of supported cpu families,
>>>>> etc.?
>>>>> (and to later know to filter all other aspects of entities based on
>>>>> this
>>>>> arch field)?
>>>>>
>>>>> list of possible arch's would be per cluster compatibility level.
>>>>> i'd expect default for API of this field to be x86_64 for backward
>>>>> compatibility, so it is not mandatory.
>>>>> I'd also prefer this field to be disabled or hidden if there is only
>>>>> one
>>>>> option available in it.
>>>>>
>>>>> it gets more complicated, as VMs can be moved around between 
>>>>> clusters,
>>>>> exported/imported, etc.
>>>>>
>>>>> you would need to validate a VM isn't moved to a cluster with a
>>>>> different arch, or imported into a cluster with a different arch as
>>>>> well.
>>>>> (probably more like that).
>>>>>
>>>>> i assume the config to filter device types per arch like the network
>>>>> devices is also for console (spice), audio, etc.
>>>>>
>>>>> the system already has the concept of filtering per cluster level, so
>>>>> filtering per cluster level and arch would mean reviewing all 
>>>>> places in
>>>>> code for that.
>>>>
>>>> I'm adding roy/omer/michal as the work on libosinfo (patches in
>>>> gerrit[1]) seems to make some of these changes not needed (if it is
>>>> merged).
>>>> rather just need to extend libosinfo with the information on ppc.
>>>>
>>>> for sure worth reviewing both approaches to make sure the chosen
>>>> solution benefits both and we collaborate on same end goal.
>>>
>>> thanks, we will check these patches and possibly change the approach
>>> to use libosinfo.
>>>
>> Hello,
>>
>> We have carefully analyzed the engine libosinfo patches and the
>> libosinfo itself to devise
>> our conclusion. During this process, we found the following key points:
>>
>>    * In order to have a clear notion of supported versions and devices,
>> we would
>>      need to populate libosinfo's xmls for qemu and for devices, as well
>> as implement logic in
>>      ovirt-engine to process the relationship between them. This would
>> be basically partially
>>      reimplement the lib itself. In addition, given that we are not
>> using the lib but actually processing
>>      the xmls directly there is no guarantee that their structure will
>> be preserved in the future,
>>      which in the mid/long term may lead to code changes in the engine
>> to adapt to it.
>
> I thought that is what roy's patches are doing?
> i agree about the concern if the xml is changing.
>
>>    * Even if libosinfo had all the information we needed in the xmls, we
>> would still need to validate
>>      or filter values according to ovirt-engine's rules. For instance,
>> if the list of network devices
>>      for PowerKVM in libosinfo had 5 elements and the engine only
>> intended to support/expose 2 specific models,
>>      (for a given version for example) it has to be aware of these two
>> models, meaning that even using libosinfo
>>      we still need something in engine to validate them (which
>> reinforces Itamar's filter suggestion).
>
> good point - Roy, how would cluster level compatibility for features 
> would work in your libosinfo approach?
>
>
>>
>> The primary concern of libosinfo patches is focused on virtual machine
>> parameters validation based on OS.
>> With regard to Power KVM support it doesn't address other areas like
>> hypervisor/cluster validation logic.
>
> well, this could just be since it wasn't populated for a non x86_64 
> arch. would it make sense for you to discuss ppc support for libosinfo 
> regardless?
>

Thanks for your comments Itamar. It's good to discuss to find the best 
ways to proceed.

I think the point Fernando made was that the libosinfo integration with 
ovirt is just for vm parameter validation, and other areas needing to 
change to support powerkvm such the hypervisor/cluster validation are 
not addressed by libosinfo at all, even for x86.

It means that if we choose this path it would first be necessary to 
change ovirt code to tighter integrate with libosinfo, and implement the 
processing of links between xmls as well as validation of values against 
ovirt rules (both mentioned in bullets above). Libosinfo in turn would 
need its xmls populated to provide things like cpu flags, devices, 
hypervisor and versions information. These would be needed just for the 
code we have today, with no PowerKVM support yet.

This would be a longer road which would be interesting to take if we had 
as a result a stable and centralized point of platform related 
information. But rather ovirt would be possibly sitting on unstable 
ground as Fernando well pointed the xmls can change at any time due to 
libosinfo projects needs, which would force ovirt to re-adapt to new xml 
formats. As to centralization, the information would still be partially 
dispersed due to the need to determine what ovirt wants to support (this 
kind of information cannot go in libosinfo).


>> Based on that and the exposed in the previous items, an approach that
>> seems to make sense if the libosinfo patches
>> are merged is to keep the focus of libosinfo usage as it is and for the
>> other areas to use the suggested in the
>> PowerKVM feature page
>> (http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64). This
>> would benefit both and
>> converge to a project's solution.
>>
>> Appreciate comments you may have.
>>
>> Kind regards,
>>>>
>>>> [1] some of the patches are:
>>>> http://gerrit.ovirt.org/9065
>>>> http://gerrit.ovirt.org/9063
>>>> http://gerrit.ovirt.org/9049
>>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



From ppinatti at linux.vnet.ibm.com  Mon Nov 19 13:38:52 2012
From: ppinatti at linux.vnet.ibm.com (Paulo de Rezende Pinatti)
Date: Mon, 19 Nov 2012 11:38:52 -0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50AA334F.6010203@linux.vnet.ibm.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>	<509CA431.8080405@redhat.com>
	<50A1F141.9010500@redhat.com> <50A236E4.1070304@linux.vnet.ibm.com>
	<50A67925.1010704@linux.vnet.ibm.com> <50A8CAC9.9090403@redhat.com>
	<50AA334F.6010203@linux.vnet.ibm.com>
Message-ID: <50AA366C.4050104@linux.vnet.ibm.com>

On 11/19/2012 11:25 AM, Paulo de Rezende Pinatti wrote:
> On 11/18/2012 09:47 AM, Itamar Heim wrote:
>> On 11/16/2012 07:34 PM, Fernando Granha Jeronimo wrote:
>>> On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
>>>> On 11/13/2012 05:05 AM, Itamar Heim wrote:
>>>>> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>>>>>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine 
>>>>>>> in a
>>>>>>> feature page:
>>>>>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>>>>>
>>>>>>> Suggestions and comments are greatly appreciated.
>>>>>>
>>>>>> iiuc, the most obvious change to mention is addition of an 'arch' 
>>>>>> field
>>>>>> to cluster, which would affect the list of supported cpu families,
>>>>>> etc.?
>>>>>> (and to later know to filter all other aspects of entities based on
>>>>>> this
>>>>>> arch field)?
>>>>>>
>>>>>> list of possible arch's would be per cluster compatibility level.
>>>>>> i'd expect default for API of this field to be x86_64 for backward
>>>>>> compatibility, so it is not mandatory.
>>>>>> I'd also prefer this field to be disabled or hidden if there is only
>>>>>> one
>>>>>> option available in it.
>>>>>>
>>>>>> it gets more complicated, as VMs can be moved around between 
>>>>>> clusters,
>>>>>> exported/imported, etc.
>>>>>>
>>>>>> you would need to validate a VM isn't moved to a cluster with a
>>>>>> different arch, or imported into a cluster with a different arch as
>>>>>> well.
>>>>>> (probably more like that).
>>>>>>
>>>>>> i assume the config to filter device types per arch like the network
>>>>>> devices is also for console (spice), audio, etc.
>>>>>>
>>>>>> the system already has the concept of filtering per cluster 
>>>>>> level, so
>>>>>> filtering per cluster level and arch would mean reviewing all 
>>>>>> places in
>>>>>> code for that.
>>>>>
>>>>> I'm adding roy/omer/michal as the work on libosinfo (patches in
>>>>> gerrit[1]) seems to make some of these changes not needed (if it is
>>>>> merged).
>>>>> rather just need to extend libosinfo with the information on ppc.
>>>>>
>>>>> for sure worth reviewing both approaches to make sure the chosen
>>>>> solution benefits both and we collaborate on same end goal.
>>>>
>>>> thanks, we will check these patches and possibly change the approach
>>>> to use libosinfo.
>>>>
>>> Hello,
>>>
>>> We have carefully analyzed the engine libosinfo patches and the
>>> libosinfo itself to devise
>>> our conclusion. During this process, we found the following key points:
>>>
>>>    * In order to have a clear notion of supported versions and devices,
>>> we would
>>>      need to populate libosinfo's xmls for qemu and for devices, as 
>>> well
>>> as implement logic in
>>>      ovirt-engine to process the relationship between them. This would
>>> be basically partially
>>>      reimplement the lib itself. In addition, given that we are not
>>> using the lib but actually processing
>>>      the xmls directly there is no guarantee that their structure will
>>> be preserved in the future,
>>>      which in the mid/long term may lead to code changes in the engine
>>> to adapt to it.
>>
>> I thought that is what roy's patches are doing?
>> i agree about the concern if the xml is changing.
>>
>>>    * Even if libosinfo had all the information we needed in the 
>>> xmls, we
>>> would still need to validate
>>>      or filter values according to ovirt-engine's rules. For instance,
>>> if the list of network devices
>>>      for PowerKVM in libosinfo had 5 elements and the engine only
>>> intended to support/expose 2 specific models,
>>>      (for a given version for example) it has to be aware of these two
>>> models, meaning that even using libosinfo
>>>      we still need something in engine to validate them (which
>>> reinforces Itamar's filter suggestion).
>>
>> good point - Roy, how would cluster level compatibility for features 
>> would work in your libosinfo approach?
>>
>>
>>>
>>> The primary concern of libosinfo patches is focused on virtual machine
>>> parameters validation based on OS.
>>> With regard to Power KVM support it doesn't address other areas like
>>> hypervisor/cluster validation logic.
>>
>> well, this could just be since it wasn't populated for a non x86_64 
>> arch. would it make sense for you to discuss ppc support for 
>> libosinfo regardless?
>>
>
> Thanks for your comments Itamar. It's good to discuss to find the best 
> ways to proceed.
>
> I think the point Fernando made was that the libosinfo integration 
> with ovirt is just for vm parameter validation, and other areas 
> needing to change to support powerkvm such the hypervisor/cluster 
> validation are not addressed by libosinfo at all, even for x86.

just to avoid confusion: I am referring to the libosinfo patches, not 
the libosinfo itself. Libosinfo has support to manage hypervisor 
information.

>
> It means that if we choose this path it would first be necessary to 
> change ovirt code to tighter integrate with libosinfo, and implement 
> the processing of links between xmls as well as validation of values 
> against ovirt rules (both mentioned in bullets above). Libosinfo in 
> turn would need its xmls populated to provide things like cpu flags, 
> devices, hypervisor and versions information. These would be needed 
> just for the code we have today, with no PowerKVM support yet.
>
> This would be a longer road which would be interesting to take if we 
> had as a result a stable and centralized point of platform related 
> information. But rather ovirt would be possibly sitting on unstable 
> ground as Fernando well pointed the xmls can change at any time due to 
> libosinfo projects needs, which would force ovirt to re-adapt to new 
> xml formats. As to centralization, the information would still be 
> partially dispersed due to the need to determine what ovirt wants to 
> support (this kind of information cannot go in libosinfo).
>
>
>>> Based on that and the exposed in the previous items, an approach that
>>> seems to make sense if the libosinfo patches
>>> are merged is to keep the focus of libosinfo usage as it is and for the
>>> other areas to use the suggested in the
>>> PowerKVM feature page
>>> (http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64). This
>>> would benefit both and
>>> converge to a project's solution.
>>>
>>> Appreciate comments you may have.
>>>
>>> Kind regards,
>>>>>
>>>>> [1] some of the patches are:
>>>>> http://gerrit.ovirt.org/9065
>>>>> http://gerrit.ovirt.org/9063
>>>>> http://gerrit.ovirt.org/9049
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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 dfediuck at redhat.com  Wed Nov 21 08:00:24 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 21 Nov 2012 03:00:24 -0500 (EST)
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <509A7E60.4090906@linux.vnet.ibm.com>
Message-ID: <614856366.29225932.1353484824630.JavaMail.root@redhat.com>

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

> From: "Sheldon" <shaohef at linux.vnet.ibm.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: arch at ovirt.org, "Zheng Sheng ZS Zhou" <zhshzhou at cn.ibm.com>
> Sent: Wednesday, November 7, 2012 5:29:36 PM
> Subject: Re: [vdsm] Review Request: Add an option to create a
> watchdog device.

> On 11/06/2012 01:47 PM, Itamar Heim wrote:

> > On 11/06/2012 04:55 AM, Sheldon wrote:
> 

> > > On 10/30/2012 01:00 PM, Sheldon wrote:
> > 
> 

> > > > Looking for some review on this patch.
> > > 
> > 
> 

> > > > http://gerrit.ovirt.org/#/c/7535/
> > > 
> > 
> 

> > > > Thanks.
> > > 
> > 
> 

> > > Add a feature page on
> > > wiki.http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device
> > 
> 

> > (moved to arch)
> 
> > thanks.
> 
> > I'm missing where this will be in the engine dialog (in new/edit
> > vm),
> > and that engine should probably get the log event on the watchdog
> > event, not only vdsm.
> 

> Watchdog event is very important for high reliability. It can tell
> what's wrong on the guest.

> I'm considering a new patch after this patch was merged. It can
> support a new API or channel to notify the watchdog event to the
> engine.

> Seems there is not an asynchronous event channel for engine.

> Maybe a new API for the engine. Engine can poll it to check the
> watchdog event.

> I will discuss it on the ovirt IRC channel with the engine expert.

> Currently, we do not have any plans to implement the engine side of
> the feature.
> But I will add a watchdog feature page to describe how engine enable
> this feature. It's definitely great if any engine guy would like to
> take the engine part. I will be glad to provide help if needed.
Hi Sheldon, 
Any news on the engine side? 
Currently the vdsm side is merged, while the engine side still missing. 
The wiki page also lacks the engine side. Can you please handle it? 

> > thanks,
> 
> > Itamar
> 

> > > > --
> > > 
> > 
> 
> > > > Sheldon Feng(???) <shaohef at linux.vnet.ibm.com>
> > > 
> > 
> 
> > > > IBM Linux Technology Center
> > > 
> > 
> 

> > > > _______________________________________________
> > > 
> > 
> 
> > > > vdsm-devel mailing list
> > > 
> > 
> 
> > > > vdsm-devel at lists.fedorahosted.org
> > > 
> > 
> 
> > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > 
> > 
> 

> > > --
> > 
> 
> > > Sheldon Feng(???) <shaohef at linux.vnet.ibm.com>
> > 
> 
> > > IBM Linux Technology Center
> > 
> 

> > > _______________________________________________
> > 
> 
> > > vdsm-devel mailing list
> > 
> 
> > > vdsm-devel at lists.fedorahosted.org
> > 
> 
> > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> 

> --
> Sheldon Feng(???) <shaohef at linux.vnet.ibm.com> IBM Linux Technology
> Center
> _______________________________________________
> 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/20121121/a8311c5d/attachment.html>

From mgoldboi at redhat.com  Wed Nov 21 15:00:21 2012
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Wed, 21 Nov 2012 17:00:21 +0200
Subject: [RFC] oVirtLive image
Message-ID: <50ACEC85.9040700@redhat.com>

Hello All,

as you may know i have been working for a while on oVirtLive image [1,2].

-as a first step I would like to have oVirt to host this sub-project in a repository
-the following step have nightly builds on jenkins for different versions/distros etc.

i think that can help in terms of project exposure, when people sometimes find deployment and installation as a hard process.

[1]http://lists.ovirt.org/pipermail/users/2012-September/003819.html
[2]http://wiki.ovirt.org/wiki/OVirt_Live

Thanks,
Moran.



From iheim at redhat.com  Wed Nov 21 22:03:44 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 22 Nov 2012 00:03:44 +0200
Subject: [RFC] oVirtLive image
In-Reply-To: <50ACEC85.9040700@redhat.com>
References: <50ACEC85.9040700@redhat.com>
Message-ID: <50AD4FC0.1010501@redhat.com>

On 11/21/2012 05:00 PM, Moran Goldboim wrote:
> Hello All,
>
> as you may know i have been working for a while on oVirtLive image [1,2].
>
> -as a first step I would like to have oVirt to host this sub-project in
> a repository
> -the following step have nightly builds on jenkins for different
> versions/distros etc.
>
> i think that can help in terms of project exposure, when people
> sometimes find deployment and installation as a hard process.
>
> [1]http://lists.ovirt.org/pipermail/users/2012-September/003819.html
> [2]http://wiki.ovirt.org/wiki/OVirt_Live

+1, suggesting ovirt-live as repo name.
will give a few days for others to reply


From iheim at redhat.com  Wed Nov 21 22:44:14 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 22 Nov 2012 00:44:14 +0200
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <2050448569.251059.1353278628812.JavaMail.root@redhat.com>
References: <2050448569.251059.1353278628812.JavaMail.root@redhat.com>
Message-ID: <50AD593E.3060709@redhat.com>

On 11/19/2012 12:43 AM, Alon Bar-Lev wrote:
> Hello,
>
> Final details:
>
> Common infrastructure
>
>    OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.
>    Java name space: org.ovirt.otopi
>    License: GPL2+
>
> Deploy code (aka vdsm-bootstrap)
>
>    ovirt-host-deploy
>    Java name space: org.ovirt.ovirt_host_deploy
>    License: GPL2+

as ovirt is ASL, please use LGPLv2.1+.

thanks,
    Itamar

>
> Thanks,
> Alon.
>
> ----- Original Message -----
>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "arch" <arch at ovirt.org>
>> Sent: Thursday, November 15, 2012 1:14:52 PM
>> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
>>
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>> To: "Itamar Heim" <iheim at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>
>>> Sent: Thursday, November 15, 2012 12:34:42 PM
>>> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
>>>
>>> Hello,
>>>
>>> Summary:
>>>
>>> Common infrastructure:
>>> OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.
>>>
>>> Deploy code (vdsm-bootstrap):
>>> ovirt-host-deploy
>>>
>>> I want to close this by Sunday to perform the rename, split, create
>>> repositories etc...
>>>
>>> So if anyone has more ideas, please raise a flags as after renaming
>>> it will be very difficult to change.
>>>
>>> Thanks,
>>> Alon
>>
>> I forgot we need a namespace for the core specific java resources.
>>
>> Should it be org.ovirt.otopi or drop the ovirt in favour of
>> org.otopi?
>>
>> Thanks,
>> Alon.
>>
>>>
>>> ----- Original Message -----
>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "arch" <arch at ovirt.org>
>>>> Sent: Thursday, November 15, 2012 12:25:13 PM
>>>> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
>>>>
>>>> On 11/15/2012 12:22 PM, Alon Bar-Lev wrote:
>>>>> OK, we need to close this up...
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> Cc: "arch" <arch at ovirt.org>
>>>>>> Sent: Tuesday, November 13, 2012 6:21:15 PM
>>>>>> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
>>>>>>
>>>>>> On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
>>>>>>> Hello All,
>>>>>>>
>>>>>>> I am working on rewriting the vdsm-bootstrap process.
>>>>>>>
>>>>>>> I found that most of the installer implementation is not vdsm
>>>>>>> specific, so I split the package into two:
>>>>>>>
>>>>>>>     core installer
>>>>>>>     vdsm-bootstrap
>>>>>>>
>>>>>>> I would like to find a suitable name for the core installer.
>>>>>>>
>>>>>>> In nat shell:
>>>>>>> """
>>>>>>> Standalone plugin based installation framework to be used to
>>>>>>> setup
>>>>>>> system components. The plugin nature provides simplicity to
>>>>>>> add new installation functionality without the complexity of
>>>>>>> the
>>>>>>> state
>>>>>>> and transaction management.
>>>>>>>
>>>>>>> At the core of the implementation there is environment
>>>>>>> dictionary
>>>>>>> and
>>>>>>> a flow of stages within plugins. The environment can be
>>>>>>> modified
>>>>>>> using
>>>>>>> command-line parameters, configuration file, or dialog
>>>>>>> customization.
>>>>>>> """
>>>>>>>
>>>>>>> Sources are available at temporary location[1].
>>>>>>>
>>>>>>> Names that we thought of:
>>>>>>> 1. ovirt-installer
>>>>>>
>>>>>> hmmm, that's between being generic, and consumable by others.
>>>>>> question is how problematic it is if we keep our name...
>>>>>> would be nice if we can advertise ourselves a bit.
>>>>>> maybe we can compromise on:
>>>>>> ogi - ovirt generic installer
>>>>>>
>>>>>> so name isn't directly with ovirt, but some marketing of ovirt
>>>>>> from
>>>>>> it
>>>>>> may happen.
>>>>>>
>>>>>> so +1 to OGI from me.
>>>>>>
>>>>>>> 2. virtulation (virtualization + installation)
>>>>>>> 3. virtaller (virtualization + installation)
>>>>>>> 4. TOPI (Task Oriented Pluggable Installer/Implementation)
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> hmmm, spinning #1:
>>>>>> OTOPI.
>>>>>> has a nice ring to it around utopia as well.
>>>>>>
>>>>>
>>>>> So OTOPI it is, well actually lower case otopi.
>>>>>
>>>>>>
>>>>>>> 5. PDF (Pluggable Deployment Framework)
>>>>>>
>>>>>> -1 due to PDF so widely known as something else
>>>>>>
>>>>>>>
>>>>>>> I would also like to consider if we want to keep the
>>>>>>> vdsm-bootstrap
>>>>>>> name for the bootstrap package, or we should use something
>>>>>>> more
>>>>>>> generic, as it really bootstrap the host and not vdsm...:
>>>>>>> 1. ovirt-hypervisor-bootstrap
>>>>>>> 2. ovirt-host-setup
>>>>>>
>>>>>> +1 to this one. not sure if critical to rename the rpm though.
>>>>>
>>>>> I think that with all alternatives, renaming the package will
>>>>> make
>>>>> it easy procedurally.
>>>>> As the old ovirt-engine will continue to pull the existing
>>>>> packages.
>>>>> We do not need to handle conflicts or breakage.
>>>>>
>>>>> So can we close up with ovirt-host-setup?
>>>>> I personally, think ovirt-host-deploy is better than setup.
>>>>
>>>> i'm fine either way.
>>>
>>> Great!
>>> So ovirt-host-deploy it is.
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> 3. ovirt-deployer
>>>>>>>
>>>>>>> Any other idea will be most welcome, we need to close this
>>>>>>> fast
>>>>>>> to
>>>>>>> progress.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Alon Bar-Lev
>>>>>
>>>>> Thanks!
>>>>> 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  Wed Nov 21 22:45:50 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 21 Nov 2012 17:45:50 -0500 (EST)
Subject: [RFC] vdsm-bootstrap rewrite naming
In-Reply-To: <50AD593E.3060709@redhat.com>
Message-ID: <1880073902.988761.1353537950036.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, November 22, 2012 12:44:14 AM
> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> 
> On 11/19/2012 12:43 AM, Alon Bar-Lev wrote:
> > Hello,
> >
> > Final details:
> >
> > Common infrastructure
> >
> >    OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.
> >    Java name space: org.ovirt.otopi
> >    License: GPL2+
> >
> > Deploy code (aka vdsm-bootstrap)
> >
> >    ovirt-host-deploy
> >    Java name space: org.ovirt.ovirt_host_deploy
> >    License: GPL2+
> 
> as ovirt is ASL, please use LGPLv2.1+.

ACK, changed.

> 
> thanks,
>     Itamar
> 
> >
> > Thanks,
> > Alon.
> >
> > ----- Original Message -----
> >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: "arch" <arch at ovirt.org>
> >> Sent: Thursday, November 15, 2012 1:14:52 PM
> >> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >>> To: "Itamar Heim" <iheim at redhat.com>
> >>> Cc: "arch" <arch at ovirt.org>
> >>> Sent: Thursday, November 15, 2012 12:34:42 PM
> >>> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> >>>
> >>> Hello,
> >>>
> >>> Summary:
> >>>
> >>> Common infrastructure:
> >>> OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.
> >>>
> >>> Deploy code (vdsm-bootstrap):
> >>> ovirt-host-deploy
> >>>
> >>> I want to close this by Sunday to perform the rename, split,
> >>> create
> >>> repositories etc...
> >>>
> >>> So if anyone has more ideas, please raise a flags as after
> >>> renaming
> >>> it will be very difficult to change.
> >>>
> >>> Thanks,
> >>> Alon
> >>
> >> I forgot we need a namespace for the core specific java resources.
> >>
> >> Should it be org.ovirt.otopi or drop the ovirt in favour of
> >> org.otopi?
> >>
> >> Thanks,
> >> Alon.
> >>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: "arch" <arch at ovirt.org>
> >>>> Sent: Thursday, November 15, 2012 12:25:13 PM
> >>>> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> >>>>
> >>>> On 11/15/2012 12:22 PM, Alon Bar-Lev wrote:
> >>>>> OK, we need to close this up...
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>> Cc: "arch" <arch at ovirt.org>
> >>>>>> Sent: Tuesday, November 13, 2012 6:21:15 PM
> >>>>>> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> >>>>>>
> >>>>>> On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
> >>>>>>> Hello All,
> >>>>>>>
> >>>>>>> I am working on rewriting the vdsm-bootstrap process.
> >>>>>>>
> >>>>>>> I found that most of the installer implementation is not vdsm
> >>>>>>> specific, so I split the package into two:
> >>>>>>>
> >>>>>>>     core installer
> >>>>>>>     vdsm-bootstrap
> >>>>>>>
> >>>>>>> I would like to find a suitable name for the core installer.
> >>>>>>>
> >>>>>>> In nat shell:
> >>>>>>> """
> >>>>>>> Standalone plugin based installation framework to be used to
> >>>>>>> setup
> >>>>>>> system components. The plugin nature provides simplicity to
> >>>>>>> add new installation functionality without the complexity of
> >>>>>>> the
> >>>>>>> state
> >>>>>>> and transaction management.
> >>>>>>>
> >>>>>>> At the core of the implementation there is environment
> >>>>>>> dictionary
> >>>>>>> and
> >>>>>>> a flow of stages within plugins. The environment can be
> >>>>>>> modified
> >>>>>>> using
> >>>>>>> command-line parameters, configuration file, or dialog
> >>>>>>> customization.
> >>>>>>> """
> >>>>>>>
> >>>>>>> Sources are available at temporary location[1].
> >>>>>>>
> >>>>>>> Names that we thought of:
> >>>>>>> 1. ovirt-installer
> >>>>>>
> >>>>>> hmmm, that's between being generic, and consumable by others.
> >>>>>> question is how problematic it is if we keep our name...
> >>>>>> would be nice if we can advertise ourselves a bit.
> >>>>>> maybe we can compromise on:
> >>>>>> ogi - ovirt generic installer
> >>>>>>
> >>>>>> so name isn't directly with ovirt, but some marketing of ovirt
> >>>>>> from
> >>>>>> it
> >>>>>> may happen.
> >>>>>>
> >>>>>> so +1 to OGI from me.
> >>>>>>
> >>>>>>> 2. virtulation (virtualization + installation)
> >>>>>>> 3. virtaller (virtualization + installation)
> >>>>>>> 4. TOPI (Task Oriented Pluggable Installer/Implementation)
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> hmmm, spinning #1:
> >>>>>> OTOPI.
> >>>>>> has a nice ring to it around utopia as well.
> >>>>>>
> >>>>>
> >>>>> So OTOPI it is, well actually lower case otopi.
> >>>>>
> >>>>>>
> >>>>>>> 5. PDF (Pluggable Deployment Framework)
> >>>>>>
> >>>>>> -1 due to PDF so widely known as something else
> >>>>>>
> >>>>>>>
> >>>>>>> I would also like to consider if we want to keep the
> >>>>>>> vdsm-bootstrap
> >>>>>>> name for the bootstrap package, or we should use something
> >>>>>>> more
> >>>>>>> generic, as it really bootstrap the host and not vdsm...:
> >>>>>>> 1. ovirt-hypervisor-bootstrap
> >>>>>>> 2. ovirt-host-setup
> >>>>>>
> >>>>>> +1 to this one. not sure if critical to rename the rpm though.
> >>>>>
> >>>>> I think that with all alternatives, renaming the package will
> >>>>> make
> >>>>> it easy procedurally.
> >>>>> As the old ovirt-engine will continue to pull the existing
> >>>>> packages.
> >>>>> We do not need to handle conflicts or breakage.
> >>>>>
> >>>>> So can we close up with ovirt-host-setup?
> >>>>> I personally, think ovirt-host-deploy is better than setup.
> >>>>
> >>>> i'm fine either way.
> >>>
> >>> Great!
> >>> So ovirt-host-deploy it is.
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>> 3. ovirt-deployer
> >>>>>>>
> >>>>>>> Any other idea will be most welcome, we need to close this
> >>>>>>> fast
> >>>>>>> to
> >>>>>>> progress.
> >>>>>>>
> >>>>>>> Best Regards,
> >>>>>>> Alon Bar-Lev
> >>>>>
> >>>>> Thanks!
> >>>>> 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  Thu Nov 22 07:15:16 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 22 Nov 2012 02:15:16 -0500 (EST)
Subject: oVirt artifacts at maven repository
In-Reply-To: <1379322055.1043756.1353568472995.JavaMail.root@redhat.com>
Message-ID: <208243965.1043801.1353568516642.JavaMail.root@redhat.com>


Hello,

The otpoi and ovirt-host-deploy projects provides java artifacts so that ovirt-engine can be built using common constants and trivial parser.

I would like to publish these artifacts at maven central to ease ovirt-engine build, as it will automatically fetch these dependencies just like every other dependency.

In order to do so I need to sign the artifacts.

Questions:

Should we have unique key for each package?
Should we have single key for all oVirt releases?

The advantages of a key for each package is that the maintainer can release artifacts at will.
The advantage of single key is that a single trust can be obtained.

What do you think?
Alon.


From jhernand at redhat.com  Thu Nov 22 08:48:33 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Thu, 22 Nov 2012 09:48:33 +0100
Subject: oVirt artifacts at maven repository
In-Reply-To: <208243965.1043801.1353568516642.JavaMail.root@redhat.com>
References: <208243965.1043801.1353568516642.JavaMail.root@redhat.com>
Message-ID: <50ADE6E1.6050503@redhat.com>

On 11/22/2012 08:15 AM, Alon Bar-Lev wrote:
> 
> Hello,
> 
> The otpoi and ovirt-host-deploy projects provides java artifacts so that ovirt-engine can be built using common constants and trivial parser.
> 
> I would like to publish these artifacts at maven central to ease ovirt-engine build, as it will automatically fetch these dependencies just like every other dependency.
> 
> In order to do so I need to sign the artifacts.
> 
> Questions:
> 
> Should we have unique key for each package?
> Should we have single key for all oVirt releases?
> 
> The advantages of a key for each package is that the maintainer can release artifacts at will.
> The advantage of single key is that a single trust can be obtained.
> 
> What do you think?

When I have verified artifacts from maven (not many times, to be honest)
I always found that they are signed by different individuals, even if
they are from related projects.

I would suggest that the release manager for each project signs the
artifact with her/his key, as sharing private keys between different
people can be a nightmare, and not very secure.

I would also suggest that release managers sing each other code signing
keys.

-- 
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  Thu Nov 22 09:26:24 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 22 Nov 2012 04:26:24 -0500 (EST)
Subject: oVirt artifacts at maven repository
In-Reply-To: <50ADE6E1.6050503@redhat.com>
Message-ID: <434072671.1062883.1353576384566.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, November 22, 2012 10:48:33 AM
> Subject: Re: oVirt artifacts at maven repository
> 
> On 11/22/2012 08:15 AM, Alon Bar-Lev wrote:
> > 
> > Hello,
> > 
> > The otpoi and ovirt-host-deploy projects provides java artifacts so
> > that ovirt-engine can be built using common constants and trivial
> > parser.
> > 
> > I would like to publish these artifacts at maven central to ease
> > ovirt-engine build, as it will automatically fetch these
> > dependencies just like every other dependency.
> > 
> > In order to do so I need to sign the artifacts.
> > 
> > Questions:
> > 
> > Should we have unique key for each package?
> > Should we have single key for all oVirt releases?
> > 
> > The advantages of a key for each package is that the maintainer can
> > release artifacts at will.
> > The advantage of single key is that a single trust can be obtained.
> > 
> > What do you think?
> 
> When I have verified artifacts from maven (not many times, to be
> honest)
> I always found that they are signed by different individuals, even if
> they are from related projects.
> 
> I would suggest that the release manager for each project signs the
> artifact with her/his key, as sharing private keys between different
> people can be a nightmare, and not very secure.
> 
> I would also suggest that release managers sing each other code
> signing
> keys.

Thank you,

I don't think sharing a release key is a nightmare, as publishing artifacts or creating release is usually the role of 1-2 people.

I don't like using personal keys on outputs as people come and go, and it is very hard to match between the personal key and authorized signer.

I prefer single release key per release artifact (sub-project).

Regards,
Alon


From dneary at redhat.com  Thu Nov 22 14:11:48 2012
From: dneary at redhat.com (Dave Neary)
Date: Thu, 22 Nov 2012 15:11:48 +0100
Subject: Request for help: filling out a "Porting oVirt" checklist
Message-ID: <50AE32A4.3060907@redhat.com>

Hi all,

In the context of deploying the new site, I'm filling a couple of gaps 
we've identified in the content in the wiki. In particular, I started a 
"Porting oVirt" page today, aiming at developers who wish to do the 
integration work to use their preferred distro as an oVirt managed node: 
http://wiki.ovirt.org/wiki/Porting_oVirt

I have a very rough idea what's involved - the Guest agent, virtio and 
SPICE server need to work on guest OSes, and VDSM, libvirt and KVM need 
to be working well on the hypervisor.

Would someone mind reading over the page, and perhaps adding some 
checklists of stuff to check to ensure it's "working"? I would really 
appreciate it!

Thanks,
Dave.


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


From shaohef at linux.vnet.ibm.com  Thu Nov 22 09:00:18 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Thu, 22 Nov 2012 17:00:18 +0800
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <614856366.29225932.1353484824630.JavaMail.root@redhat.com>
References: <614856366.29225932.1353484824630.JavaMail.root@redhat.com>
Message-ID: <50ADE9A2.40400@linux.vnet.ibm.com>

On 11/21/2012 04:00 PM, Doron Fediuck wrote:
>
>     Currently, we do not have any plans to implement the engine side
>     of the feature.
>     But I will add a watchdog feature page to describe how engine
>     enable this feature. It's definitely great if any engine guy would
>     like to take the engine part. I will be glad to provide help if
>     needed.
>
> Hi Sheldon,
> Any news on the engine side?
> Currently the vdsm side is merged, while the engine side still missing.
> The wiki page also lacks the engine side. Can you please handle it?
Hi Doron,

I have updated the wiki page. 
http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device
And for vdsm side, I should also add a new patch to report the watchdog 
event.

I can add a flat to vm's status, so engine can poll vm's status to check 
the event then notify the user, and let the user to take some actions, 
such as restart or dump guest for analysis.
Perhaps event report channel is more better, but I have not find any in 
vdsm.  But it is a big work to add an event register mechanism for vdsm.

what's your suggestion?


-- 
Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center

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

From dfediuck at redhat.com  Thu Nov 22 09:54:14 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 22 Nov 2012 04:54:14 -0500 (EST)
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <50ADE9A2.40400@linux.vnet.ibm.com>
Message-ID: <396620953.29948603.1353578054166.JavaMail.root@redhat.com>


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

> From: "Sheldon" <shaohef at linux.vnet.ibm.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: arch at ovirt.org, "Zheng Sheng ZS Zhou" <zhshzhou at cn.ibm.com>,
> "Itamar Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com, "Shu Ming"
> <shuming at linux.vnet.ibm.com>, "Mark Wu" <wudxw at linux.vnet.ibm.com>,
> ryanh at us.ibm.com, snmishra at us.ibm.com, danken at redhat.com
> Sent: Thursday, November 22, 2012 11:00:18 AM
> Subject: Re: [vdsm] Review Request: Add an option to create a
> watchdog device.

> On 11/21/2012 04:00 PM, Doron Fediuck wrote:

> > > Currently, we do not have any plans to implement the engine side
> > > of
> > > the feature.
> > 
> 
> > > But I will add a watchdog feature page to describe how engine
> > > enable
> > > this feature. It's definitely great if any engine guy would like
> > > to
> > > take the engine part. I will be glad to provide help if needed.
> > 
> 
> > Hi Sheldon,
> 
> > Any news on the engine side?
> 
> > Currently the vdsm side is merged, while the engine side still
> > missing.
> 
> > The wiki page also lacks the engine side. Can you please handle it?
> 

> Hi Doron,

> I have updated the wiki page.
> http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device
> And for vdsm side, I should also add a new patch to report the
> watchdog event.

> I can add a flat to vm's status, so engine can poll vm's status to
> check the event then notify the user, and let the user to take some
> actions, such as restart or dump guest for analysis.
> Perhaps event report channel is more better, but I have not find any
> in vdsm. But it is a big work to add an event register mechanism for
> vdsm.

> what's your suggestion?

> --
> Sheldon Feng(???) <shaohef at linux.vnet.ibm.com> IBM Linux Technology
> Center

Hi Sheldon,
AFAIK, watchdog fires automatically, so no real need for user interaction
when an event happens. So I'd expect the user to set the relevant action
before starting the VM. Once the watchdog is triggered, it will do whatever
action he has set, and notify the user.

So I'd expect the user to have a list of actions for the watchdog device
in the engine UI, with a default of none. The user should be able to choose
which action to set when starting or editing the VM (for next run).

In the host level, vdsm should get the notification from libvirt, and as
you suggested report it in the vm stats when polled by the engine. So
the user can see the notification on a watchdog action taken, and he can still
stop / restart the VM if he wishes to.

Does that make sense?


From ryanh at us.ibm.com  Mon Nov 26 14:01:48 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Mon, 26 Nov 2012 08:01:48 -0600
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <396620953.29948603.1353578054166.JavaMail.root@redhat.com>
References: <50ADE9A2.40400@linux.vnet.ibm.com>
	<396620953.29948603.1353578054166.JavaMail.root@redhat.com>
Message-ID: <20121126140148.GY15882@frylock.phx.austin.ibm.com>

* Doron Fediuck <dfediuck at redhat.com> [2012-11-22 03:56]:
> 
> ----- Original Message ----- 
> 
> > From: "Sheldon" <shaohef at linux.vnet.ibm.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: arch at ovirt.org, "Zheng Sheng ZS Zhou" <zhshzhou at cn.ibm.com>,
> > "Itamar Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com, "Shu Ming"
> > <shuming at linux.vnet.ibm.com>, "Mark Wu" <wudxw at linux.vnet.ibm.com>,
> > ryanh at us.ibm.com, snmishra at us.ibm.com, danken at redhat.com
> > Sent: Thursday, November 22, 2012 11:00:18 AM
> > Subject: Re: [vdsm] Review Request: Add an option to create a
> > watchdog device.
> 
> > On 11/21/2012 04:00 PM, Doron Fediuck wrote:
> 
> > > > Currently, we do not have any plans to implement the engine side
> > > > of
> > > > the feature.
> > > 
> > 
> > > > But I will add a watchdog feature page to describe how engine
> > > > enable
> > > > this feature. It's definitely great if any engine guy would like
> > > > to
> > > > take the engine part. I will be glad to provide help if needed.
> > > 
> > 
> > > Hi Sheldon,
> > 
> > > Any news on the engine side?
> > 
> > > Currently the vdsm side is merged, while the engine side still
> > > missing.
> > 
> > > The wiki page also lacks the engine side. Can you please handle it?
> > 
> 
> > Hi Doron,
> 
> > I have updated the wiki page.
> > http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device
> > And for vdsm side, I should also add a new patch to report the
> > watchdog event.
> 
> > I can add a flat to vm's status, so engine can poll vm's status to
> > check the event then notify the user, and let the user to take some
> > actions, such as restart or dump guest for analysis.
> > Perhaps event report channel is more better, but I have not find any
> > in vdsm. But it is a big work to add an event register mechanism for
> > vdsm.
> 
> > what's your suggestion?
> 
> > --
> > Sheldon Feng(?????????) <shaohef at linux.vnet.ibm.com> IBM Linux Technology
> > Center
> 
> Hi Sheldon,
> AFAIK, watchdog fires automatically, so no real need for user interaction
> when an event happens. So I'd expect the user to set the relevant action
> before starting the VM. Once the watchdog is triggered, it will do whatever
> action he has set, and notify the user.
> 
> So I'd expect the user to have a list of actions for the watchdog device
> in the engine UI, with a default of none. The user should be able to choose
> which action to set when starting or editing the VM (for next run).

I'd like to suggest we pick something other than none by default since
we've gone through the trouble of configuring and enabling a watchdog.
I think it's worth the discussion of what a better default behavior
should be given access to a watchdog.

I'd suggest that a simple reboot mode would be most useful.

> 
> In the host level, vdsm should get the notification from libvirt, and as
> you suggested report it in the vm stats when polled by the engine. So
> the user can see the notification on a watchdog action taken, and he can still
> stop / restart the VM if he wishes to.
> 
> Does that make sense?

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com



From dfediuck at redhat.com  Mon Nov 26 15:12:22 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 26 Nov 2012 10:12:22 -0500 (EST)
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <20121126140148.GY15882@frylock.phx.austin.ibm.com>
Message-ID: <1390356932.33368605.1353942742322.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Ryan Harper" <ryanh at us.ibm.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "Sheldon" <shaohef at linux.vnet.ibm.com>, arch at ovirt.org, "Zheng Sheng ZS Zhou" <zhshzhou at cn.ibm.com>, "Itamar
> Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com, "Shu Ming" <shuming at linux.vnet.ibm.com>, "Mark Wu"
> <wudxw at linux.vnet.ibm.com>, ryanh at us.ibm.com, snmishra at us.ibm.com, danken at redhat.com
> Sent: Monday, November 26, 2012 4:01:48 PM
> Subject: Re: [vdsm] Review Request: Add an option to create a watchdog device.
> 
> * Doron Fediuck <dfediuck at redhat.com> [2012-11-22 03:56]:
> > 
> > ----- Original Message -----
> > 
> > > From: "Sheldon" <shaohef at linux.vnet.ibm.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: arch at ovirt.org, "Zheng Sheng ZS Zhou" <zhshzhou at cn.ibm.com>,
> > > "Itamar Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com, "Shu
> > > Ming"
> > > <shuming at linux.vnet.ibm.com>, "Mark Wu"
> > > <wudxw at linux.vnet.ibm.com>,
> > > ryanh at us.ibm.com, snmishra at us.ibm.com, danken at redhat.com
> > > Sent: Thursday, November 22, 2012 11:00:18 AM
> > > Subject: Re: [vdsm] Review Request: Add an option to create a
> > > watchdog device.
> > 
> > > On 11/21/2012 04:00 PM, Doron Fediuck wrote:
> > 
> > > > > Currently, we do not have any plans to implement the engine
> > > > > side
> > > > > of
> > > > > the feature.
> > > > 
> > > 
> > > > > But I will add a watchdog feature page to describe how engine
> > > > > enable
> > > > > this feature. It's definitely great if any engine guy would
> > > > > like
> > > > > to
> > > > > take the engine part. I will be glad to provide help if
> > > > > needed.
> > > > 
> > > 
> > > > Hi Sheldon,
> > > 
> > > > Any news on the engine side?
> > > 
> > > > Currently the vdsm side is merged, while the engine side still
> > > > missing.
> > > 
> > > > The wiki page also lacks the engine side. Can you please handle
> > > > it?
> > > 
> > 
> > > Hi Doron,
> > 
> > > I have updated the wiki page.
> > > http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device
> > > And for vdsm side, I should also add a new patch to report the
> > > watchdog event.
> > 
> > > I can add a flat to vm's status, so engine can poll vm's status
> > > to
> > > check the event then notify the user, and let the user to take
> > > some
> > > actions, such as restart or dump guest for analysis.
> > > Perhaps event report channel is more better, but I have not find
> > > any
> > > in vdsm. But it is a big work to add an event register mechanism
> > > for
> > > vdsm.
> > 
> > > what's your suggestion?
> > 
> > > --
> > > Sheldon Feng(?????????) <shaohef at linux.vnet.ibm.com> IBM Linux
> > > Technology
> > > Center
> > 
> > Hi Sheldon,
> > AFAIK, watchdog fires automatically, so no real need for user
> > interaction
> > when an event happens. So I'd expect the user to set the relevant
> > action
> > before starting the VM. Once the watchdog is triggered, it will do
> > whatever
> > action he has set, and notify the user.
> > 
> > So I'd expect the user to have a list of actions for the watchdog
> > device
> > in the engine UI, with a default of none. The user should be able
> > to choose
> > which action to set when starting or editing the VM (for next run).
> 
> I'd like to suggest we pick something other than none by default
> since
> we've gone through the trouble of configuring and enabling a
> watchdog.
> I think it's worth the discussion of what a better default behavior
> should be given access to a watchdog.
> 
> I'd suggest that a simple reboot mode would be most useful.
> 

Hi Ryan, good point.
The reason I asked for none is exactly since someone though of it
when writing the device actions. ie- otherwise no-op makes no sense,
but as we all know no-op sometimes proves to be a much needed option
if not the default one.
In this context, a watchdog has quite an explosive potential for a VM.
So for the sake of all users I'd rather ask them to specify exactly
what should be done. Otherwise- Primum non nocere. I'm sure one day
someone will appreciate it.

> > 
> > In the host level, vdsm should get the notification from libvirt,
> > and as
> > you suggested report it in the vm stats when polled by the engine.
> > So
> > the user can see the notification on a watchdog action taken, and
> > he can still
> > stop / restart the VM if he wishes to.
> > 
> > Does that make sense?
> 
> --
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> ryanh at us.ibm.com
> 
> 


From ryanh at us.ibm.com  Mon Nov 26 15:50:34 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Mon, 26 Nov 2012 09:50:34 -0600
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <1390356932.33368605.1353942742322.JavaMail.root@redhat.com>
References: <20121126140148.GY15882@frylock.phx.austin.ibm.com>
	<1390356932.33368605.1353942742322.JavaMail.root@redhat.com>
Message-ID: <20121126155034.GC15882@frylock.phx.austin.ibm.com>

* Doron Fediuck <dfediuck at redhat.com> [2012-11-26 09:20]:
> ----- Original Message -----
> > From: "Ryan Harper" <ryanh at us.ibm.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "Sheldon" <shaohef at linux.vnet.ibm.com>, arch at ovirt.org, "Zheng Sheng ZS Zhou" <zhshzhou at cn.ibm.com>, "Itamar
> > Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com, "Shu Ming" <shuming at linux.vnet.ibm.com>, "Mark Wu"
> > <wudxw at linux.vnet.ibm.com>, ryanh at us.ibm.com, snmishra at us.ibm.com, danken at redhat.com
> > Sent: Monday, November 26, 2012 4:01:48 PM
> > Subject: Re: [vdsm] Review Request: Add an option to create a watchdog device.
> > 
> > * Doron Fediuck <dfediuck at redhat.com> [2012-11-22 03:56]:
> > > 
> > > ----- Original Message -----
> > > 
> > > > From: "Sheldon" <shaohef at linux.vnet.ibm.com>
> > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > Cc: arch at ovirt.org, "Zheng Sheng ZS Zhou" <zhshzhou at cn.ibm.com>,
> > > > "Itamar Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com, "Shu
> > > > Ming"
> > > > <shuming at linux.vnet.ibm.com>, "Mark Wu"
> > > > <wudxw at linux.vnet.ibm.com>,
> > > > ryanh at us.ibm.com, snmishra at us.ibm.com, danken at redhat.com
> > > > Sent: Thursday, November 22, 2012 11:00:18 AM
> > > > Subject: Re: [vdsm] Review Request: Add an option to create a
> > > > watchdog device.
> > > 
> > > > On 11/21/2012 04:00 PM, Doron Fediuck wrote:
> > > 
> > > > > > Currently, we do not have any plans to implement the engine
> > > > > > side
> > > > > > of
> > > > > > the feature.
> > > > > 
> > > > 
> > > > > > But I will add a watchdog feature page to describe how engine
> > > > > > enable
> > > > > > this feature. It's definitely great if any engine guy would
> > > > > > like
> > > > > > to
> > > > > > take the engine part. I will be glad to provide help if
> > > > > > needed.
> > > > > 
> > > > 
> > > > > Hi Sheldon,
> > > > 
> > > > > Any news on the engine side?
> > > > 
> > > > > Currently the vdsm side is merged, while the engine side still
> > > > > missing.
> > > > 
> > > > > The wiki page also lacks the engine side. Can you please handle
> > > > > it?
> > > > 
> > > 
> > > > Hi Doron,
> > > 
> > > > I have updated the wiki page.
> > > > http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device
> > > > And for vdsm side, I should also add a new patch to report the
> > > > watchdog event.
> > > 
> > > > I can add a flat to vm's status, so engine can poll vm's status
> > > > to
> > > > check the event then notify the user, and let the user to take
> > > > some
> > > > actions, such as restart or dump guest for analysis.
> > > > Perhaps event report channel is more better, but I have not find
> > > > any
> > > > in vdsm. But it is a big work to add an event register mechanism
> > > > for
> > > > vdsm.
> > > 
> > > > what's your suggestion?
> > > 
> > > > --
> > > > Sheldon Feng(?????????) <shaohef at linux.vnet.ibm.com> IBM Linux
> > > > Technology
> > > > Center
> > > 
> > > Hi Sheldon,
> > > AFAIK, watchdog fires automatically, so no real need for user
> > > interaction
> > > when an event happens. So I'd expect the user to set the relevant
> > > action
> > > before starting the VM. Once the watchdog is triggered, it will do
> > > whatever
> > > action he has set, and notify the user.
> > > 
> > > So I'd expect the user to have a list of actions for the watchdog
> > > device
> > > in the engine UI, with a default of none. The user should be able
> > > to choose
> > > which action to set when starting or editing the VM (for next run).
> > 
> > I'd like to suggest we pick something other than none by default
> > since
> > we've gone through the trouble of configuring and enabling a
> > watchdog.
> > I think it's worth the discussion of what a better default behavior
> > should be given access to a watchdog.
> > 
> > I'd suggest that a simple reboot mode would be most useful.
> > 
> 
> Hi Ryan, good point.
> The reason I asked for none is exactly since someone though of it
> when writing the device actions. ie- otherwise no-op makes no sense,
> but as we all know no-op sometimes proves to be a much needed option
> if not the default one.
> In this context, a watchdog has quite an explosive potential for a VM.
> So for the sake of all users I'd rather ask them to specify exactly
> what should be done. Otherwise- Primum non nocere. I'm sure one day
> someone will appreciate it.

While I understand what your saying; I think it's worth actually walking
through all of the actions and selecting the best here.  VDSM has a role
to play here in how *best* to configure a VM.  I think that a watchdog
can elevate the usefulness of a VM by ensuring that it stays running
without user intervention.

As you say, having an unexpected reboot when it's not wanted can cause
an issue, so we have at least two areas to discuss:

1) watchdog fidelity; does it do what it's supposed to do at the right
time and not malfunction.  This requires testing and use to validate.
Leaving the watchdog off by default will certainly reduce the amount of
testing time.

2) watchdog configuration.  What's the most reasonable and helpful
configuration, this includes the action as well as any variables
associated with that specific action.  I think the best course here is
to propose an initial configuration and start getting some test-time
under the configuration for validation.

If we're unwilling to enable an action by default, I'd like to have a
discussion around why that's the case.  The initial objection to
always-on with action=reboot seems to be concern about the watchdog
misfiring when it shouldn't.   Are their other concerns?

Another thought here is to think about the target guest OS type.  It may
be the case that specific actions/configurations make sense for one OS,
but not the other[1]

There was an engine-devel thread about libosinfo integration[2].


1. http://rwmj.wordpress.com/2010/03/03/what-is-a-watchdog/#comment-4959
2. http://lists.ovirt.org/pipermail/engine-devel/2012-September/002544.html


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com



From dfediuck at redhat.com  Mon Nov 26 17:35:41 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 26 Nov 2012 12:35:41 -0500 (EST)
Subject: [vdsm] Review Request: Add an option to create a watchdog device.
In-Reply-To: <20121126155034.GC15882@frylock.phx.austin.ibm.com>
Message-ID: <1897002313.33586223.1353951341226.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ryan Harper" <ryanh at us.ibm.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "Ryan Harper" <ryanh at us.ibm.com>, "Sheldon" <shaohef at linux.vnet.ibm.com>, arch at ovirt.org, "Zheng Sheng ZS Zhou"
> <zhshzhou at cn.ibm.com>, "Itamar Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com, "Shu Ming"
> <shuming at linux.vnet.ibm.com>, "Mark Wu" <wudxw at linux.vnet.ibm.com>, snmishra at us.ibm.com, danken at redhat.com
> Sent: Monday, November 26, 2012 5:50:34 PM
> Subject: Re: [vdsm] Review Request: Add an option to create a watchdog device.
> 
> * Doron Fediuck <dfediuck at redhat.com> [2012-11-26 09:20]:
> > ----- Original Message -----
> > > From: "Ryan Harper" <ryanh at us.ibm.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: "Sheldon" <shaohef at linux.vnet.ibm.com>, arch at ovirt.org,
> > > "Zheng Sheng ZS Zhou" <zhshzhou at cn.ibm.com>, "Itamar
> > > Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com, "Shu Ming"
> > > <shuming at linux.vnet.ibm.com>, "Mark Wu"
> > > <wudxw at linux.vnet.ibm.com>, ryanh at us.ibm.com,
> > > snmishra at us.ibm.com, danken at redhat.com
> > > Sent: Monday, November 26, 2012 4:01:48 PM
> > > Subject: Re: [vdsm] Review Request: Add an option to create a
> > > watchdog device.
> > > 
> > > * Doron Fediuck <dfediuck at redhat.com> [2012-11-22 03:56]:
> > > > 
> > > > ----- Original Message -----
> > > > 
> > > > > From: "Sheldon" <shaohef at linux.vnet.ibm.com>
> > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > Cc: arch at ovirt.org, "Zheng Sheng ZS Zhou"
> > > > > <zhshzhou at cn.ibm.com>,
> > > > > "Itamar Heim" <iheim at redhat.com>, agl at linux.vnet.ibm.com,
> > > > > "Shu
> > > > > Ming"
> > > > > <shuming at linux.vnet.ibm.com>, "Mark Wu"
> > > > > <wudxw at linux.vnet.ibm.com>,
> > > > > ryanh at us.ibm.com, snmishra at us.ibm.com, danken at redhat.com
> > > > > Sent: Thursday, November 22, 2012 11:00:18 AM
> > > > > Subject: Re: [vdsm] Review Request: Add an option to create a
> > > > > watchdog device.
> > > > 
> > > > > On 11/21/2012 04:00 PM, Doron Fediuck wrote:
> > > > 
> > > > > > > Currently, we do not have any plans to implement the
> > > > > > > engine
> > > > > > > side
> > > > > > > of
> > > > > > > the feature.
> > > > > > 
> > > > > 
> > > > > > > But I will add a watchdog feature page to describe how
> > > > > > > engine
> > > > > > > enable
> > > > > > > this feature. It's definitely great if any engine guy
> > > > > > > would
> > > > > > > like
> > > > > > > to
> > > > > > > take the engine part. I will be glad to provide help if
> > > > > > > needed.
> > > > > > 
> > > > > 
> > > > > > Hi Sheldon,
> > > > > 
> > > > > > Any news on the engine side?
> > > > > 
> > > > > > Currently the vdsm side is merged, while the engine side
> > > > > > still
> > > > > > missing.
> > > > > 
> > > > > > The wiki page also lacks the engine side. Can you please
> > > > > > handle
> > > > > > it?
> > > > > 
> > > > 
> > > > > Hi Doron,
> > > > 
> > > > > I have updated the wiki page.
> > > > > http://wiki.ovirt.org/wiki/Add_an_option_to_create_a_watchdog_device
> > > > > And for vdsm side, I should also add a new patch to report
> > > > > the
> > > > > watchdog event.
> > > > 
> > > > > I can add a flat to vm's status, so engine can poll vm's
> > > > > status
> > > > > to
> > > > > check the event then notify the user, and let the user to
> > > > > take
> > > > > some
> > > > > actions, such as restart or dump guest for analysis.
> > > > > Perhaps event report channel is more better, but I have not
> > > > > find
> > > > > any
> > > > > in vdsm. But it is a big work to add an event register
> > > > > mechanism
> > > > > for
> > > > > vdsm.
> > > > 
> > > > > what's your suggestion?
> > > > 
> > > > > --
> > > > > Sheldon Feng(?????????) <shaohef at linux.vnet.ibm.com> IBM
> > > > > Linux
> > > > > Technology
> > > > > Center
> > > > 
> > > > Hi Sheldon,
> > > > AFAIK, watchdog fires automatically, so no real need for user
> > > > interaction
> > > > when an event happens. So I'd expect the user to set the
> > > > relevant
> > > > action
> > > > before starting the VM. Once the watchdog is triggered, it will
> > > > do
> > > > whatever
> > > > action he has set, and notify the user.
> > > > 
> > > > So I'd expect the user to have a list of actions for the
> > > > watchdog
> > > > device
> > > > in the engine UI, with a default of none. The user should be
> > > > able
> > > > to choose
> > > > which action to set when starting or editing the VM (for next
> > > > run).
> > > 
> > > I'd like to suggest we pick something other than none by default
> > > since
> > > we've gone through the trouble of configuring and enabling a
> > > watchdog.
> > > I think it's worth the discussion of what a better default
> > > behavior
> > > should be given access to a watchdog.
> > > 
> > > I'd suggest that a simple reboot mode would be most useful.
> > > 
> > 
> > Hi Ryan, good point.
> > The reason I asked for none is exactly since someone though of it
> > when writing the device actions. ie- otherwise no-op makes no
> > sense,
> > but as we all know no-op sometimes proves to be a much needed
> > option
> > if not the default one.
> > In this context, a watchdog has quite an explosive potential for a
> > VM.
> > So for the sake of all users I'd rather ask them to specify exactly
> > what should be done. Otherwise- Primum non nocere. I'm sure one day
> > someone will appreciate it.
> 
> While I understand what your saying; I think it's worth actually
> walking
> through all of the actions and selecting the best here.  VDSM has a
> role
> to play here in how *best* to configure a VM.  I think that a
> watchdog
> can elevate the usefulness of a VM by ensuring that it stays running
> without user intervention.
> 

Ryan, you're mixing vdsm and engine.
My response was to the way engine UI will present it to the user:

> > > > So I'd expect the user to have a list of actions for the
> > > > watchdog
> > > > device
> > > > in the engine UI, with a default of none. The user should be
> > > > able
> > > > to choose
> > > > which action to set when starting or editing the VM (for next
> > > > run).

So this is not about vdsm, but about engine UI.

As for VDSM's role on the best VM configuration, I disagree on this point.
What's best for your VM will not always be best for my VM, especially
when reboot is being considered. So unless there's a 100% fool-proof reason,
do no harm.

> As you say, having an unexpected reboot when it's not wanted can
> cause
> an issue, so we have at least two areas to discuss:
> 
> 1) watchdog fidelity; does it do what it's supposed to do at the
> right
> time and not malfunction.  This requires testing and use to validate.
> Leaving the watchdog off by default will certainly reduce the amount
> of
> testing time.
> 
> 2) watchdog configuration.  What's the most reasonable and helpful
> configuration, this includes the action as well as any variables
> associated with that specific action.  I think the best course here
> is
> to propose an initial configuration and start getting some test-time
> under the configuration for validation.
> 

Ryan, just reminding you this is an engine UI thread.
As such I'd be very careful from rebooting anything as a default.
This is not an audio or VGA card where you can fallback to lower resolution,
this will kill your guest, with everything running in it.

> If we're unwilling to enable an action by default, I'd like to have a
> discussion around why that's the case.  The initial objection to
> always-on with action=reboot seems to be concern about the watchdog
> misfiring when it shouldn't.   Are their other concerns?
> 

Yes. Googling will provide you several watchdog-related cases, which
I can't quote here due to copyrights of the relevant KBs. The general
idea is that one of 3 things causes WD to fire;
1. watchdog driver issues
2. Guest OS low on resources (potentially swapping), but still running
3. Host issues, such as sockets exhausted, etc.

The main thing is, that in none of the above, rebooting the VM will
improve the situation. If any it will make it worst. By default...

> Another thought here is to think about the target guest OS type.  It
> may
> be the case that specific actions/configurations make sense for one
> OS,
> but not the other[1]
> 
> There was an engine-devel thread about libosinfo integration[2].
> 
> 

See my previous comment for relevant cases. As a default watchdog policy
I'd rather be safe than sorry. Most KBs I saw would tell you to stop
the watchdog service / remove the device to begin with. Then you get
a bug fix. But as you probably understand, for some users this already
did some damage.

One more thing you need to consider is exporting and importing VMs, as
well as VM templates and pools. Here as well you may get unpleasant surprise
if you use a VM with a watchdog that will bite by default.

> 1.
> http://rwmj.wordpress.com/2010/03/03/what-is-a-watchdog/#comment-4959
> 2.
> http://lists.ovirt.org/pipermail/engine-devel/2012-September/002544.html
> 
> 
> --
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> ryanh at us.ibm.com
> 
> 


From lpeer at redhat.com  Tue Nov 27 13:01:33 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 27 Nov 2012 15:01:33 +0200
Subject: ovirt-quantum integration
Message-ID: <50B4B9AD.7010600@redhat.com>

Hi All,
Mike Kolesnik and me have been working on a proposal for integrating
quantum into oVirt in the past few weeks.
We decided to focus our efforts on integrating with quantum services, we
started with IP address management service.

here is a link to our proposal:
http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration

As usual comments are welcome,

Livnat


From gkotton at redhat.com  Tue Nov 27 13:46:48 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Tue, 27 Nov 2012 15:46:48 +0200
Subject: ovirt-quantum integration
In-Reply-To: <50B4B9AD.7010600@redhat.com>
References: <50B4B9AD.7010600@redhat.com>
Message-ID: <50B4C448.2010005@redhat.com>

On 11/27/2012 03:01 PM, Livnat Peer wrote:
> Hi All,
> Mike Kolesnik and me have been working on a proposal for integrating
> quantum into oVirt in the past few weeks.
> We decided to focus our efforts on integrating with quantum services, we
> started with IP address management service.
>
> here is a link to our proposal:
> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>
> As usual comments are welcome,
Please see my comments below:

i. The quantum diagram is incorrect. It is the same message queue that
passes the notifications. This is done by a message broker. In RH we are
supporting qpid and in the community upstream rabbitmq is used.
ii. The DHCP agent is plugable. That is there may be more than one
implementation. At the moment only dnsmasq is support. There was a
company working on ISC upstream but they have stopped due to problem
they encountered.
iii. Layer 3 driver. This is incorrect. The layer 2 agent does the
network connectivity. The layer 3 agent provides floating IP support.
This is something that you may want to consider to. It is related to IPAM
iv. I am not really sure I understand you picture with server B and
get/create network. This is not really what happens. If you want I can
explain.
v. What do you mean by the "port is then part of the Quantum DB". Not
all plugins maintain a database.
vi. I think that you are missing useful information about the subnets
and gateways. This is also a critical part of the IPAM. When a VM sends
a DHCP request it not only gets and IP but it can also receive host
route information. This is very important.
vii. The DHCP agent dynamics are incorrect (l3 agent, write port
definitions etc.). One of the pain points is that the process is for
each quantum network. This is a scale issue and is being discussed
upstream.
viii. Quantum does not require homogeneous  hardware. This is incorrect.
There is something called a provider network that addresses this.
ix. I do not udnerstand the race when the VM starts. There is none. When
a VM starts it will send a DHCP request. If it does not receive one it
will send another after a timeout. Can you please explain the race?

You do not need to consume Quantum to provide IPAM. You can just run the
dnsmasq and make sure that its interface is connected to the virtual
network. This will provide you with the functionality that you are
looking for. If you want I go can over the dirty details. It will be far
less time than consuming Quantum and you can achieve the same goal. You
just need to be aware when the dnsmasq is running to sent the updates.

IPAM is one of the many features that Quantum has to offer. It will certain
help oVirt.

Thanks
Gary


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



From mkolesni at redhat.com  Tue Nov 27 14:06:14 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 27 Nov 2012 09:06:14 -0500 (EST)
Subject: ovirt-quantum integration
In-Reply-To: <50B4C448.2010005@redhat.com>
Message-ID: <1034808037.17794745.1354025174695.JavaMail.root@redhat.com>

Thanks for the reply,
Please see comments inline

----- Original Message -----
> On 11/27/2012 03:01 PM, Livnat Peer wrote:
> > Hi All,
> > Mike Kolesnik and me have been working on a proposal for
> > integrating
> > quantum into oVirt in the past few weeks.
> > We decided to focus our efforts on integrating with quantum
> > services, we
> > started with IP address management service.
> >
> > here is a link to our proposal:
> > http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
> >
> > As usual comments are welcome,
> Please see my comments below:
> 
> i. The quantum diagram is incorrect. It is the same message queue
> that
> passes the notifications. This is done by a message broker. In RH we
> are
> supporting qpid and in the community upstream rabbitmq is used.

I will fix the diagram accordingly

> ii. The DHCP agent is plugable. That is there may be more than one
> implementation. At the moment only dnsmasq is support. There was a
> company working on ISC upstream but they have stopped due to problem
> they encountered.
> iii. Layer 3 driver. This is incorrect. The layer 2 agent does the
> network connectivity. The layer 3 agent provides floating IP support.
> This is something that you may want to consider to. It is related to
> IPAM
> iv. I am not really sure I understand you picture with server B and
> get/create network. This is not really what happens. If you want I
> can
> explain.

We saw that the DHCP Agent is trying to create the network interface if it doesn't exist (in DeviceManager.setup which is called as part of "enable_dhcp_helper").

If you want to elaborate on this, please do.

> v. What do you mean by the "port is then part of the Quantum DB". Not
> all plugins maintain a database.

True but if it's not saved somewhere then how does the Agent know which IP to assign to which MAC?

> vi. I think that you are missing useful information about the subnets
> and gateways. This is also a critical part of the IPAM. When a VM
> sends
> a DHCP request it not only gets and IP but it can also receive host
> route information. This is very important.

can you please elaborate on this?

> vii. The DHCP agent dynamics are incorrect (l3 agent, write port
> definitions etc.). One of the pain points is that the process is for
> each quantum network. This is a scale issue and is being discussed
> upstream.

This is what we saw that happens in the code, if we are wrong please explain what is the right behaviour of the DHCP Agent.

> viii. Quantum does not require homogeneous  hardware. This is
> incorrect.
> There is something called a provider network that addresses this.

Can you please elaborate?

> ix. I do not udnerstand the race when the VM starts. There is none.
> When
> a VM starts it will send a DHCP request. If it does not receive one
> it
> will send another after a timeout. Can you please explain the race?

This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.

> 
> You do not need to consume Quantum to provide IPAM. You can just run
> the
> dnsmasq and make sure that its interface is connected to the virtual
> network. This will provide you with the functionality that you are
> looking for. If you want I go can over the dirty details. It will be
> far
> less time than consuming Quantum and you can achieve the same goal.
> You
> just need to be aware when the dnsmasq is running to sent the
> updates.
> 
> IPAM is one of the many features that Quantum has to offer. It will
> certain
> help oVirt.
> 
> Thanks
> Gary


From gkotton at redhat.com  Tue Nov 27 14:34:43 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Tue, 27 Nov 2012 16:34:43 +0200
Subject: ovirt-quantum integration
In-Reply-To: <1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
References: <1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
Message-ID: <50B4CF83.1050907@redhat.com>

On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
> Thanks for the reply,
> Please see comments inline
>
> ----- Original Message -----
>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
>>> Hi All,
>>> Mike Kolesnik and me have been working on a proposal for
>>> integrating
>>> quantum into oVirt in the past few weeks.
>>> We decided to focus our efforts on integrating with quantum
>>> services, we
>>> started with IP address management service.
>>>
>>> here is a link to our proposal:
>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>>
>>> As usual comments are welcome,
>> Please see my comments below:
>>
>> i. The quantum diagram is incorrect. It is the same message queue
>> that
>> passes the notifications. This is done by a message broker. In RH we
>> are
>> supporting qpid and in the community upstream rabbitmq is used.
> I will fix the diagram accordingly

Thanks
>
>> ii. The DHCP agent is plugable. That is there may be more than one
>> implementation. At the moment only dnsmasq is support. There was a
>> company working on ISC upstream but they have stopped due to problem
>> they encountered.
>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does the
>> network connectivity. The layer 3 agent provides floating IP support.
>> This is something that you may want to consider to. It is related to
>> IPAM
>> iv. I am not really sure I understand you picture with server B and
>> get/create network. This is not really what happens. If you want I
>> can
>> explain.
> We saw that the DHCP Agent is trying to create the network interface if it doesn't exist (in DeviceManager.setup which is called as part of "enable_dhcp_helper").
>
> If you want to elaborate on this, please do.

The DHCP agent will create a device that is used by the dnsmasq process. 
The creation is done according to a driver that is used for the 
underlying l2 implementation. It does not have anything to do the the 
layer 3 agent. It creates a network device and assigns it an IP address. 
The layer 2 agent (if there is one) will attach this device to the 
underlying virtual network.
Prior to doing anything the DHCP agent will create a quantum port on the 
subnet. This is how it receives its own IP address.

>
>> v. What do you mean by the "port is then part of the Quantum DB". Not
>> all plugins maintain a database.
> True but if it's not saved somewhere then how does the Agent know which IP to assign to which MAC?

The DHCP agent is notified by the Quantum service of a new port 
allocation. It is passed the port details - the mac address and the IP 
address. The plugin may not use a database that one can access. All of 
the interface to the data is done via the Quantum API. For example the NVP.

>
>> vi. I think that you are missing useful information about the subnets
>> and gateways. This is also a critical part of the IPAM. When a VM
>> sends
>> a DHCP request it not only gets and IP but it can also receive host
>> route information. This is very important.
> can you please elaborate on this?

When you reboot your computer at work you get access to the internet. 
This is done via DHCP. You get an IP address and all of the relevant 
routes configured. The port data has the 'host_routes' which is also 
used by the dnsmasq. There can be more than one route which is 
configured. The subnet contains the gateway IP.

>
>> vii. The DHCP agent dynamics are incorrect (l3 agent, write port
>> definitions etc.). One of the pain points is that the process is for
>> each quantum network. This is a scale issue and is being discussed
>> upstream.
> This is what we saw that happens in the code, if we are wrong please explain what is the right behaviour of the DHCP Agent.

For each network that has one or more subnets with DHCP support a 
dnsmasq process is created. Please see http://fpaste.org/IHbA/. Here I 
have two networks.

>
>> viii. Quantum does not require homogeneous  hardware. This is
>> incorrect.
>> There is something called a provider network that addresses this.
> Can you please elaborate?

When you create a network you can indicate which NIC connects to the 
outside world. If you look at 
http://wiki.openstack.org/ConfigureOpenvswitch then you will see the 
bridge mappings. This information is passed via the API.
>
>> ix. I do not udnerstand the race when the VM starts. There is none.
>> When
>> a VM starts it will send a DHCP request. If it does not receive one
>> it
>> will send another after a timeout. Can you please explain the race?
> This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.

This works. This is how DHCP is engineered. Can you please explain the 
problem? If you send a DHCP request and do not get a reply then you send 
one again. The timeout between requests is incremental.

I am not sure that we are on the same page when it comes to a race 
condition. I'd like you to clarify.
>
>> You do not need to consume Quantum to provide IPAM. You can just run
>> the
>> dnsmasq and make sure that its interface is connected to the virtual
>> network. This will provide you with the functionality that you are
>> looking for. If you want I go can over the dirty details. It will be
>> far
>> less time than consuming Quantum and you can achieve the same goal.
>> You
>> just need to be aware when the dnsmasq is running to sent the
>> updates.
>>
>> IPAM is one of the many features that Quantum has to offer. It will
>> certain
>> help oVirt.
>>
>> Thanks
>> Gary



From danken at redhat.com  Tue Nov 27 14:38:28 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 27 Nov 2012 16:38:28 +0200
Subject: ovirt-quantum integration
In-Reply-To: <1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
References: <50B4C448.2010005@redhat.com>
	<1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
Message-ID: <20121127143828.GH5083@redhat.com>

On Tue, Nov 27, 2012 at 09:06:14AM -0500, Mike Kolesnik wrote:

> 
> > ix. I do not udnerstand the race when the VM starts. There is none.
> > When
> > a VM starts it will send a DHCP request. If it does not receive one
> > it
> > will send another after a timeout. Can you please explain the race?
> 
> This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.

I think the point is that a guest dhclient may give up before Quantum
allocates it an IP. Maybe, due to timing and guests' behavior, the race
would not show up, but it is still there.


From gkotton at redhat.com  Tue Nov 27 14:43:52 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Tue, 27 Nov 2012 16:43:52 +0200
Subject: ovirt-quantum integration
In-Reply-To: <20121127143828.GH5083@redhat.com>
References: <50B4C448.2010005@redhat.com>
	<1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<20121127143828.GH5083@redhat.com>
Message-ID: <50B4D1A8.4060403@redhat.com>

On 11/27/2012 04:38 PM, Dan Kenigsberg wrote:
> On Tue, Nov 27, 2012 at 09:06:14AM -0500, Mike Kolesnik wrote:
>
>>> ix. I do not udnerstand the race when the VM starts. There is none.
>>> When
>>> a VM starts it will send a DHCP request. If it does not receive one
>>> it
>>> will send another after a timeout. Can you please explain the race?
>> This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.
> I think the point is that a guest dhclient may give up before Quantum
> allocates it an IP. Maybe, due to timing and guests' behavior, the race
> would not show up, but it is still there.

Yes, this is certainly something that can happen if there are networking 
problems or if something in the system is broken. How is it done today 
in oVirt? Does someone has to go and manually update the DHCP server?
If the messaging is a real concern then you can piggyback to DHCP 
information on the RPC call to VDSM where the DHCP agent will be 
running. This will ensure that the information exists in the host file 
prior to running the VM.




From danken at redhat.com  Tue Nov 27 15:06:27 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 27 Nov 2012 17:06:27 +0200
Subject: ovirt-quantum integration
In-Reply-To: <50B4D1A8.4060403@redhat.com>
References: <50B4C448.2010005@redhat.com>
	<1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<20121127143828.GH5083@redhat.com> <50B4D1A8.4060403@redhat.com>
Message-ID: <20121127150627.GJ5083@redhat.com>

On Tue, Nov 27, 2012 at 04:43:52PM +0200, Gary Kotton wrote:
> On 11/27/2012 04:38 PM, Dan Kenigsberg wrote:
> >On Tue, Nov 27, 2012 at 09:06:14AM -0500, Mike Kolesnik wrote:
> >
> >>>ix. I do not udnerstand the race when the VM starts. There is none.
> >>>When
> >>>a VM starts it will send a DHCP request. If it does not receive one
> >>>it
> >>>will send another after a timeout. Can you please explain the race?
> >>This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.
> >I think the point is that a guest dhclient may give up before Quantum
> >allocates it an IP. Maybe, due to timing and guests' behavior, the race
> >would not show up, but it is still there.
> 
> Yes, this is certainly something that can happen if there are
> networking problems or if something in the system is broken. How is
> it done today in oVirt? Does someone has to go and manually update
> the DHCP server?

It's not done in oVirt, we want to gain it from Quantum...
Now you'd have to log into the guest and re-initiate dhclient (or
restart the guest) after manually configuring the DHCP server.

> If the messaging is a real concern then you can piggyback to DHCP
> information on the RPC call to VDSM where the DHCP agent will be
> running. This will ensure that the information exists in the host
> file prior to running the VM.



From gkotton at redhat.com  Tue Nov 27 15:12:32 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Tue, 27 Nov 2012 17:12:32 +0200
Subject: ovirt-quantum integration
In-Reply-To: <20121127150627.GJ5083@redhat.com>
References: <50B4C448.2010005@redhat.com>
	<1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<20121127143828.GH5083@redhat.com> <50B4D1A8.4060403@redhat.com>
	<20121127150627.GJ5083@redhat.com>
Message-ID: <50B4D860.8020801@redhat.com>

On 11/27/2012 05:06 PM, Dan Kenigsberg wrote:
> On Tue, Nov 27, 2012 at 04:43:52PM +0200, Gary Kotton wrote:
>> On 11/27/2012 04:38 PM, Dan Kenigsberg wrote:
>>> On Tue, Nov 27, 2012 at 09:06:14AM -0500, Mike Kolesnik wrote:
>>>
>>>>> ix. I do not udnerstand the race when the VM starts. There is none.
>>>>> When
>>>>> a VM starts it will send a DHCP request. If it does not receive one
>>>>> it
>>>>> will send another after a timeout. Can you please explain the race?
>>>> This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.
>>> I think the point is that a guest dhclient may give up before Quantum
>>> allocates it an IP. Maybe, due to timing and guests' behavior, the race
>>> would not show up, but it is still there.
>> Yes, this is certainly something that can happen if there are
>> networking problems or if something in the system is broken. How is
>> it done today in oVirt? Does someone has to go and manually update
>> the DHCP server?
> It's not done in oVirt, we want to gain it from Quantum...
> Now you'd have to log into the guest and re-initiate dhclient (or
> restart the guest) after manually configuring the DHCP server.

Quantum is certainly not perfect. It has a number of shortcomings but it 
does work. There are a number of major cloud providers that are using it 
and I do not recall them mentioning that they had problems with the 
timeout for the DHCP requests.

My two cents is that oVirt has a to gain by using Quantum. Quantum is 
moving fast - at the moment there is a lot of work being done with the 
addition of LBaaS. This is currently aimed at the end of the current 
release cycle.

This is a game changer for oVirt.

>
>> If the messaging is a real concern then you can piggyback to DHCP
>> information on the RPC call to VDSM where the DHCP agent will be
>> running. This will ensure that the information exists in the host
>> file prior to running the VM.



From danken at redhat.com  Tue Nov 27 16:08:23 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 27 Nov 2012 18:08:23 +0200
Subject: ovirt-quantum integration
In-Reply-To: <50B4D860.8020801@redhat.com>
References: <50B4C448.2010005@redhat.com>
	<1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<20121127143828.GH5083@redhat.com> <50B4D1A8.4060403@redhat.com>
	<20121127150627.GJ5083@redhat.com> <50B4D860.8020801@redhat.com>
Message-ID: <20121127160823.GL5083@redhat.com>

On Tue, Nov 27, 2012 at 05:12:32PM +0200, Gary Kotton wrote:
> On 11/27/2012 05:06 PM, Dan Kenigsberg wrote:
> >On Tue, Nov 27, 2012 at 04:43:52PM +0200, Gary Kotton wrote:
> >>On 11/27/2012 04:38 PM, Dan Kenigsberg wrote:
> >>>On Tue, Nov 27, 2012 at 09:06:14AM -0500, Mike Kolesnik wrote:
> >>>
> >>>>>ix. I do not udnerstand the race when the VM starts. There is none.
> >>>>>When
> >>>>>a VM starts it will send a DHCP request. If it does not receive one
> >>>>>it
> >>>>>will send another after a timeout. Can you please explain the race?
> >>>>This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.
> >>>I think the point is that a guest dhclient may give up before Quantum
> >>>allocates it an IP. Maybe, due to timing and guests' behavior, the race
> >>>would not show up, but it is still there.
> >>Yes, this is certainly something that can happen if there are
> >>networking problems or if something in the system is broken. How is
> >>it done today in oVirt? Does someone has to go and manually update
> >>the DHCP server?
> >It's not done in oVirt, we want to gain it from Quantum...
> >Now you'd have to log into the guest and re-initiate dhclient (or
> >restart the guest) after manually configuring the DHCP server.
> 
> Quantum is certainly not perfect. It has a number of shortcomings
> but it does work. There are a number of major cloud providers that
> are using it and I do not recall them mentioning that they had
> problems with the timeout for the DHCP requests.
> 
> My two cents is that oVirt has a to gain by using Quantum. Quantum
> is moving fast - at the moment there is a lot of work being done
> with the addition of LBaaS. This is currently aimed at the end of
> the current release cycle.
> 
> This is a game changer for oVirt.

There is no doubt here about that. oVirt is far from perfect, and as a
first modest step towards perfection, we are going to use Quantum's
l3 address allocation - we just need learn to tame it.

> 
> >
> >>If the messaging is a real concern then you can piggyback to DHCP
> >>information on the RPC call to VDSM where the DHCP agent will be
> >>running. This will ensure that the information exists in the host
> >>file prior to running the VM.

On a second read, I'm not sure I understand your suggestion: do you
suggest to allocate the address with Quantum, send it to the destination
host on top of vmCreate verb, and pass it to a local instance on
dnsmasq? This would make Quantum's DHCP agent redundant, as well as the
newly-suggested setDHCP verb that's designed to turn it on.

Dan.


From gkotton at redhat.com  Tue Nov 27 16:26:12 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Tue, 27 Nov 2012 18:26:12 +0200
Subject: ovirt-quantum integration
In-Reply-To: <20121127160823.GL5083@redhat.com>
References: <50B4C448.2010005@redhat.com>
	<1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<20121127143828.GH5083@redhat.com> <50B4D1A8.4060403@redhat.com>
	<20121127150627.GJ5083@redhat.com> <50B4D860.8020801@redhat.com>
	<20121127160823.GL5083@redhat.com>
Message-ID: <50B4E9A4.6030300@redhat.com>

On 11/27/2012 06:08 PM, Dan Kenigsberg wrote:
> On Tue, Nov 27, 2012 at 05:12:32PM +0200, Gary Kotton wrote:
>> On 11/27/2012 05:06 PM, Dan Kenigsberg wrote:
>>> On Tue, Nov 27, 2012 at 04:43:52PM +0200, Gary Kotton wrote:
>>>> On 11/27/2012 04:38 PM, Dan Kenigsberg wrote:
>>>>> On Tue, Nov 27, 2012 at 09:06:14AM -0500, Mike Kolesnik wrote:
>>>>>
>>>>>>> ix. I do not udnerstand the race when the VM starts. There is none.
>>>>>>> When
>>>>>>> a VM starts it will send a DHCP request. If it does not receive one
>>>>>>> it
>>>>>>> will send another after a timeout. Can you please explain the race?
>>>>>> This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.
>>>>> I think the point is that a guest dhclient may give up before Quantum
>>>>> allocates it an IP. Maybe, due to timing and guests' behavior, the race
>>>>> would not show up, but it is still there.
>>>> Yes, this is certainly something that can happen if there are
>>>> networking problems or if something in the system is broken. How is
>>>> it done today in oVirt? Does someone has to go and manually update
>>>> the DHCP server?
>>> It's not done in oVirt, we want to gain it from Quantum...
>>> Now you'd have to log into the guest and re-initiate dhclient (or
>>> restart the guest) after manually configuring the DHCP server.
>> Quantum is certainly not perfect. It has a number of shortcomings
>> but it does work. There are a number of major cloud providers that
>> are using it and I do not recall them mentioning that they had
>> problems with the timeout for the DHCP requests.
>>
>> My two cents is that oVirt has a to gain by using Quantum. Quantum
>> is moving fast - at the moment there is a lot of work being done
>> with the addition of LBaaS. This is currently aimed at the end of
>> the current release cycle.
>>
>> This is a game changer for oVirt.
> There is no doubt here about that. oVirt is far from perfect, and as a
> first modest step towards perfection, we are going to use Quantum's
> l3 address allocation - we just need learn to tame it.

Not sure that tame it is the correct terminology. It is not clear how 
one will be able to take certain parts of Quantum. But that is another 
issue.
>
>>>> If the messaging is a real concern then you can piggyback to DHCP
>>>> information on the RPC call to VDSM where the DHCP agent will be
>>>> running. This will ensure that the information exists in the host
>>>> file prior to running the VM.
> On a second read, I'm not sure I understand your suggestion: do you
> suggest to allocate the address with Quantum, send it to the destination
> host on top of vmCreate verb, and pass it to a local instance on
> dnsmasq? This would make Quantum's DHCP agent redundant, as well as the
> newly-suggested setDHCP verb that's designed to turn it on.

I am not familiar with the verb setDHCP. The DHCP agent manages a 
dbsmasq class. You can make use of this directly in VDSM where you 
control the updates of the DHCP data and the launching of the VM. This 
is a hybrid of Quantum and oVirt/VDSM (this is #3 below)

I think that you have a number of options and I'd like to elaborate:
1. Consume Quantum as it is (with the good and the bad).
2. Consume building blocks of of Quantum and wrap certain interfaces 
with oVirt/VDSM proprietary implementations (say for example instead of 
using a messge broker, make use of the RPC commands that you have 
today). In OpenStack there is a common RPC library. You can leverage 
this interface to have more control over what happens and when.
3. Forget Quantum and build it yourself using ideas and lessons from Quantum

My leanings would be for #1 but it would certainly be worthwhile looking 
into #2. Maybe with little effort you can use existing API's and have 
the best of both worlds.


>
> Dan.



From lpeer at redhat.com  Wed Nov 28 11:34:23 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 28 Nov 2012 13:34:23 +0200
Subject: ovirt-quantum integration
In-Reply-To: <50B4CF83.1050907@redhat.com>
References: <1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<50B4CF83.1050907@redhat.com>
Message-ID: <50B5F6BF.10904@redhat.com>

On 27/11/12 16:34, Gary Kotton wrote:
> On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
>> Thanks for the reply,
>> Please see comments inline
>>

Hi Garry,
Thanks for your input, see my comments inline.

Livnat

>> ----- Original Message -----
>>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
>>>> Hi All,
>>>> Mike Kolesnik and me have been working on a proposal for
>>>> integrating
>>>> quantum into oVirt in the past few weeks.
>>>> We decided to focus our efforts on integrating with quantum
>>>> services, we
>>>> started with IP address management service.
>>>>
>>>> here is a link to our proposal:
>>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>>>
>>>> As usual comments are welcome,
>>> Please see my comments below:
>>>
>>> i. The quantum diagram is incorrect. It is the same message queue
>>> that
>>> passes the notifications. This is done by a message broker. In RH we
>>> are
>>> supporting qpid and in the community upstream rabbitmq is used.
>> I will fix the diagram accordingly
> 
> Thanks
>>
>>> ii. The DHCP agent is plugable. That is there may be more than one
>>> implementation. At the moment only dnsmasq is support. There was a
>>> company working on ISC upstream but they have stopped due to problem
>>> they encountered.
>>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does the
>>> network connectivity. The layer 3 agent provides floating IP support.
>>> This is something that you may want to consider to. It is related to
>>> IPAM

>From what we gathered from code the DHCP Agent is communicating with (an
implementation of the) LinuxInterfaceDriver, which is not the same as
the layer 2 agent used in the plugin.

For example, looking in Linux bridge, the plugin has
Linux_bridge_quantum agent that is part of the Linux bridge plugin, and
it has (what we called Layer 3 driver) a BridgeInterfaceDriver that is
used within the DHCP Agent.

Maybe we used a misleading terminology but 'layer 2 agent' is also
misleading, IMO, as it is already used in the plugin context and this is
not the same component.

We'll update the doc to call it 'layer 2 driver'.

>>> iv. I am not really sure I understand you picture with server B and
>>> get/create network. This is not really what happens. If you want I
>>> can
>>> explain.
>> We saw that the DHCP Agent is trying to create the network interface
>> if it doesn't exist (in DeviceManager.setup which is called as part of
>> "enable_dhcp_helper").
>>
>> If you want to elaborate on this, please do.
> 
> The DHCP agent will create a device that is used by the dnsmasq process.
> The creation is done according to a driver that is used for the
> underlying l2 implementation. It does not have anything to do the the
> layer 3 agent. 

Again the same terminology misunderstanding.

> It creates a network device and assigns it an IP address.
> The layer 2 agent (if there is one) will attach this device to the
> underlying virtual network.

It seems to be our understanding and what we have described in the wiki
page, do you see something wrong there?

> Prior to doing anything the DHCP agent will create a quantum port on the
> subnet. This is how it receives its own IP address.
> 
>>
>>> v. What do you mean by the "port is then part of the Quantum DB". Not
>>> all plugins maintain a database.
>> True but if it's not saved somewhere then how does the Agent know
>> which IP to assign to which MAC?
> 
> The DHCP agent is notified by the Quantum service of a new port
> allocation. It is passed the port details - the mac address and the IP
> address. The plugin may not use a database that one can access. All of
> the interface to the data is done via the Quantum API. For example the NVP.
> 
>>
>>> vi. I think that you are missing useful information about the subnets
>>> and gateways. This is also a critical part of the IPAM. When a VM
>>> sends
>>> a DHCP request it not only gets and IP but it can also receive host
>>> route information. This is very important.
>> can you please elaborate on this?
> 
> When you reboot your computer at work you get access to the internet.
> This is done via DHCP. You get an IP address and all of the relevant
> routes configured. The port data has the 'host_routes' which is also
> used by the dnsmasq. There can be more than one route which is
> configured. The subnet contains the gateway IP.
> 

We assumed that when creating the subnet in Quantum it would update the
DHCP Agent with all the information oVirt will provide as part of the
subnet details (dns_nameservers, host_routes, gateway_ip  etc).
Isn't this the case?

>>
>>> vii. The DHCP agent dynamics are incorrect (l3 agent, write port
>>> definitions etc.). One of the pain points is that the process is for
>>> each quantum network. This is a scale issue and is being discussed
>>> upstream.
>> This is what we saw that happens in the code, if we are wrong please
>> explain what is the right behaviour of the DHCP Agent.
> 
> For each network that has one or more subnets with DHCP support a
> dnsmasq process is created. Please see http://fpaste.org/IHbA/. Here I
> have two networks.

That's exactly what we have described in the wiki. dnsmasq per network.
In the integration with oVirt we planned that the ovirt layer2 driver
will not return interface_name where there is no need for the dnsmasq
locally on the host.
This requires a patch to Quantum that in case the driver returns empty
device name the dnsmasq won't be started.
We'll send a patch for that soon.
I added that to the wiki as well.

> 
>>
>>> viii. Quantum does not require homogeneous  hardware. This is
>>> incorrect.
>>> There is something called a provider network that addresses this.
>> Can you please elaborate?
> 
> When you create a network you can indicate which NIC connects to the
> outside world. If you look at
> http://wiki.openstack.org/ConfigureOpenvswitch then you will see the
> bridge mappings. This information is passed via the API.

Our understanding is that Quantum IPAM design assumes the DHCP Agent has
local access to *ALL* the networks created in quantum.
Per Network it spawns a local dnsmasq and connect it to the network
(which should be accessible from within the host on which the DHCP Agent
is running on).

This assumption is problematic in the oVirt context and this is the
issue we were trying to overcome in the proposed integration.

>>
>>> ix. I do not udnerstand the race when the VM starts. There is none.
>>> When
>>> a VM starts it will send a DHCP request. If it does not receive one
>>> it
>>> will send another after a timeout. Can you please explain the race?
>> This is exactly it, the VM might start requesting DHCP lease before it
>> was updated in the DHCP server, for us it's a race.
> 
> This works. This is how DHCP is engineered. Can you please explain the
> problem? If you send a DHCP request and do not get a reply then you send
> one again. The timeout between requests is incremental.
> 
> I am not sure that we are on the same page when it comes to a race
> condition. I'd like you to clarify.
>>
>>> You do not need to consume Quantum to provide IPAM. You can just run
>>> the
>>> dnsmasq and make sure that its interface is connected to the virtual
>>> network. This will provide you with the functionality that you are
>>> looking for. If you want I go can over the dirty details. It will be
>>> far
>>> less time than consuming Quantum and you can achieve the same goal.
>>> You
>>> just need to be aware when the dnsmasq is running to sent the
>>> updates.
>>>
>>> IPAM is one of the many features that Quantum has to offer. It will
>>> certain
>>> help oVirt.
>>>
>>> Thanks
>>> Gary
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From gkotton at redhat.com  Wed Nov 28 12:00:51 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Wed, 28 Nov 2012 14:00:51 +0200
Subject: ovirt-quantum integration
In-Reply-To: <50B5F6BF.10904@redhat.com>
References: <1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<50B4CF83.1050907@redhat.com> <50B5F6BF.10904@redhat.com>
Message-ID: <50B5FCF3.4030301@redhat.com>

On 11/28/2012 01:34 PM, Livnat Peer wrote:
> On 27/11/12 16:34, Gary Kotton wrote:
>> On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
>>> Thanks for the reply,
>>> Please see comments inline
>>>
> Hi Garry,
> Thanks for your input, see my comments inline.
>
> Livnat
>
>>> ----- Original Message -----
>>>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
>>>>> Hi All,
>>>>> Mike Kolesnik and me have been working on a proposal for
>>>>> integrating
>>>>> quantum into oVirt in the past few weeks.
>>>>> We decided to focus our efforts on integrating with quantum
>>>>> services, we
>>>>> started with IP address management service.
>>>>>
>>>>> here is a link to our proposal:
>>>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>>>>
>>>>> As usual comments are welcome,
>>>> Please see my comments below:
>>>>
>>>> i. The quantum diagram is incorrect. It is the same message queue
>>>> that
>>>> passes the notifications. This is done by a message broker. In RH we
>>>> are
>>>> supporting qpid and in the community upstream rabbitmq is used.
>>> I will fix the diagram accordingly
>> Thanks
>>>> ii. The DHCP agent is plugable. That is there may be more than one
>>>> implementation. At the moment only dnsmasq is support. There was a
>>>> company working on ISC upstream but they have stopped due to problem
>>>> they encountered.
>>>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does the
>>>> network connectivity. The layer 3 agent provides floating IP support.
>>>> This is something that you may want to consider to. It is related to
>>>> IPAM
>  From what we gathered from code the DHCP Agent is communicating with (an
> implementation of the) LinuxInterfaceDriver, which is not the same as
> the layer 2 agent used in the plugin.

Correct. The DHCP agent needs to create the relevant interfaces. The 
layer 2 is responsible for attaching these interfaces to the network.

>
> For example, looking in Linux bridge, the plugin has
> Linux_bridge_quantum agent that is part of the Linux bridge plugin, and
> it has (what we called Layer 3 driver) a BridgeInterfaceDriver that is
> used within the DHCP Agent.
>
> Maybe we used a misleading terminology but 'layer 2 agent' is also
> misleading, IMO, as it is already used in the plugin context and this is
> not the same component.
>
> We'll update the doc to call it 'layer 2 driver'.
>
>>>> iv. I am not really sure I understand you picture with server B and
>>>> get/create network. This is not really what happens. If you want I
>>>> can
>>>> explain.
>>> We saw that the DHCP Agent is trying to create the network interface
>>> if it doesn't exist (in DeviceManager.setup which is called as part of
>>> "enable_dhcp_helper").
>>>
>>> If you want to elaborate on this, please do.
>> The DHCP agent will create a device that is used by the dnsmasq process.
>> The creation is done according to a driver that is used for the
>> underlying l2 implementation. It does not have anything to do the the
>> layer 3 agent.
> Again the same terminology misunderstanding.
>
>> It creates a network device and assigns it an IP address.
>> The layer 2 agent (if there is one) will attach this device to the
>> underlying virtual network.
> It seems to be our understanding and what we have described in the wiki
> page, do you see something wrong there?
>
>> Prior to doing anything the DHCP agent will create a quantum port on the
>> subnet. This is how it receives its own IP address.
>>
>>>> v. What do you mean by the "port is then part of the Quantum DB". Not
>>>> all plugins maintain a database.
>>> True but if it's not saved somewhere then how does the Agent know
>>> which IP to assign to which MAC?
>> The DHCP agent is notified by the Quantum service of a new port
>> allocation. It is passed the port details - the mac address and the IP
>> address. The plugin may not use a database that one can access. All of
>> the interface to the data is done via the Quantum API. For example the NVP.
>>
>>>> vi. I think that you are missing useful information about the subnets
>>>> and gateways. This is also a critical part of the IPAM. When a VM
>>>> sends
>>>> a DHCP request it not only gets and IP but it can also receive host
>>>> route information. This is very important.
>>> can you please elaborate on this?
>> When you reboot your computer at work you get access to the internet.
>> This is done via DHCP. You get an IP address and all of the relevant
>> routes configured. The port data has the 'host_routes' which is also
>> used by the dnsmasq. There can be more than one route which is
>> configured. The subnet contains the gateway IP.
>>
> We assumed that when creating the subnet in Quantum it would update the
> DHCP Agent with all the information oVirt will provide as part of the
> subnet details (dns_nameservers, host_routes, gateway_ip  etc).
> Isn't this the case?

Yes it is. I was misleading as the wiki only referred to Quantum ports 
and not subnets. If I understand correctly then you will be using the 
entire Quantum service? Will this include floating IP's security groups 
etc.?
>
>>>> vii. The DHCP agent dynamics are incorrect (l3 agent, write port
>>>> definitions etc.). One of the pain points is that the process is for
>>>> each quantum network. This is a scale issue and is being discussed
>>>> upstream.
>>> This is what we saw that happens in the code, if we are wrong please
>>> explain what is the right behaviour of the DHCP Agent.
>> For each network that has one or more subnets with DHCP support a
>> dnsmasq process is created. Please see http://fpaste.org/IHbA/. Here I
>> have two networks.
> That's exactly what we have described in the wiki. dnsmasq per network.
> In the integration with oVirt we planned that the ovirt layer2 driver
> will not return interface_name where there is no need for the dnsmasq
> locally on the host.

I do not think that this will work - you will need to attach the dnsmasq 
to the network. At the moment Quantum does not run the dnsmasq on the 
compute nodes. There is a notion of a network node when various services 
can run. One of the issues that we are dealing with at the moment is HA 
and scale for the DHCP agents. At the moment only one DHCP agent can 
run. The open issue is that if the DHCP agent sees thousands of networks 
then it will create dnsmasq process for each network killing the node 
local resources.

> This requires a patch to Quantum that in case the driver returns empty
> device name the dnsmasq won't be started.

I am not sure that I understand. The DHCP agent has to create a device 
to interface with the outside world. If the device fails to be created 
then the dnsmasq process will not be spawned.

> We'll send a patch for that soon.
> I added that to the wiki as well.
>
>>>> viii. Quantum does not require homogeneous  hardware. This is
>>>> incorrect.
>>>> There is something called a provider network that addresses this.
>>> Can you please elaborate?
>> When you create a network you can indicate which NIC connects to the
>> outside world. If you look at
>> http://wiki.openstack.org/ConfigureOpenvswitch then you will see the
>> bridge mappings. This information is passed via the API.
> Our understanding is that Quantum IPAM design assumes the DHCP Agent has
> local access to *ALL* the networks created in quantum.

IPAM is part of the Quantum API. That is, Quantum provides and interface 
for logical ports to be assigned an IP address. The DHCP agent is one 
way of implementing this. The DHCP agent interfaces with the Quantum 
plugin to receive the information that it requires. Currently tyhe DHCP 
agent is able to get information for all networks.

> Per Network it spawns a local dnsmasq and connect it to the network
> (which should be accessible from within the host on which the DHCP Agent
> is running on).

The dnsmasq is able to be accessed from all compute nodes on the 
network. From what you are mentioning here is that you guys will be 
taking a hybrid approach to using Quantum. Correct?

>
> This assumption is problematic in the oVirt context and this is the
> issue we were trying to overcome in the proposed integration.

I am sorry but I am not sure that I understand the issue that you are 
trying to overcome. In theory more than one DHCP server can run. This is 
how people provide HA. One of the servers will answer. Do you plan to 
have a DHCP agent running on each vdsm node? Nova networking has support 
for a feature like this. It is called multinode. It is something that is 
under discussion in Quantum.
>
>>>> ix. I do not udnerstand the race when the VM starts. There is none.
>>>> When
>>>> a VM starts it will send a DHCP request. If it does not receive one
>>>> it
>>>> will send another after a timeout. Can you please explain the race?
>>> This is exactly it, the VM might start requesting DHCP lease before it
>>> was updated in the DHCP server, for us it's a race.
>> This works. This is how DHCP is engineered. Can you please explain the
>> problem? If you send a DHCP request and do not get a reply then you send
>> one again. The timeout between requests is incremental.
>>
>> I am not sure that we are on the same page when it comes to a race
>> condition. I'd like you to clarify.
>>>> You do not need to consume Quantum to provide IPAM. You can just run
>>>> the
>>>> dnsmasq and make sure that its interface is connected to the virtual
>>>> network. This will provide you with the functionality that you are
>>>> looking for. If you want I go can over the dirty details. It will be
>>>> far
>>>> less time than consuming Quantum and you can achieve the same goal.
>>>> You
>>>> just need to be aware when the dnsmasq is running to sent the
>>>> updates.
>>>>
>>>> IPAM is one of the many features that Quantum has to offer. It will
>>>> certain
>>>> help oVirt.
>>>>
>>>> Thanks
>>>> Gary
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch



From danken at redhat.com  Wed Nov 28 11:55:02 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 28 Nov 2012 13:55:02 +0200
Subject: [Users] oVirt 3.2 Released Delayed
In-Reply-To: <1352981981.4817.34.camel@beelzebub.mburnsfire.net>
References: <1352981981.4817.34.camel@beelzebub.mburnsfire.net>
Message-ID: <20121128115502.GT5083@redhat.com>

On Thu, Nov 15, 2012 at 07:19:41AM -0500, Mike Burns wrote:
> Due to a desire to support Fedora 18 and the Fedora 18 schedule slip, we
> have delayed the upcoming 3.2 release.  The new target dates are now:
> 
> Devel Freeze/Beta:  	2012-11-28
> Test Day: 		2012-12-11
> GA:			2013-01-09

Today is devel freeze, but we have several issues blocking us from
a release. I've created Bug 881006 - Tracker: oVirt 3.2 release; please
make it depend on stuff that we must solve before releasing.

Dan.


From lpeer at redhat.com  Wed Nov 28 13:46:52 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 28 Nov 2012 15:46:52 +0200
Subject: ovirt-quantum integration
In-Reply-To: <50B5FCF3.4030301@redhat.com>
References: <1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<50B4CF83.1050907@redhat.com> <50B5F6BF.10904@redhat.com>
	<50B5FCF3.4030301@redhat.com>
Message-ID: <50B615CC.1060609@redhat.com>

On 28/11/12 14:00, Gary Kotton wrote:
> On 11/28/2012 01:34 PM, Livnat Peer wrote:
>> On 27/11/12 16:34, Gary Kotton wrote:
>>> On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
>>>> Thanks for the reply,
>>>> Please see comments inline
>>>>
>> Hi Garry,
>> Thanks for your input, see my comments inline.
>>
>> Livnat
>>
>>>> ----- Original Message -----
>>>>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
>>>>>> Hi All,
>>>>>> Mike Kolesnik and me have been working on a proposal for
>>>>>> integrating
>>>>>> quantum into oVirt in the past few weeks.
>>>>>> We decided to focus our efforts on integrating with quantum
>>>>>> services, we
>>>>>> started with IP address management service.
>>>>>>
>>>>>> here is a link to our proposal:
>>>>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>>>>>
>>>>>> As usual comments are welcome,
>>>>> Please see my comments below:
>>>>>
>>>>> i. The quantum diagram is incorrect. It is the same message queue
>>>>> that
>>>>> passes the notifications. This is done by a message broker. In RH we
>>>>> are
>>>>> supporting qpid and in the community upstream rabbitmq is used.
>>>> I will fix the diagram accordingly
>>> Thanks
>>>>> ii. The DHCP agent is plugable. That is there may be more than one
>>>>> implementation. At the moment only dnsmasq is support. There was a
>>>>> company working on ISC upstream but they have stopped due to problem
>>>>> they encountered.
>>>>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does the
>>>>> network connectivity. The layer 3 agent provides floating IP support.
>>>>> This is something that you may want to consider to. It is related to
>>>>> IPAM
>>  From what we gathered from code the DHCP Agent is communicating with (an
>> implementation of the) LinuxInterfaceDriver, which is not the same as
>> the layer 2 agent used in the plugin.
> 
> Correct. The DHCP agent needs to create the relevant interfaces. The
> layer 2 is responsible for attaching these interfaces to the network.
> 
>>
>> For example, looking in Linux bridge, the plugin has
>> Linux_bridge_quantum agent that is part of the Linux bridge plugin, and
>> it has (what we called Layer 3 driver) a BridgeInterfaceDriver that is
>> used within the DHCP Agent.
>>
>> Maybe we used a misleading terminology but 'layer 2 agent' is also
>> misleading, IMO, as it is already used in the plugin context and this is
>> not the same component.
>>
>> We'll update the doc to call it 'layer 2 driver'.
>>
>>>>> iv. I am not really sure I understand you picture with server B and
>>>>> get/create network. This is not really what happens. If you want I
>>>>> can
>>>>> explain.
>>>> We saw that the DHCP Agent is trying to create the network interface
>>>> if it doesn't exist (in DeviceManager.setup which is called as part of
>>>> "enable_dhcp_helper").
>>>>
>>>> If you want to elaborate on this, please do.
>>> The DHCP agent will create a device that is used by the dnsmasq process.
>>> The creation is done according to a driver that is used for the
>>> underlying l2 implementation. It does not have anything to do the the
>>> layer 3 agent.
>> Again the same terminology misunderstanding.
>>
>>> It creates a network device and assigns it an IP address.
>>> The layer 2 agent (if there is one) will attach this device to the
>>> underlying virtual network.
>> It seems to be our understanding and what we have described in the wiki
>> page, do you see something wrong there?
>>
>>> Prior to doing anything the DHCP agent will create a quantum port on the
>>> subnet. This is how it receives its own IP address.
>>>
>>>>> v. What do you mean by the "port is then part of the Quantum DB". Not
>>>>> all plugins maintain a database.
>>>> True but if it's not saved somewhere then how does the Agent know
>>>> which IP to assign to which MAC?
>>> The DHCP agent is notified by the Quantum service of a new port
>>> allocation. It is passed the port details - the mac address and the IP
>>> address. The plugin may not use a database that one can access. All of
>>> the interface to the data is done via the Quantum API. For example
>>> the NVP.
>>>
>>>>> vi. I think that you are missing useful information about the subnets
>>>>> and gateways. This is also a critical part of the IPAM. When a VM
>>>>> sends
>>>>> a DHCP request it not only gets and IP but it can also receive host
>>>>> route information. This is very important.
>>>> can you please elaborate on this?
>>> When you reboot your computer at work you get access to the internet.
>>> This is done via DHCP. You get an IP address and all of the relevant
>>> routes configured. The port data has the 'host_routes' which is also
>>> used by the dnsmasq. There can be more than one route which is
>>> configured. The subnet contains the gateway IP.
>>>
>> We assumed that when creating the subnet in Quantum it would update the
>> DHCP Agent with all the information oVirt will provide as part of the
>> subnet details (dns_nameservers, host_routes, gateway_ip  etc).
>> Isn't this the case?
> 
> Yes it is. I was misleading as the wiki only referred to Quantum ports
> and not subnets. If I understand correctly then you will be using the
> entire Quantum service? Will this include floating IP's security groups
> etc.?

I did not review security group and floating IP provided by quantum. Can
you please point us to a documentation on these?


>>
>>>>> vii. The DHCP agent dynamics are incorrect (l3 agent, write port
>>>>> definitions etc.). One of the pain points is that the process is for
>>>>> each quantum network. This is a scale issue and is being discussed
>>>>> upstream.
>>>> This is what we saw that happens in the code, if we are wrong please
>>>> explain what is the right behaviour of the DHCP Agent.
>>> For each network that has one or more subnets with DHCP support a
>>> dnsmasq process is created. Please see http://fpaste.org/IHbA/. Here I
>>> have two networks.
>> That's exactly what we have described in the wiki. dnsmasq per network.
>> In the integration with oVirt we planned that the ovirt layer2 driver
>> will not return interface_name where there is no need for the dnsmasq
>> locally on the host.
> 
> I do not think that this will work - you will need to attach the dnsmasq
> to the network. At the moment Quantum does not run the dnsmasq on the
> compute nodes. There is a notion of a network node when various services
> can run. One of the issues that we are dealing with at the moment is HA
> and scale for the DHCP agents. At the moment only one DHCP agent can
> run. The open issue is that if the DHCP agent sees thousands of networks
> then it will create dnsmasq process for each network killing the node
> local resources.
> 

That's exactly the problems we addressed in our proposal.
In the integration proposal we'll deploy the DHCP-Agent on the hosts
(where and when is defined via the the setupDHCP API we added to oVirt),
and we'll have more than one DHCP Agent...each DHCP Agent will manage
the networks available on the host it is deployed on.
The wiki page describes how we intend to do it.
We actually leverage the fact that the DHCP Agent and the Quantum
service don't have to be co-located on the same machine and added some
logic in oVirt where and when to deploy the DHCP Agent.

The DHCP Agent will get notification on each network created in Quantum
but when delegating the call to the layer 2 (oVirt) driver we'll create
devices only for the networks we'd like to control from that DHCP
instance. In case we won't create a device we would like the DHCP Agent
to avoid spawning a dnsmasq (which is the code we'll contribute to Quantum).

>> This requires a patch to Quantum that in case the driver returns empty
>> device name the dnsmasq won't be started.
> 
> I am not sure that I understand. The DHCP agent has to create a device
> to interface with the outside world. If the device fails to be created
> then the dnsmasq process will not be spawned.
>
If the device fails to to be created and an exception is raised then the
dnsmasq is not created  (there is a retry in a loop via the error
handling in the notification layer), but we suggest that if the device
returns an empty device name the DHCP Agent won't spawn a dnsmasq
process as it would have no meaning.
We'll use the above behavior in oVirt driver to control which dnsmask is
spawned on the server the DHCP Agent is deployed on.

>> We'll send a patch for that soon.
>> I added that to the wiki as well.
>>
>>>>> viii. Quantum does not require homogeneous  hardware. This is
>>>>> incorrect.
>>>>> There is something called a provider network that addresses this.
>>>> Can you please elaborate?
>>> When you create a network you can indicate which NIC connects to the
>>> outside world. If you look at
>>> http://wiki.openstack.org/ConfigureOpenvswitch then you will see the
>>> bridge mappings. This information is passed via the API.
>> Our understanding is that Quantum IPAM design assumes the DHCP Agent has
>> local access to *ALL* the networks created in quantum.
> 
> IPAM is part of the Quantum API. That is, Quantum provides and interface
> for logical ports to be assigned an IP address. The DHCP agent is one
> way of implementing this. The DHCP agent interfaces with the Quantum
> plugin to receive the information that it requires. Currently tyhe DHCP
> agent is able to get information for all networks.
> 
>> Per Network it spawns a local dnsmasq and connect it to the network
>> (which should be accessible from within the host on which the DHCP Agent
>> is running on).
> 
> The dnsmasq is able to be accessed from all compute nodes on the
> network. From what you are mentioning here is that you guys will be
> taking a hybrid approach to using Quantum. Correct?
> 

I did not understand the question, not sure what you mean by hybrid
approach?

>>
>> This assumption is problematic in the oVirt context and this is the
>> issue we were trying to overcome in the proposed integration.
> 
> I am sorry but I am not sure that I understand the issue that you are
> trying to overcome.

It's the same issues you raised above, scalability and the assumption
that there is one hast that has to have connectivity to all the networks
configured in the system.

> In theory more than one DHCP server can run. This is
> how people provide HA. One of the servers will answer. Do you plan to
> have a DHCP agent running on each vdsm node? Nova networking has support
> for a feature like this. It is called multinode. It is something that is
> under discussion in Quantum.

The issue is not related to the DHCP Agent HA.

>>
>>>>> ix. I do not udnerstand the race when the VM starts. There is none.
>>>>> When
>>>>> a VM starts it will send a DHCP request. If it does not receive one
>>>>> it
>>>>> will send another after a timeout. Can you please explain the race?
>>>> This is exactly it, the VM might start requesting DHCP lease before it
>>>> was updated in the DHCP server, for us it's a race.
>>> This works. This is how DHCP is engineered. Can you please explain the
>>> problem? If you send a DHCP request and do not get a reply then you send
>>> one again. The timeout between requests is incremental.
>>>
>>> I am not sure that we are on the same page when it comes to a race
>>> condition. I'd like you to clarify.
>>>>> You do not need to consume Quantum to provide IPAM. You can just run
>>>>> the
>>>>> dnsmasq and make sure that its interface is connected to the virtual
>>>>> network. This will provide you with the functionality that you are
>>>>> looking for. If you want I go can over the dirty details. It will be
>>>>> far
>>>>> less time than consuming Quantum and you can achieve the same goal.
>>>>> You
>>>>> just need to be aware when the dnsmasq is running to sent the
>>>>> updates.
>>>>>
>>>>> IPAM is one of the many features that Quantum has to offer. It will
>>>>> certain
>>>>> help oVirt.
>>>>>
>>>>> Thanks
>>>>> Gary
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
> 



From gkotton at redhat.com  Wed Nov 28 14:22:57 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Wed, 28 Nov 2012 16:22:57 +0200
Subject: ovirt-quantum integration
In-Reply-To: <50B615CC.1060609@redhat.com>
References: <1034808037.17794745.1354025174695.JavaMail.root@redhat.com>
	<50B4CF83.1050907@redhat.com> <50B5F6BF.10904@redhat.com>
	<50B5FCF3.4030301@redhat.com> <50B615CC.1060609@redhat.com>
Message-ID: <50B61E41.7030200@redhat.com>

On 11/28/2012 03:46 PM, Livnat Peer wrote:
> On 28/11/12 14:00, Gary Kotton wrote:
>> On 11/28/2012 01:34 PM, Livnat Peer wrote:
>>> On 27/11/12 16:34, Gary Kotton wrote:
>>>> On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
>>>>> Thanks for the reply,
>>>>> Please see comments inline
>>>>>
>>> Hi Garry,
>>> Thanks for your input, see my comments inline.
>>>
>>> Livnat
>>>
>>>>> ----- Original Message -----
>>>>>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
>>>>>>> Hi All,
>>>>>>> Mike Kolesnik and me have been working on a proposal for
>>>>>>> integrating
>>>>>>> quantum into oVirt in the past few weeks.
>>>>>>> We decided to focus our efforts on integrating with quantum
>>>>>>> services, we
>>>>>>> started with IP address management service.
>>>>>>>
>>>>>>> here is a link to our proposal:
>>>>>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>>>>>>
>>>>>>> As usual comments are welcome,
>>>>>> Please see my comments below:
>>>>>>
>>>>>> i. The quantum diagram is incorrect. It is the same message queue
>>>>>> that
>>>>>> passes the notifications. This is done by a message broker. In RH we
>>>>>> are
>>>>>> supporting qpid and in the community upstream rabbitmq is used.
>>>>> I will fix the diagram accordingly
>>>> Thanks
>>>>>> ii. The DHCP agent is plugable. That is there may be more than one
>>>>>> implementation. At the moment only dnsmasq is support. There was a
>>>>>> company working on ISC upstream but they have stopped due to problem
>>>>>> they encountered.
>>>>>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does the
>>>>>> network connectivity. The layer 3 agent provides floating IP support.
>>>>>> This is something that you may want to consider to. It is related to
>>>>>> IPAM
>>>    From what we gathered from code the DHCP Agent is communicating with (an
>>> implementation of the) LinuxInterfaceDriver, which is not the same as
>>> the layer 2 agent used in the plugin.
>> Correct. The DHCP agent needs to create the relevant interfaces. The
>> layer 2 is responsible for attaching these interfaces to the network.
>>
>>> For example, looking in Linux bridge, the plugin has
>>> Linux_bridge_quantum agent that is part of the Linux bridge plugin, and
>>> it has (what we called Layer 3 driver) a BridgeInterfaceDriver that is
>>> used within the DHCP Agent.
>>>
>>> Maybe we used a misleading terminology but 'layer 2 agent' is also
>>> misleading, IMO, as it is already used in the plugin context and this is
>>> not the same component.
>>>
>>> We'll update the doc to call it 'layer 2 driver'.
>>>
>>>>>> iv. I am not really sure I understand you picture with server B and
>>>>>> get/create network. This is not really what happens. If you want I
>>>>>> can
>>>>>> explain.
>>>>> We saw that the DHCP Agent is trying to create the network interface
>>>>> if it doesn't exist (in DeviceManager.setup which is called as part of
>>>>> "enable_dhcp_helper").
>>>>>
>>>>> If you want to elaborate on this, please do.
>>>> The DHCP agent will create a device that is used by the dnsmasq process.
>>>> The creation is done according to a driver that is used for the
>>>> underlying l2 implementation. It does not have anything to do the the
>>>> layer 3 agent.
>>> Again the same terminology misunderstanding.
>>>
>>>> It creates a network device and assigns it an IP address.
>>>> The layer 2 agent (if there is one) will attach this device to the
>>>> underlying virtual network.
>>> It seems to be our understanding and what we have described in the wiki
>>> page, do you see something wrong there?
>>>
>>>> Prior to doing anything the DHCP agent will create a quantum port on the
>>>> subnet. This is how it receives its own IP address.
>>>>
>>>>>> v. What do you mean by the "port is then part of the Quantum DB". Not
>>>>>> all plugins maintain a database.
>>>>> True but if it's not saved somewhere then how does the Agent know
>>>>> which IP to assign to which MAC?
>>>> The DHCP agent is notified by the Quantum service of a new port
>>>> allocation. It is passed the port details - the mac address and the IP
>>>> address. The plugin may not use a database that one can access. All of
>>>> the interface to the data is done via the Quantum API. For example
>>>> the NVP.
>>>>
>>>>>> vi. I think that you are missing useful information about the subnets
>>>>>> and gateways. This is also a critical part of the IPAM. When a VM
>>>>>> sends
>>>>>> a DHCP request it not only gets and IP but it can also receive host
>>>>>> route information. This is very important.
>>>>> can you please elaborate on this?
>>>> When you reboot your computer at work you get access to the internet.
>>>> This is done via DHCP. You get an IP address and all of the relevant
>>>> routes configured. The port data has the 'host_routes' which is also
>>>> used by the dnsmasq. There can be more than one route which is
>>>> configured. The subnet contains the gateway IP.
>>>>
>>> We assumed that when creating the subnet in Quantum it would update the
>>> DHCP Agent with all the information oVirt will provide as part of the
>>> subnet details (dns_nameservers, host_routes, gateway_ip  etc).
>>> Isn't this the case?
>> Yes it is. I was misleading as the wiki only referred to Quantum ports
>> and not subnets. If I understand correctly then you will be using the
>> entire Quantum service? Will this include floating IP's security groups
>> etc.?
> I did not review security group and floating IP provided by quantum. Can
> you please point us to a documentation on these?

Security groups is in development - 
https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups
Floating IP's - 
http://docs.openstack.org/trunk/openstack-network/admin/content/index.html
>
>
>>>>>> vii. The DHCP agent dynamics are incorrect (l3 agent, write port
>>>>>> definitions etc.). One of the pain points is that the process is for
>>>>>> each quantum network. This is a scale issue and is being discussed
>>>>>> upstream.
>>>>> This is what we saw that happens in the code, if we are wrong please
>>>>> explain what is the right behaviour of the DHCP Agent.
>>>> For each network that has one or more subnets with DHCP support a
>>>> dnsmasq process is created. Please see http://fpaste.org/IHbA/. Here I
>>>> have two networks.
>>> That's exactly what we have described in the wiki. dnsmasq per network.
>>> In the integration with oVirt we planned that the ovirt layer2 driver
>>> will not return interface_name where there is no need for the dnsmasq
>>> locally on the host.
>> I do not think that this will work - you will need to attach the dnsmasq
>> to the network. At the moment Quantum does not run the dnsmasq on the
>> compute nodes. There is a notion of a network node when various services
>> can run. One of the issues that we are dealing with at the moment is HA
>> and scale for the DHCP agents. At the moment only one DHCP agent can
>> run. The open issue is that if the DHCP agent sees thousands of networks
>> then it will create dnsmasq process for each network killing the node
>> local resources.
>>
> That's exactly the problems we addressed in our proposal.
> In the integration proposal we'll deploy the DHCP-Agent on the hosts
> (where and when is defined via the the setupDHCP API we added to oVirt),
> and we'll have more than one DHCP Agent...each DHCP Agent will manage
> the networks available on the host it is deployed on.

At the moment Quantum only works with 1 DCHP agent. Upstream there is 
work on improving this.
> The wiki page describes how we intend to do it.
> We actually leverage the fact that the DHCP Agent and the Quantum
> service don't have to be co-located on the same machine and added some
> logic in oVirt where and when to deploy the DHCP Agent.
>
> The DHCP Agent will get notification on each network created in Quantum
> but when delegating the call to the layer 2 (oVirt) driver we'll create
> devices only for the networks we'd like to control from that DHCP
> instance.

Not sure what the layer 2 oVirt driver is? Does this mean that you will 
not be using Quantum L2 agents? If so then this may not work. First I 
need a clarification then I can explain.

>   In case we won't create a device we would like the DHCP Agent
> to avoid spawning a dnsmasq (which is the code we'll contribute to Quantum).

The DHCP agent creates the device. I do not understand how you will 
decide whether or not to create the device. One thing that you should 
take into account is HA for the solution. Lets say your DHCP agent on 
the node freezes - how will launched VM's get their IP addresses?
>
>>> This requires a patch to Quantum that in case the driver returns empty
>>> device name the dnsmasq won't be started.
>> I am not sure that I understand. The DHCP agent has to create a device
>> to interface with the outside world. If the device fails to be created
>> then the dnsmasq process will not be spawned.
>>
> If the device fails to to be created and an exception is raised then the
> dnsmasq is not created  (there is a retry in a loop via the error
> handling in the notification layer), but we suggest that if the device
> returns an empty device name the DHCP Agent won't spawn a dnsmasq
> process as it would have no meaning.

ok. I am not sure how this will be accepted upstream as the DHCP agent 
is requesting to create the interface. The logic seems a tad odd.
As mentioned above there is work upstream on this at the moment - there 
are a number of options that are in debate - one is to have scheduler 
that decides where to run the agents. Another is to indicate the the 
DHCP agent which networks to treat - that is, if it receives a network 
notifiction for a network that it does not "own" then it will ignore this.

> We'll use the above behavior in oVirt driver to control which dnsmask is
> spawned on the server the DHCP Agent is deployed on.
>
>>> We'll send a patch for that soon.
>>> I added that to the wiki as well.
>>>
>>>>>> viii. Quantum does not require homogeneous  hardware. This is
>>>>>> incorrect.
>>>>>> There is something called a provider network that addresses this.
>>>>> Can you please elaborate?
>>>> When you create a network you can indicate which NIC connects to the
>>>> outside world. If you look at
>>>> http://wiki.openstack.org/ConfigureOpenvswitch then you will see the
>>>> bridge mappings. This information is passed via the API.
>>> Our understanding is that Quantum IPAM design assumes the DHCP Agent has
>>> local access to *ALL* the networks created in quantum.
>> IPAM is part of the Quantum API. That is, Quantum provides and interface
>> for logical ports to be assigned an IP address. The DHCP agent is one
>> way of implementing this. The DHCP agent interfaces with the Quantum
>> plugin to receive the information that it requires. Currently tyhe DHCP
>> agent is able to get information for all networks.
>>
>>> Per Network it spawns a local dnsmasq and connect it to the network
>>> (which should be accessible from within the host on which the DHCP Agent
>>> is running on).
>> The dnsmasq is able to be accessed from all compute nodes on the
>> network. From what you are mentioning here is that you guys will be
>> taking a hybrid approach to using Quantum. Correct?
>>
> I did not understand the question, not sure what you mean by hybrid
> approach?

 From what you have written I understand, and may be completely wrong 
here, that you only want to use certain parts of quantum in certain ways 
which are not supported today. So the hybrid is taking parts of Quantum 
and using them in VDSM but not via the standard API's.
>
>>> This assumption is problematic in the oVirt context and this is the
>>> issue we were trying to overcome in the proposed integration.
>> I am sorry but I am not sure that I understand the issue that you are
>> trying to overcome.
> It's the same issues you raised above, scalability and the assumption
> that there is one hast that has to have connectivity to all the networks
> configured in the system.
>
>> In theory more than one DHCP server can run. This is
>> how people provide HA. One of the servers will answer. Do you plan to
>> have a DHCP agent running on each vdsm node? Nova networking has support
>> for a feature like this. It is called multinode. It is something that is
>> under discussion in Quantum.
> The issue is not related to the DHCP Agent HA.

I am not sure how your solution will address the HA. Say you have 2 
hosts. VM X is running on HOST A. It has a dnsmasq running on HOST A. 
HOST B will not have one as there are no VM's running on B. Say the 
dnsmasq freezes on A. A new VM deployed on A will not receive and IP 
address. If there was a dnsmasq running on B Then it would.

>
>>>>>> ix. I do not udnerstand the race when the VM starts. There is none.
>>>>>> When
>>>>>> a VM starts it will send a DHCP request. If it does not receive one
>>>>>> it
>>>>>> will send another after a timeout. Can you please explain the race?
>>>>> This is exactly it, the VM might start requesting DHCP lease before it
>>>>> was updated in the DHCP server, for us it's a race.
>>>> This works. This is how DHCP is engineered. Can you please explain the
>>>> problem? If you send a DHCP request and do not get a reply then you send
>>>> one again. The timeout between requests is incremental.
>>>>
>>>> I am not sure that we are on the same page when it comes to a race
>>>> condition. I'd like you to clarify.
>>>>>> You do not need to consume Quantum to provide IPAM. You can just run
>>>>>> the
>>>>>> dnsmasq and make sure that its interface is connected to the virtual
>>>>>> network. This will provide you with the functionality that you are
>>>>>> looking for. If you want I go can over the dirty details. It will be
>>>>>> far
>>>>>> less time than consuming Quantum and you can achieve the same goal.
>>>>>> You
>>>>>> just need to be aware when the dnsmasq is running to sent the
>>>>>> updates.
>>>>>>
>>>>>> IPAM is one of the many features that Quantum has to offer. It will
>>>>>> certain
>>>>>> help oVirt.
>>>>>>
>>>>>> Thanks
>>>>>> Gary
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch



From mkolesni at redhat.com  Wed Nov 28 14:33:46 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 28 Nov 2012 09:33:46 -0500 (EST)
Subject: ovirt-quantum integration
In-Reply-To: <50B61E41.7030200@redhat.com>
Message-ID: <1083118704.1087020.1354113226768.JavaMail.root@redhat.com>

----- Original Message -----
> On 11/28/2012 03:46 PM, Livnat Peer wrote:
> > On 28/11/12 14:00, Gary Kotton wrote:
> >> On 11/28/2012 01:34 PM, Livnat Peer wrote:
> >>> On 27/11/12 16:34, Gary Kotton wrote:
> >>>> On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
> >>>>> Thanks for the reply,
> >>>>> Please see comments inline
> >>>>>
> >>> Hi Garry,
> >>> Thanks for your input, see my comments inline.
> >>>
> >>> Livnat
> >>>
> >>>>> ----- Original Message -----
> >>>>>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
> >>>>>>> Hi All,
> >>>>>>> Mike Kolesnik and me have been working on a proposal for
> >>>>>>> integrating
> >>>>>>> quantum into oVirt in the past few weeks.
> >>>>>>> We decided to focus our efforts on integrating with quantum
> >>>>>>> services, we
> >>>>>>> started with IP address management service.
> >>>>>>>
> >>>>>>> here is a link to our proposal:
> >>>>>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
> >>>>>>>
> >>>>>>> As usual comments are welcome,
> >>>>>> Please see my comments below:
> >>>>>>
> >>>>>> i. The quantum diagram is incorrect. It is the same message
> >>>>>> queue
> >>>>>> that
> >>>>>> passes the notifications. This is done by a message broker. In
> >>>>>> RH we
> >>>>>> are
> >>>>>> supporting qpid and in the community upstream rabbitmq is
> >>>>>> used.
> >>>>> I will fix the diagram accordingly
> >>>> Thanks
> >>>>>> ii. The DHCP agent is plugable. That is there may be more than
> >>>>>> one
> >>>>>> implementation. At the moment only dnsmasq is support. There
> >>>>>> was a
> >>>>>> company working on ISC upstream but they have stopped due to
> >>>>>> problem
> >>>>>> they encountered.
> >>>>>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does
> >>>>>> the
> >>>>>> network connectivity. The layer 3 agent provides floating IP
> >>>>>> support.
> >>>>>> This is something that you may want to consider to. It is
> >>>>>> related to
> >>>>>> IPAM
> >>>    From what we gathered from code the DHCP Agent is
> >>>    communicating with (an
> >>> implementation of the) LinuxInterfaceDriver, which is not the
> >>> same as
> >>> the layer 2 agent used in the plugin.
> >> Correct. The DHCP agent needs to create the relevant interfaces.
> >> The
> >> layer 2 is responsible for attaching these interfaces to the
> >> network.
> >>
> >>> For example, looking in Linux bridge, the plugin has
> >>> Linux_bridge_quantum agent that is part of the Linux bridge
> >>> plugin, and
> >>> it has (what we called Layer 3 driver) a BridgeInterfaceDriver
> >>> that is
> >>> used within the DHCP Agent.
> >>>
> >>> Maybe we used a misleading terminology but 'layer 2 agent' is
> >>> also
> >>> misleading, IMO, as it is already used in the plugin context and
> >>> this is
> >>> not the same component.
> >>>
> >>> We'll update the doc to call it 'layer 2 driver'.
> >>>
> >>>>>> iv. I am not really sure I understand you picture with server
> >>>>>> B and
> >>>>>> get/create network. This is not really what happens. If you
> >>>>>> want I
> >>>>>> can
> >>>>>> explain.
> >>>>> We saw that the DHCP Agent is trying to create the network
> >>>>> interface
> >>>>> if it doesn't exist (in DeviceManager.setup which is called as
> >>>>> part of
> >>>>> "enable_dhcp_helper").
> >>>>>
> >>>>> If you want to elaborate on this, please do.
> >>>> The DHCP agent will create a device that is used by the dnsmasq
> >>>> process.
> >>>> The creation is done according to a driver that is used for the
> >>>> underlying l2 implementation. It does not have anything to do
> >>>> the the
> >>>> layer 3 agent.
> >>> Again the same terminology misunderstanding.
> >>>
> >>>> It creates a network device and assigns it an IP address.
> >>>> The layer 2 agent (if there is one) will attach this device to
> >>>> the
> >>>> underlying virtual network.
> >>> It seems to be our understanding and what we have described in
> >>> the wiki
> >>> page, do you see something wrong there?
> >>>
> >>>> Prior to doing anything the DHCP agent will create a quantum
> >>>> port on the
> >>>> subnet. This is how it receives its own IP address.
> >>>>
> >>>>>> v. What do you mean by the "port is then part of the Quantum
> >>>>>> DB". Not
> >>>>>> all plugins maintain a database.
> >>>>> True but if it's not saved somewhere then how does the Agent
> >>>>> know
> >>>>> which IP to assign to which MAC?
> >>>> The DHCP agent is notified by the Quantum service of a new port
> >>>> allocation. It is passed the port details - the mac address and
> >>>> the IP
> >>>> address. The plugin may not use a database that one can access.
> >>>> All of
> >>>> the interface to the data is done via the Quantum API. For
> >>>> example
> >>>> the NVP.
> >>>>
> >>>>>> vi. I think that you are missing useful information about the
> >>>>>> subnets
> >>>>>> and gateways. This is also a critical part of the IPAM. When a
> >>>>>> VM
> >>>>>> sends
> >>>>>> a DHCP request it not only gets and IP but it can also receive
> >>>>>> host
> >>>>>> route information. This is very important.
> >>>>> can you please elaborate on this?
> >>>> When you reboot your computer at work you get access to the
> >>>> internet.
> >>>> This is done via DHCP. You get an IP address and all of the
> >>>> relevant
> >>>> routes configured. The port data has the 'host_routes' which is
> >>>> also
> >>>> used by the dnsmasq. There can be more than one route which is
> >>>> configured. The subnet contains the gateway IP.
> >>>>
> >>> We assumed that when creating the subnet in Quantum it would
> >>> update the
> >>> DHCP Agent with all the information oVirt will provide as part of
> >>> the
> >>> subnet details (dns_nameservers, host_routes, gateway_ip  etc).
> >>> Isn't this the case?
> >> Yes it is. I was misleading as the wiki only referred to Quantum
> >> ports
> >> and not subnets. If I understand correctly then you will be using
> >> the
> >> entire Quantum service? Will this include floating IP's security
> >> groups
> >> etc.?
> > I did not review security group and floating IP provided by
> > quantum. Can
> > you please point us to a documentation on these?
> 
> Security groups is in development -
> https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups
> Floating IP's -
> http://docs.openstack.org/trunk/openstack-network/admin/content/index.html
> >
> >
> >>>>>> vii. The DHCP agent dynamics are incorrect (l3 agent, write
> >>>>>> port
> >>>>>> definitions etc.). One of the pain points is that the process
> >>>>>> is for
> >>>>>> each quantum network. This is a scale issue and is being
> >>>>>> discussed
> >>>>>> upstream.
> >>>>> This is what we saw that happens in the code, if we are wrong
> >>>>> please
> >>>>> explain what is the right behaviour of the DHCP Agent.
> >>>> For each network that has one or more subnets with DHCP support
> >>>> a
> >>>> dnsmasq process is created. Please see http://fpaste.org/IHbA/.
> >>>> Here I
> >>>> have two networks.
> >>> That's exactly what we have described in the wiki. dnsmasq per
> >>> network.
> >>> In the integration with oVirt we planned that the ovirt layer2
> >>> driver
> >>> will not return interface_name where there is no need for the
> >>> dnsmasq
> >>> locally on the host.
> >> I do not think that this will work - you will need to attach the
> >> dnsmasq
> >> to the network. At the moment Quantum does not run the dnsmasq on
> >> the
> >> compute nodes. There is a notion of a network node when various
> >> services
> >> can run. One of the issues that we are dealing with at the moment
> >> is HA
> >> and scale for the DHCP agents. At the moment only one DHCP agent
> >> can
> >> run. The open issue is that if the DHCP agent sees thousands of
> >> networks
> >> then it will create dnsmasq process for each network killing the
> >> node
> >> local resources.
> >>
> > That's exactly the problems we addressed in our proposal.
> > In the integration proposal we'll deploy the DHCP-Agent on the
> > hosts
> > (where and when is defined via the the setupDHCP API we added to
> > oVirt),
> > and we'll have more than one DHCP Agent...each DHCP Agent will
> > manage
> > the networks available on the host it is deployed on.
> 
> At the moment Quantum only works with 1 DCHP agent. Upstream there is
> work on improving this.

So if I run Quantum Service and 2 instances of the DHCP Agent on different machines, this is not supported? (And it it's not can you please elaborate what is the problem?)

> > The wiki page describes how we intend to do it.
> > We actually leverage the fact that the DHCP Agent and the Quantum
> > service don't have to be co-located on the same machine and added
> > some
> > logic in oVirt where and when to deploy the DHCP Agent.
> >
> > The DHCP Agent will get notification on each network created in
> > Quantum
> > but when delegating the call to the layer 2 (oVirt) driver we'll
> > create
> > devices only for the networks we'd like to control from that DHCP
> > instance.
> 
> Not sure what the layer 2 oVirt driver is? Does this mean that you
> will
> not be using Quantum L2 agents? If so then this may not work. First I
> need a clarification then I can explain.
> 
> >   In case we won't create a device we would like the DHCP Agent
> > to avoid spawning a dnsmasq (which is the code we'll contribute to
> > Quantum).
> 
> The DHCP agent creates the device. I do not understand how you will
> decide whether or not to create the device. One thing that you should
> take into account is HA for the solution. Lets say your DHCP agent on
> the node freezes - how will launched VM's get their IP addresses?
> >
> >>> This requires a patch to Quantum that in case the driver returns
> >>> empty
> >>> device name the dnsmasq won't be started.
> >> I am not sure that I understand. The DHCP agent has to create a
> >> device
> >> to interface with the outside world. If the device fails to be
> >> created
> >> then the dnsmasq process will not be spawned.
> >>
> > If the device fails to to be created and an exception is raised
> > then the
> > dnsmasq is not created  (there is a retry in a loop via the error
> > handling in the notification layer), but we suggest that if the
> > device
> > returns an empty device name the DHCP Agent won't spawn a dnsmasq
> > process as it would have no meaning.
> 
> ok. I am not sure how this will be accepted upstream as the DHCP
> agent
> is requesting to create the interface. The logic seems a tad odd.
> As mentioned above there is work upstream on this at the moment -
> there
> are a number of options that are in debate - one is to have scheduler
> that decides where to run the agents. Another is to indicate the the
> DHCP agent which networks to treat - that is, if it receives a
> network
> notifiction for a network that it does not "own" then it will ignore
> this.

Yes this is essentially our proposal..

> 
> > We'll use the above behavior in oVirt driver to control which
> > dnsmask is
> > spawned on the server the DHCP Agent is deployed on.
> >
> >>> We'll send a patch for that soon.
> >>> I added that to the wiki as well.
> >>>
> >>>>>> viii. Quantum does not require homogeneous  hardware. This is
> >>>>>> incorrect.
> >>>>>> There is something called a provider network that addresses
> >>>>>> this.
> >>>>> Can you please elaborate?
> >>>> When you create a network you can indicate which NIC connects to
> >>>> the
> >>>> outside world. If you look at
> >>>> http://wiki.openstack.org/ConfigureOpenvswitch then you will see
> >>>> the
> >>>> bridge mappings. This information is passed via the API.
> >>> Our understanding is that Quantum IPAM design assumes the DHCP
> >>> Agent has
> >>> local access to *ALL* the networks created in quantum.
> >> IPAM is part of the Quantum API. That is, Quantum provides and
> >> interface
> >> for logical ports to be assigned an IP address. The DHCP agent is
> >> one
> >> way of implementing this. The DHCP agent interfaces with the
> >> Quantum
> >> plugin to receive the information that it requires. Currently tyhe
> >> DHCP
> >> agent is able to get information for all networks.
> >>
> >>> Per Network it spawns a local dnsmasq and connect it to the
> >>> network
> >>> (which should be accessible from within the host on which the
> >>> DHCP Agent
> >>> is running on).
> >> The dnsmasq is able to be accessed from all compute nodes on the
> >> network. From what you are mentioning here is that you guys will
> >> be
> >> taking a hybrid approach to using Quantum. Correct?
> >>
> > I did not understand the question, not sure what you mean by hybrid
> > approach?
> 
>  From what you have written I understand, and may be completely wrong
> here, that you only want to use certain parts of quantum in certain
> ways
> which are not supported today. So the hybrid is taking parts of
> Quantum
> and using them in VDSM but not via the standard API's.

We are planning to write our own pluggable implementations (which is the purpose of Quantum), but we're not planning to take just parts of Quantum but the whole deal..

> >
> >>> This assumption is problematic in the oVirt context and this is
> >>> the
> >>> issue we were trying to overcome in the proposed integration.
> >> I am sorry but I am not sure that I understand the issue that you
> >> are
> >> trying to overcome.
> > It's the same issues you raised above, scalability and the
> > assumption
> > that there is one hast that has to have connectivity to all the
> > networks
> > configured in the system.
> >
> >> In theory more than one DHCP server can run. This is
> >> how people provide HA. One of the servers will answer. Do you plan
> >> to
> >> have a DHCP agent running on each vdsm node? Nova networking has
> >> support
> >> for a feature like this. It is called multinode. It is something
> >> that is
> >> under discussion in Quantum.
> > The issue is not related to the DHCP Agent HA.
> 
> I am not sure how your solution will address the HA. Say you have 2
> hosts. VM X is running on HOST A. It has a dnsmasq running on HOST A.
> HOST B will not have one as there are no VM's running on B. Say the
> dnsmasq freezes on A. A new VM deployed on A will not receive and IP
> address. If there was a dnsmasq running on B Then it would.

We are planning on having several DHCP servers for each network, so this will not be a problem.

> 
> >
> >>>>>> ix. I do not udnerstand the race when the VM starts. There is
> >>>>>> none.
> >>>>>> When
> >>>>>> a VM starts it will send a DHCP request. If it does not
> >>>>>> receive one
> >>>>>> it
> >>>>>> will send another after a timeout. Can you please explain the
> >>>>>> race?
> >>>>> This is exactly it, the VM might start requesting DHCP lease
> >>>>> before it
> >>>>> was updated in the DHCP server, for us it's a race.
> >>>> This works. This is how DHCP is engineered. Can you please
> >>>> explain the
> >>>> problem? If you send a DHCP request and do not get a reply then
> >>>> you send
> >>>> one again. The timeout between requests is incremental.
> >>>>
> >>>> I am not sure that we are on the same page when it comes to a
> >>>> race
> >>>> condition. I'd like you to clarify.
> >>>>>> You do not need to consume Quantum to provide IPAM. You can
> >>>>>> just run
> >>>>>> the
> >>>>>> dnsmasq and make sure that its interface is connected to the
> >>>>>> virtual
> >>>>>> network. This will provide you with the functionality that you
> >>>>>> are
> >>>>>> looking for. If you want I go can over the dirty details. It
> >>>>>> will be
> >>>>>> far
> >>>>>> less time than consuming Quantum and you can achieve the same
> >>>>>> goal.
> >>>>>> You
> >>>>>> just need to be aware when the dnsmasq is running to sent the
> >>>>>> updates.
> >>>>>>
> >>>>>> IPAM is one of the many features that Quantum has to offer. It
> >>>>>> will
> >>>>>> certain
> >>>>>> help oVirt.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Gary


From gkotton at redhat.com  Wed Nov 28 14:48:22 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Wed, 28 Nov 2012 16:48:22 +0200
Subject: ovirt-quantum integration
In-Reply-To: <1083118704.1087020.1354113226768.JavaMail.root@redhat.com>
References: <1083118704.1087020.1354113226768.JavaMail.root@redhat.com>
Message-ID: <50B62436.6020009@redhat.com>

On 11/28/2012 04:33 PM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 11/28/2012 03:46 PM, Livnat Peer wrote:
>>> On 28/11/12 14:00, Gary Kotton wrote:
>>>> On 11/28/2012 01:34 PM, Livnat Peer wrote:
>>>>> On 27/11/12 16:34, Gary Kotton wrote:
>>>>>> On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
>>>>>>> Thanks for the reply,
>>>>>>> Please see comments inline
>>>>>>>
>>>>> Hi Garry,
>>>>> Thanks for your input, see my comments inline.
>>>>>
>>>>> Livnat
>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
>>>>>>>>> Hi All,
>>>>>>>>> Mike Kolesnik and me have been working on a proposal for
>>>>>>>>> integrating
>>>>>>>>> quantum into oVirt in the past few weeks.
>>>>>>>>> We decided to focus our efforts on integrating with quantum
>>>>>>>>> services, we
>>>>>>>>> started with IP address management service.
>>>>>>>>>
>>>>>>>>> here is a link to our proposal:
>>>>>>>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>>>>>>>>
>>>>>>>>> As usual comments are welcome,
>>>>>>>> Please see my comments below:
>>>>>>>>
>>>>>>>> i. The quantum diagram is incorrect. It is the same message
>>>>>>>> queue
>>>>>>>> that
>>>>>>>> passes the notifications. This is done by a message broker. In
>>>>>>>> RH we
>>>>>>>> are
>>>>>>>> supporting qpid and in the community upstream rabbitmq is
>>>>>>>> used.
>>>>>>> I will fix the diagram accordingly
>>>>>> Thanks
>>>>>>>> ii. The DHCP agent is plugable. That is there may be more than
>>>>>>>> one
>>>>>>>> implementation. At the moment only dnsmasq is support. There
>>>>>>>> was a
>>>>>>>> company working on ISC upstream but they have stopped due to
>>>>>>>> problem
>>>>>>>> they encountered.
>>>>>>>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does
>>>>>>>> the
>>>>>>>> network connectivity. The layer 3 agent provides floating IP
>>>>>>>> support.
>>>>>>>> This is something that you may want to consider to. It is
>>>>>>>> related to
>>>>>>>> IPAM
>>>>>      From what we gathered from code the DHCP Agent is
>>>>>     communicating with (an
>>>>> implementation of the) LinuxInterfaceDriver, which is not the
>>>>> same as
>>>>> the layer 2 agent used in the plugin.
>>>> Correct. The DHCP agent needs to create the relevant interfaces.
>>>> The
>>>> layer 2 is responsible for attaching these interfaces to the
>>>> network.
>>>>
>>>>> For example, looking in Linux bridge, the plugin has
>>>>> Linux_bridge_quantum agent that is part of the Linux bridge
>>>>> plugin, and
>>>>> it has (what we called Layer 3 driver) a BridgeInterfaceDriver
>>>>> that is
>>>>> used within the DHCP Agent.
>>>>>
>>>>> Maybe we used a misleading terminology but 'layer 2 agent' is
>>>>> also
>>>>> misleading, IMO, as it is already used in the plugin context and
>>>>> this is
>>>>> not the same component.
>>>>>
>>>>> We'll update the doc to call it 'layer 2 driver'.
>>>>>
>>>>>>>> iv. I am not really sure I understand you picture with server
>>>>>>>> B and
>>>>>>>> get/create network. This is not really what happens. If you
>>>>>>>> want I
>>>>>>>> can
>>>>>>>> explain.
>>>>>>> We saw that the DHCP Agent is trying to create the network
>>>>>>> interface
>>>>>>> if it doesn't exist (in DeviceManager.setup which is called as
>>>>>>> part of
>>>>>>> "enable_dhcp_helper").
>>>>>>>
>>>>>>> If you want to elaborate on this, please do.
>>>>>> The DHCP agent will create a device that is used by the dnsmasq
>>>>>> process.
>>>>>> The creation is done according to a driver that is used for the
>>>>>> underlying l2 implementation. It does not have anything to do
>>>>>> the the
>>>>>> layer 3 agent.
>>>>> Again the same terminology misunderstanding.
>>>>>
>>>>>> It creates a network device and assigns it an IP address.
>>>>>> The layer 2 agent (if there is one) will attach this device to
>>>>>> the
>>>>>> underlying virtual network.
>>>>> It seems to be our understanding and what we have described in
>>>>> the wiki
>>>>> page, do you see something wrong there?
>>>>>
>>>>>> Prior to doing anything the DHCP agent will create a quantum
>>>>>> port on the
>>>>>> subnet. This is how it receives its own IP address.
>>>>>>
>>>>>>>> v. What do you mean by the "port is then part of the Quantum
>>>>>>>> DB". Not
>>>>>>>> all plugins maintain a database.
>>>>>>> True but if it's not saved somewhere then how does the Agent
>>>>>>> know
>>>>>>> which IP to assign to which MAC?
>>>>>> The DHCP agent is notified by the Quantum service of a new port
>>>>>> allocation. It is passed the port details - the mac address and
>>>>>> the IP
>>>>>> address. The plugin may not use a database that one can access.
>>>>>> All of
>>>>>> the interface to the data is done via the Quantum API. For
>>>>>> example
>>>>>> the NVP.
>>>>>>
>>>>>>>> vi. I think that you are missing useful information about the
>>>>>>>> subnets
>>>>>>>> and gateways. This is also a critical part of the IPAM. When a
>>>>>>>> VM
>>>>>>>> sends
>>>>>>>> a DHCP request it not only gets and IP but it can also receive
>>>>>>>> host
>>>>>>>> route information. This is very important.
>>>>>>> can you please elaborate on this?
>>>>>> When you reboot your computer at work you get access to the
>>>>>> internet.
>>>>>> This is done via DHCP. You get an IP address and all of the
>>>>>> relevant
>>>>>> routes configured. The port data has the 'host_routes' which is
>>>>>> also
>>>>>> used by the dnsmasq. There can be more than one route which is
>>>>>> configured. The subnet contains the gateway IP.
>>>>>>
>>>>> We assumed that when creating the subnet in Quantum it would
>>>>> update the
>>>>> DHCP Agent with all the information oVirt will provide as part of
>>>>> the
>>>>> subnet details (dns_nameservers, host_routes, gateway_ip  etc).
>>>>> Isn't this the case?
>>>> Yes it is. I was misleading as the wiki only referred to Quantum
>>>> ports
>>>> and not subnets. If I understand correctly then you will be using
>>>> the
>>>> entire Quantum service? Will this include floating IP's security
>>>> groups
>>>> etc.?
>>> I did not review security group and floating IP provided by
>>> quantum. Can
>>> you please point us to a documentation on these?
>> Security groups is in development -
>> https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups
>> Floating IP's -
>> http://docs.openstack.org/trunk/openstack-network/admin/content/index.html
>>>
>>>>>>>> vii. The DHCP agent dynamics are incorrect (l3 agent, write
>>>>>>>> port
>>>>>>>> definitions etc.). One of the pain points is that the process
>>>>>>>> is for
>>>>>>>> each quantum network. This is a scale issue and is being
>>>>>>>> discussed
>>>>>>>> upstream.
>>>>>>> This is what we saw that happens in the code, if we are wrong
>>>>>>> please
>>>>>>> explain what is the right behaviour of the DHCP Agent.
>>>>>> For each network that has one or more subnets with DHCP support
>>>>>> a
>>>>>> dnsmasq process is created. Please see http://fpaste.org/IHbA/.
>>>>>> Here I
>>>>>> have two networks.
>>>>> That's exactly what we have described in the wiki. dnsmasq per
>>>>> network.
>>>>> In the integration with oVirt we planned that the ovirt layer2
>>>>> driver
>>>>> will not return interface_name where there is no need for the
>>>>> dnsmasq
>>>>> locally on the host.
>>>> I do not think that this will work - you will need to attach the
>>>> dnsmasq
>>>> to the network. At the moment Quantum does not run the dnsmasq on
>>>> the
>>>> compute nodes. There is a notion of a network node when various
>>>> services
>>>> can run. One of the issues that we are dealing with at the moment
>>>> is HA
>>>> and scale for the DHCP agents. At the moment only one DHCP agent
>>>> can
>>>> run. The open issue is that if the DHCP agent sees thousands of
>>>> networks
>>>> then it will create dnsmasq process for each network killing the
>>>> node
>>>> local resources.
>>>>
>>> That's exactly the problems we addressed in our proposal.
>>> In the integration proposal we'll deploy the DHCP-Agent on the
>>> hosts
>>> (where and when is defined via the the setupDHCP API we added to
>>> oVirt),
>>> and we'll have more than one DHCP Agent...each DHCP Agent will
>>> manage
>>> the networks available on the host it is deployed on.
>> At the moment Quantum only works with 1 DCHP agent. Upstream there is
>> work on improving this.
> So if I run Quantum Service and 2 instances of the DHCP Agent on different machines, this is not supported? (And it it's not can you please elaborate what is the problem?)

  There is a bug in the underlying Oslo RPC implementation that sets the topic and queue names to be same value. Hence it will only be sent to one agent and not all.


>
>>> The wiki page describes how we intend to do it.
>>> We actually leverage the fact that the DHCP Agent and the Quantum
>>> service don't have to be co-located on the same machine and added
>>> some
>>> logic in oVirt where and when to deploy the DHCP Agent.
>>>
>>> The DHCP Agent will get notification on each network created in
>>> Quantum
>>> but when delegating the call to the layer 2 (oVirt) driver we'll
>>> create
>>> devices only for the networks we'd like to control from that DHCP
>>> instance.
>> Not sure what the layer 2 oVirt driver is? Does this mean that you
>> will
>> not be using Quantum L2 agents? If so then this may not work. First I
>> need a clarification then I can explain.
>>
>>>    In case we won't create a device we would like the DHCP Agent
>>> to avoid spawning a dnsmasq (which is the code we'll contribute to
>>> Quantum).
>> The DHCP agent creates the device. I do not understand how you will
>> decide whether or not to create the device. One thing that you should
>> take into account is HA for the solution. Lets say your DHCP agent on
>> the node freezes - how will launched VM's get their IP addresses?
>>>>> This requires a patch to Quantum that in case the driver returns
>>>>> empty
>>>>> device name the dnsmasq won't be started.
>>>> I am not sure that I understand. The DHCP agent has to create a
>>>> device
>>>> to interface with the outside world. If the device fails to be
>>>> created
>>>> then the dnsmasq process will not be spawned.
>>>>
>>> If the device fails to to be created and an exception is raised
>>> then the
>>> dnsmasq is not created  (there is a retry in a loop via the error
>>> handling in the notification layer), but we suggest that if the
>>> device
>>> returns an empty device name the DHCP Agent won't spawn a dnsmasq
>>> process as it would have no meaning.
>> ok. I am not sure how this will be accepted upstream as the DHCP
>> agent
>> is requesting to create the interface. The logic seems a tad odd.
>> As mentioned above there is work upstream on this at the moment -
>> there
>> are a number of options that are in debate - one is to have scheduler
>> that decides where to run the agents. Another is to indicate the the
>> DHCP agent which networks to treat - that is, if it receives a
>> network
>> notifiction for a network that it does not "own" then it will ignore
>> this.
> Yes this is essentially our proposal..

ok, this was certainly not clear from the wiki :)

>
>>> We'll use the above behavior in oVirt driver to control which
>>> dnsmask is
>>> spawned on the server the DHCP Agent is deployed on.
>>>
>>>>> We'll send a patch for that soon.
>>>>> I added that to the wiki as well.
>>>>>
>>>>>>>> viii. Quantum does not require homogeneous  hardware. This is
>>>>>>>> incorrect.
>>>>>>>> There is something called a provider network that addresses
>>>>>>>> this.
>>>>>>> Can you please elaborate?
>>>>>> When you create a network you can indicate which NIC connects to
>>>>>> the
>>>>>> outside world. If you look at
>>>>>> http://wiki.openstack.org/ConfigureOpenvswitch then you will see
>>>>>> the
>>>>>> bridge mappings. This information is passed via the API.
>>>>> Our understanding is that Quantum IPAM design assumes the DHCP
>>>>> Agent has
>>>>> local access to *ALL* the networks created in quantum.
>>>> IPAM is part of the Quantum API. That is, Quantum provides and
>>>> interface
>>>> for logical ports to be assigned an IP address. The DHCP agent is
>>>> one
>>>> way of implementing this. The DHCP agent interfaces with the
>>>> Quantum
>>>> plugin to receive the information that it requires. Currently tyhe
>>>> DHCP
>>>> agent is able to get information for all networks.
>>>>
>>>>> Per Network it spawns a local dnsmasq and connect it to the
>>>>> network
>>>>> (which should be accessible from within the host on which the
>>>>> DHCP Agent
>>>>> is running on).
>>>> The dnsmasq is able to be accessed from all compute nodes on the
>>>> network. From what you are mentioning here is that you guys will
>>>> be
>>>> taking a hybrid approach to using Quantum. Correct?
>>>>
>>> I did not understand the question, not sure what you mean by hybrid
>>> approach?
>>    From what you have written I understand, and may be completely wrong
>> here, that you only want to use certain parts of quantum in certain
>> ways
>> which are not supported today. So the hybrid is taking parts of
>> Quantum
>> and using them in VDSM but not via the standard API's.
> We are planning to write our own pluggable implementations (which is the purpose of Quantum), but we're not planning to take just parts of Quantum but the whole deal..

Can you please elaborate more on the plugin that you plan to implement. 
Will this be contributed upstream? If so then I suggest that you guys 
draft blueprints
>
>>>>> This assumption is problematic in the oVirt context and this is
>>>>> the
>>>>> issue we were trying to overcome in the proposed integration.
>>>> I am sorry but I am not sure that I understand the issue that you
>>>> are
>>>> trying to overcome.
>>> It's the same issues you raised above, scalability and the
>>> assumption
>>> that there is one hast that has to have connectivity to all the
>>> networks
>>> configured in the system.
>>>
>>>> In theory more than one DHCP server can run. This is
>>>> how people provide HA. One of the servers will answer. Do you plan
>>>> to
>>>> have a DHCP agent running on each vdsm node? Nova networking has
>>>> support
>>>> for a feature like this. It is called multinode. It is something
>>>> that is
>>>> under discussion in Quantum.
>>> The issue is not related to the DHCP Agent HA.
>> I am not sure how your solution will address the HA. Say you have 2
>> hosts. VM X is running on HOST A. It has a dnsmasq running on HOST A.
>> HOST B will not have one as there are no VM's running on B. Say the
>> dnsmasq freezes on A. A new VM deployed on A will not receive and IP
>> address. If there was a dnsmasq running on B Then it would.
> We are planning on having several DHCP servers for each network, so this will not be a problem.

Great.
>
>>>>>>>> ix. I do not udnerstand the race when the VM starts. There is
>>>>>>>> none.
>>>>>>>> When
>>>>>>>> a VM starts it will send a DHCP request. If it does not
>>>>>>>> receive one
>>>>>>>> it
>>>>>>>> will send another after a timeout. Can you please explain the
>>>>>>>> race?
>>>>>>> This is exactly it, the VM might start requesting DHCP lease
>>>>>>> before it
>>>>>>> was updated in the DHCP server, for us it's a race.
>>>>>> This works. This is how DHCP is engineered. Can you please
>>>>>> explain the
>>>>>> problem? If you send a DHCP request and do not get a reply then
>>>>>> you send
>>>>>> one again. The timeout between requests is incremental.
>>>>>>
>>>>>> I am not sure that we are on the same page when it comes to a
>>>>>> race
>>>>>> condition. I'd like you to clarify.
>>>>>>>> You do not need to consume Quantum to provide IPAM. You can
>>>>>>>> just run
>>>>>>>> the
>>>>>>>> dnsmasq and make sure that its interface is connected to the
>>>>>>>> virtual
>>>>>>>> network. This will provide you with the functionality that you
>>>>>>>> are
>>>>>>>> looking for. If you want I go can over the dirty details. It
>>>>>>>> will be
>>>>>>>> far
>>>>>>>> less time than consuming Quantum and you can achieve the same
>>>>>>>> goal.
>>>>>>>> You
>>>>>>>> just need to be aware when the dnsmasq is running to sent the
>>>>>>>> updates.
>>>>>>>>
>>>>>>>> IPAM is one of the many features that Quantum has to offer. It
>>>>>>>> will
>>>>>>>> certain
>>>>>>>> help oVirt.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Gary



From kwade at redhat.com  Thu Nov 29 06:48:03 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 28 Nov 2012 22:48:03 -0800
Subject: Outage :: wiki and www :: 2100 to 0100 UTC Thu 29 Nov/Fri 30 Nov
Message-ID: <50B70523.3090603@redhat.com>

We are having a four-hour freeze and short outage of the wiki and www
portions of ovirt.org to migrate to OpenShift.

2100 UTC Thu 29 Nov to 0100 UTC Fri 30 Nov

date -d '2100 UTC Thu Nov 29'

We are targeting the DNS switch to happen at 2359 UTC Thu 29 Nov.

This migration includes updating to a new theme for the site. We expect
there to be no downtime for access to content on the website. During the
four-hour window we'll be working to make sure URLs linking in to the
old content forward directly to the new website. The freeze on the wiki
is expected to complete on or before the four-hour mark.

The new theme and information layout have been presented and discussed,
this is just the final portion where we turn the lights on in a new
location, and dim the lights in the old.

Any questions, concerns, ideas, etc. just let us know. We'll do a final
minute reminder via email and IRC when the outage window starts. Status
updates will also by via email and IRC, as arisen.

== Affected services ==

www.ovirt.org
wiki.ovirt.org
ovirt.org/releases
ovirt.org/meetings
ovirt.org/stats

== Future considerations ==

If we had a strict infrastructure change management process, we would
have coordinated better with the rest of the contributor teams to be
sure this work didn't interrupt their workflow.

-- 
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: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121128/c7b1df48/attachment.sig>

From lpeer at redhat.com  Thu Nov 29 12:00:04 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 29 Nov 2012 14:00:04 +0200
Subject: ovirt-quantum integration
In-Reply-To: <50B62436.6020009@redhat.com>
References: <1083118704.1087020.1354113226768.JavaMail.root@redhat.com>
	<50B62436.6020009@redhat.com>
Message-ID: <50B74E44.5000401@redhat.com>

On 28/11/12 16:48, Gary Kotton wrote:
> On 11/28/2012 04:33 PM, Mike Kolesnik wrote:
>> ----- Original Message -----
>>> On 11/28/2012 03:46 PM, Livnat Peer wrote:
>>>> On 28/11/12 14:00, Gary Kotton wrote:
>>>>> On 11/28/2012 01:34 PM, Livnat Peer wrote:
>>>>>> On 27/11/12 16:34, Gary Kotton wrote:
>>>>>>> On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
>>>>>>>> Thanks for the reply,
>>>>>>>> Please see comments inline
>>>>>>>>
>>>>>> Hi Garry,
>>>>>> Thanks for your input, see my comments inline.
>>>>>>
>>>>>> Livnat
>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>> Mike Kolesnik and me have been working on a proposal for
>>>>>>>>>> integrating
>>>>>>>>>> quantum into oVirt in the past few weeks.
>>>>>>>>>> We decided to focus our efforts on integrating with quantum
>>>>>>>>>> services, we
>>>>>>>>>> started with IP address management service.
>>>>>>>>>>
>>>>>>>>>> here is a link to our proposal:
>>>>>>>>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>>>>>>>>>
>>>>>>>>>> As usual comments are welcome,
>>>>>>>>> Please see my comments below:
>>>>>>>>>
>>>>>>>>> i. The quantum diagram is incorrect. It is the same message
>>>>>>>>> queue
>>>>>>>>> that
>>>>>>>>> passes the notifications. This is done by a message broker. In
>>>>>>>>> RH we
>>>>>>>>> are
>>>>>>>>> supporting qpid and in the community upstream rabbitmq is
>>>>>>>>> used.
>>>>>>>> I will fix the diagram accordingly
>>>>>>> Thanks
>>>>>>>>> ii. The DHCP agent is plugable. That is there may be more than
>>>>>>>>> one
>>>>>>>>> implementation. At the moment only dnsmasq is support. There
>>>>>>>>> was a
>>>>>>>>> company working on ISC upstream but they have stopped due to
>>>>>>>>> problem
>>>>>>>>> they encountered.
>>>>>>>>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does
>>>>>>>>> the
>>>>>>>>> network connectivity. The layer 3 agent provides floating IP
>>>>>>>>> support.
>>>>>>>>> This is something that you may want to consider to. It is
>>>>>>>>> related to
>>>>>>>>> IPAM
>>>>>>      From what we gathered from code the DHCP Agent is
>>>>>>     communicating with (an
>>>>>> implementation of the) LinuxInterfaceDriver, which is not the
>>>>>> same as
>>>>>> the layer 2 agent used in the plugin.
>>>>> Correct. The DHCP agent needs to create the relevant interfaces.
>>>>> The
>>>>> layer 2 is responsible for attaching these interfaces to the
>>>>> network.
>>>>>
>>>>>> For example, looking in Linux bridge, the plugin has
>>>>>> Linux_bridge_quantum agent that is part of the Linux bridge
>>>>>> plugin, and
>>>>>> it has (what we called Layer 3 driver) a BridgeInterfaceDriver
>>>>>> that is
>>>>>> used within the DHCP Agent.
>>>>>>
>>>>>> Maybe we used a misleading terminology but 'layer 2 agent' is
>>>>>> also
>>>>>> misleading, IMO, as it is already used in the plugin context and
>>>>>> this is
>>>>>> not the same component.
>>>>>>
>>>>>> We'll update the doc to call it 'layer 2 driver'.
>>>>>>
>>>>>>>>> iv. I am not really sure I understand you picture with server
>>>>>>>>> B and
>>>>>>>>> get/create network. This is not really what happens. If you
>>>>>>>>> want I
>>>>>>>>> can
>>>>>>>>> explain.
>>>>>>>> We saw that the DHCP Agent is trying to create the network
>>>>>>>> interface
>>>>>>>> if it doesn't exist (in DeviceManager.setup which is called as
>>>>>>>> part of
>>>>>>>> "enable_dhcp_helper").
>>>>>>>>
>>>>>>>> If you want to elaborate on this, please do.
>>>>>>> The DHCP agent will create a device that is used by the dnsmasq
>>>>>>> process.
>>>>>>> The creation is done according to a driver that is used for the
>>>>>>> underlying l2 implementation. It does not have anything to do
>>>>>>> the the
>>>>>>> layer 3 agent.
>>>>>> Again the same terminology misunderstanding.
>>>>>>
>>>>>>> It creates a network device and assigns it an IP address.
>>>>>>> The layer 2 agent (if there is one) will attach this device to
>>>>>>> the
>>>>>>> underlying virtual network.
>>>>>> It seems to be our understanding and what we have described in
>>>>>> the wiki
>>>>>> page, do you see something wrong there?
>>>>>>
>>>>>>> Prior to doing anything the DHCP agent will create a quantum
>>>>>>> port on the
>>>>>>> subnet. This is how it receives its own IP address.
>>>>>>>
>>>>>>>>> v. What do you mean by the "port is then part of the Quantum
>>>>>>>>> DB". Not
>>>>>>>>> all plugins maintain a database.
>>>>>>>> True but if it's not saved somewhere then how does the Agent
>>>>>>>> know
>>>>>>>> which IP to assign to which MAC?
>>>>>>> The DHCP agent is notified by the Quantum service of a new port
>>>>>>> allocation. It is passed the port details - the mac address and
>>>>>>> the IP
>>>>>>> address. The plugin may not use a database that one can access.
>>>>>>> All of
>>>>>>> the interface to the data is done via the Quantum API. For
>>>>>>> example
>>>>>>> the NVP.
>>>>>>>
>>>>>>>>> vi. I think that you are missing useful information about the
>>>>>>>>> subnets
>>>>>>>>> and gateways. This is also a critical part of the IPAM. When a
>>>>>>>>> VM
>>>>>>>>> sends
>>>>>>>>> a DHCP request it not only gets and IP but it can also receive
>>>>>>>>> host
>>>>>>>>> route information. This is very important.
>>>>>>>> can you please elaborate on this?
>>>>>>> When you reboot your computer at work you get access to the
>>>>>>> internet.
>>>>>>> This is done via DHCP. You get an IP address and all of the
>>>>>>> relevant
>>>>>>> routes configured. The port data has the 'host_routes' which is
>>>>>>> also
>>>>>>> used by the dnsmasq. There can be more than one route which is
>>>>>>> configured. The subnet contains the gateway IP.
>>>>>>>
>>>>>> We assumed that when creating the subnet in Quantum it would
>>>>>> update the
>>>>>> DHCP Agent with all the information oVirt will provide as part of
>>>>>> the
>>>>>> subnet details (dns_nameservers, host_routes, gateway_ip  etc).
>>>>>> Isn't this the case?
>>>>> Yes it is. I was misleading as the wiki only referred to Quantum
>>>>> ports
>>>>> and not subnets. If I understand correctly then you will be using
>>>>> the
>>>>> entire Quantum service? Will this include floating IP's security
>>>>> groups
>>>>> etc.?
>>>> I did not review security group and floating IP provided by
>>>> quantum. Can
>>>> you please point us to a documentation on these?
>>> Security groups is in development -
>>> https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups
>>> Floating IP's -
>>> http://docs.openstack.org/trunk/openstack-network/admin/content/index.html
>>>
>>>>
>>>>>>>>> vii. The DHCP agent dynamics are incorrect (l3 agent, write
>>>>>>>>> port
>>>>>>>>> definitions etc.). One of the pain points is that the process
>>>>>>>>> is for
>>>>>>>>> each quantum network. This is a scale issue and is being
>>>>>>>>> discussed
>>>>>>>>> upstream.
>>>>>>>> This is what we saw that happens in the code, if we are wrong
>>>>>>>> please
>>>>>>>> explain what is the right behaviour of the DHCP Agent.
>>>>>>> For each network that has one or more subnets with DHCP support
>>>>>>> a
>>>>>>> dnsmasq process is created. Please see http://fpaste.org/IHbA/.
>>>>>>> Here I
>>>>>>> have two networks.
>>>>>> That's exactly what we have described in the wiki. dnsmasq per
>>>>>> network.
>>>>>> In the integration with oVirt we planned that the ovirt layer2
>>>>>> driver
>>>>>> will not return interface_name where there is no need for the
>>>>>> dnsmasq
>>>>>> locally on the host.
>>>>> I do not think that this will work - you will need to attach the
>>>>> dnsmasq
>>>>> to the network. At the moment Quantum does not run the dnsmasq on
>>>>> the
>>>>> compute nodes. There is a notion of a network node when various
>>>>> services
>>>>> can run. One of the issues that we are dealing with at the moment
>>>>> is HA
>>>>> and scale for the DHCP agents. At the moment only one DHCP agent
>>>>> can
>>>>> run. The open issue is that if the DHCP agent sees thousands of
>>>>> networks
>>>>> then it will create dnsmasq process for each network killing the
>>>>> node
>>>>> local resources.
>>>>>
>>>> That's exactly the problems we addressed in our proposal.
>>>> In the integration proposal we'll deploy the DHCP-Agent on the
>>>> hosts
>>>> (where and when is defined via the the setupDHCP API we added to
>>>> oVirt),
>>>> and we'll have more than one DHCP Agent...each DHCP Agent will
>>>> manage
>>>> the networks available on the host it is deployed on.
>>> At the moment Quantum only works with 1 DCHP agent. Upstream there is
>>> work on improving this.
>> So if I run Quantum Service and 2 instances of the DHCP Agent on
>> different machines, this is not supported? (And it it's not can you
>> please elaborate what is the problem?)
> 
>  There is a bug in the underlying Oslo RPC implementation that sets the
> topic and queue names to be same value. Hence it will only be sent to
> one agent and not all.

yes, and it seems it to also bothers Mark McClain which wrote on the
openstack-dev list -

" There is a bug in the underlying Oslo RPC implementation that sets the
topic and queue names to be same value.  I didn't get a clear
explanation of this problem until today and will have to figure out a
fix to oslo."


either he'll fix it or we can add that to our list of required fixes to
Quantum.


> 
> 
>>
>>>> The wiki page describes how we intend to do it.
>>>> We actually leverage the fact that the DHCP Agent and the Quantum
>>>> service don't have to be co-located on the same machine and added
>>>> some
>>>> logic in oVirt where and when to deploy the DHCP Agent.
>>>>
>>>> The DHCP Agent will get notification on each network created in
>>>> Quantum
>>>> but when delegating the call to the layer 2 (oVirt) driver we'll
>>>> create
>>>> devices only for the networks we'd like to control from that DHCP
>>>> instance.
>>> Not sure what the layer 2 oVirt driver is? Does this mean that you
>>> will
>>> not be using Quantum L2 agents? If so then this may not work. First I
>>> need a clarification then I can explain.
>>>
>>>>    In case we won't create a device we would like the DHCP Agent
>>>> to avoid spawning a dnsmasq (which is the code we'll contribute to
>>>> Quantum).
>>> The DHCP agent creates the device. I do not understand how you will
>>> decide whether or not to create the device. One thing that you should
>>> take into account is HA for the solution. Lets say your DHCP agent on
>>> the node freezes - how will launched VM's get their IP addresses?
>>>>>> This requires a patch to Quantum that in case the driver returns
>>>>>> empty
>>>>>> device name the dnsmasq won't be started.
>>>>> I am not sure that I understand. The DHCP agent has to create a
>>>>> device
>>>>> to interface with the outside world. If the device fails to be
>>>>> created
>>>>> then the dnsmasq process will not be spawned.
>>>>>
>>>> If the device fails to to be created and an exception is raised
>>>> then the
>>>> dnsmasq is not created  (there is a retry in a loop via the error
>>>> handling in the notification layer), but we suggest that if the
>>>> device
>>>> returns an empty device name the DHCP Agent won't spawn a dnsmasq
>>>> process as it would have no meaning.
>>> ok. I am not sure how this will be accepted upstream as the DHCP
>>> agent
>>> is requesting to create the interface. The logic seems a tad odd.
>>> As mentioned above there is work upstream on this at the moment -
>>> there
>>> are a number of options that are in debate - one is to have scheduler
>>> that decides where to run the agents. Another is to indicate the the
>>> DHCP agent which networks to treat - that is, if it receives a
>>> network
>>> notifiction for a network that it does not "own" then it will ignore
>>> this.
>> Yes this is essentially our proposal..
> 
> ok, this was certainly not clear from the wiki :)
> 
>>
>>>> We'll use the above behavior in oVirt driver to control which
>>>> dnsmask is
>>>> spawned on the server the DHCP Agent is deployed on.
>>>>
>>>>>> We'll send a patch for that soon.
>>>>>> I added that to the wiki as well.
>>>>>>
>>>>>>>>> viii. Quantum does not require homogeneous  hardware. This is
>>>>>>>>> incorrect.
>>>>>>>>> There is something called a provider network that addresses
>>>>>>>>> this.
>>>>>>>> Can you please elaborate?
>>>>>>> When you create a network you can indicate which NIC connects to
>>>>>>> the
>>>>>>> outside world. If you look at
>>>>>>> http://wiki.openstack.org/ConfigureOpenvswitch then you will see
>>>>>>> the
>>>>>>> bridge mappings. This information is passed via the API.
>>>>>> Our understanding is that Quantum IPAM design assumes the DHCP
>>>>>> Agent has
>>>>>> local access to *ALL* the networks created in quantum.
>>>>> IPAM is part of the Quantum API. That is, Quantum provides and
>>>>> interface
>>>>> for logical ports to be assigned an IP address. The DHCP agent is
>>>>> one
>>>>> way of implementing this. The DHCP agent interfaces with the
>>>>> Quantum
>>>>> plugin to receive the information that it requires. Currently tyhe
>>>>> DHCP
>>>>> agent is able to get information for all networks.
>>>>>
>>>>>> Per Network it spawns a local dnsmasq and connect it to the
>>>>>> network
>>>>>> (which should be accessible from within the host on which the
>>>>>> DHCP Agent
>>>>>> is running on).
>>>>> The dnsmasq is able to be accessed from all compute nodes on the
>>>>> network. From what you are mentioning here is that you guys will
>>>>> be
>>>>> taking a hybrid approach to using Quantum. Correct?
>>>>>
>>>> I did not understand the question, not sure what you mean by hybrid
>>>> approach?
>>>    From what you have written I understand, and may be completely wrong
>>> here, that you only want to use certain parts of quantum in certain
>>> ways
>>> which are not supported today. So the hybrid is taking parts of
>>> Quantum
>>> and using them in VDSM but not via the standard API's.
>> We are planning to write our own pluggable implementations (which is
>> the purpose of Quantum), but we're not planning to take just parts of
>> Quantum but the whole deal..
> 
> Can you please elaborate more on the plugin that you plan to implement.
> Will this be contributed upstream? If so then I suggest that you guys
> draft blueprints

The plugin would obviously be open source and we are working on the
details ATM.
I don't see a reason we won't contribute the code to quantum - The code
is open anyway.

>>
>>>>>> This assumption is problematic in the oVirt context and this is
>>>>>> the
>>>>>> issue we were trying to overcome in the proposed integration.
>>>>> I am sorry but I am not sure that I understand the issue that you
>>>>> are
>>>>> trying to overcome.
>>>> It's the same issues you raised above, scalability and the
>>>> assumption
>>>> that there is one hast that has to have connectivity to all the
>>>> networks
>>>> configured in the system.
>>>>
>>>>> In theory more than one DHCP server can run. This is
>>>>> how people provide HA. One of the servers will answer. Do you plan
>>>>> to
>>>>> have a DHCP agent running on each vdsm node? Nova networking has
>>>>> support
>>>>> for a feature like this. It is called multinode. It is something
>>>>> that is
>>>>> under discussion in Quantum.
>>>> The issue is not related to the DHCP Agent HA.
>>> I am not sure how your solution will address the HA. Say you have 2
>>> hosts. VM X is running on HOST A. It has a dnsmasq running on HOST A.
>>> HOST B will not have one as there are no VM's running on B. Say the
>>> dnsmasq freezes on A. A new VM deployed on A will not receive and IP
>>> address. If there was a dnsmasq running on B Then it would.
>> We are planning on having several DHCP servers for each network, so
>> this will not be a problem.
> 
> Great.
>>
>>>>>>>>> ix. I do not udnerstand the race when the VM starts. There is
>>>>>>>>> none.
>>>>>>>>> When
>>>>>>>>> a VM starts it will send a DHCP request. If it does not
>>>>>>>>> receive one
>>>>>>>>> it
>>>>>>>>> will send another after a timeout. Can you please explain the
>>>>>>>>> race?
>>>>>>>> This is exactly it, the VM might start requesting DHCP lease
>>>>>>>> before it
>>>>>>>> was updated in the DHCP server, for us it's a race.
>>>>>>> This works. This is how DHCP is engineered. Can you please
>>>>>>> explain the
>>>>>>> problem? If you send a DHCP request and do not get a reply then
>>>>>>> you send
>>>>>>> one again. The timeout between requests is incremental.
>>>>>>>
>>>>>>> I am not sure that we are on the same page when it comes to a
>>>>>>> race
>>>>>>> condition. I'd like you to clarify.
>>>>>>>>> You do not need to consume Quantum to provide IPAM. You can
>>>>>>>>> just run
>>>>>>>>> the
>>>>>>>>> dnsmasq and make sure that its interface is connected to the
>>>>>>>>> virtual
>>>>>>>>> network. This will provide you with the functionality that you
>>>>>>>>> are
>>>>>>>>> looking for. If you want I go can over the dirty details. It
>>>>>>>>> will be
>>>>>>>>> far
>>>>>>>>> less time than consuming Quantum and you can achieve the same
>>>>>>>>> goal.
>>>>>>>>> You
>>>>>>>>> just need to be aware when the dnsmasq is running to sent the
>>>>>>>>> updates.
>>>>>>>>>
>>>>>>>>> IPAM is one of the many features that Quantum has to offer. It
>>>>>>>>> will
>>>>>>>>> certain
>>>>>>>>> help oVirt.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Gary
> 



From iheim at redhat.com  Thu Nov 29 14:08:41 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 29 Nov 2012 09:08:41 -0500
Subject: [RFC] oVirtLive image
In-Reply-To: <50AD4FC0.1010501@redhat.com>
References: <50ACEC85.9040700@redhat.com> <50AD4FC0.1010501@redhat.com>
Message-ID: <50B76C69.2010907@redhat.com>

On 11/21/2012 05:03 PM, Itamar Heim wrote:
> On 11/21/2012 05:00 PM, Moran Goldboim wrote:
>> Hello All,
>>
>> as you may know i have been working for a while on oVirtLive image [1,2].
>>
>> -as a first step I would like to have oVirt to host this sub-project in
>> a repository
>> -the following step have nightly builds on jenkins for different
>> versions/distros etc.
>>
>> i think that can help in terms of project exposure, when people
>> sometimes find deployment and installation as a hard process.
>>
>> [1]http://lists.ovirt.org/pipermail/users/2012-September/003819.html
>> [2]http://wiki.ovirt.org/wiki/OVirt_Live
>
> +1, suggesting ovirt-live as repo name.
> will give a few days for others to reply

don't remember seeing any comments against this. created the repo.
moran, please work with dave to add it to:
http://www.ovirt.org/project/subprojects/

alon - same for otopi/ovirt-host-deploy
shahar - same for samples-portals
vojtech - same for samples-uiplugins


From dneary at redhat.com  Thu Nov 29 15:07:54 2012
From: dneary at redhat.com (Dave Neary)
Date: Thu, 29 Nov 2012 16:07:54 +0100
Subject: [RFC] oVirtLive image
In-Reply-To: <50B76C69.2010907@redhat.com>
References: <50ACEC85.9040700@redhat.com> <50AD4FC0.1010501@redhat.com>
	<50B76C69.2010907@redhat.com>
Message-ID: <50B77A4A.9070004@redhat.com>

Hi Itamar,

On 11/29/2012 03:08 PM, Itamar Heim wrote:
> don't remember seeing any comments against this. created the repo.
> moran, please work with dave to add it to:
> http://www.ovirt.org/project/subprojects/

As you may have seen on infra@ and elsewhere, we are working hard to 
migrate to the new website before the end of the month. I'll touch base 
with Moran, but normally, from this evening we will be migrated to the 
new wiki-based website running on OpenShift, which will mean that anyone 
will be able to edit the "Subprojects" page.

Given how close we are to moving, I do not plan on making any edits in 
the wordpress site from now on.

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


From kwade at redhat.com  Thu Nov 29 21:02:15 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 29 Nov 2012 13:02:15 -0800
Subject: Outage :: wiki and www :: 2100 to 0100 UTC Thu 29 Nov/Fri 30 Nov
In-Reply-To: <50B70523.3090603@redhat.com>
References: <50B70523.3090603@redhat.com>
Message-ID: <50B7CD57.7010809@redhat.com>

This outage is now starting. We'll be freezing the wiki at
wiki.ovirt.org for the duration of the outage window. If you want to
watch, participate, or have urgent questions, we're on #ovirt on
irc.oftc.net.

On 11/28/2012 10:48 PM, Karsten 'quaid' Wade wrote:
> We are having a four-hour freeze and short outage of the wiki and www
> portions of ovirt.org to migrate to OpenShift.
> 
> 2100 UTC Thu 29 Nov to 0100 UTC Fri 30 Nov
> 
> date -d '2100 UTC Thu Nov 29'
> 
> We are targeting the DNS switch to happen at 2359 UTC Thu 29 Nov.
> 
> This migration includes updating to a new theme for the site. We expect
> there to be no downtime for access to content on the website. During the
> four-hour window we'll be working to make sure URLs linking in to the
> old content forward directly to the new website. The freeze on the wiki
> is expected to complete on or before the four-hour mark.
> 
> The new theme and information layout have been presented and discussed,
> this is just the final portion where we turn the lights on in a new
> location, and dim the lights in the old.
> 
> Any questions, concerns, ideas, etc. just let us know. We'll do a final
> minute reminder via email and IRC when the outage window starts. Status
> updates will also by via email and IRC, as arisen.
> 
> == Affected services ==
> 
> www.ovirt.org
> wiki.ovirt.org
> ovirt.org/releases
> ovirt.org/meetings
> ovirt.org/stats
> 
> == Future considerations ==
> 
> If we had a strict infrastructure change management process, we would
> have coordinated better with the rest of the contributor teams to be
> sure this work didn't interrupt their workflow.
> 
> 
> 
> _______________________________________________
> 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: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121129/5766fb74/attachment.sig>

From kwade at redhat.com  Fri Nov 30 07:50:27 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 29 Nov 2012 23:50:27 -0800
Subject: Outage :: wiki and www :: 2100 to 0100 UTC Thu 29 Nov/Fri 30 Nov
In-Reply-To: <50B7CD57.7010809@redhat.com>
References: <50B70523.3090603@redhat.com> <50B7CD57.7010809@redhat.com>
Message-ID: <50B86543.6090506@redhat.com>

This outage is now over.

The wiki is writeable again, redirects of old content to new locations
are working, and you should be able to go about reading, writing,
creating, and collaborating. Enjoy the new look&feel:

http://www.ovirt.org

There are a lot of small components making *.ovirt.org run, it's fairly
certain we've missed something. If you see anything wrong, broken, or
confusing a, you can drop by IRC, email infra at ovirt.org, or file a
ticket here:

http://fedorahosted.org/ovirt

Thanks to everyone for making this migration happen. It's going to be
nice not having to manage the platform for these non-core-technology
components. The Infra team will be able to focus a bit more on the
deeper parts of the oVirt infrastructure of participation.

In particular, thanks to:

* Garrett Lesage lead the effort to improve not only the look&feel of
the ovirt.org website, but to reconsider the user experience. He worked
on making the top-level of the site show what the technology is, what
the project is, and what you can download and do here. He took on the
challenge of making MediaWiki look good for all the user classes -
casual browser through to regular contributor. (And thanks especially
for saving the front page this week when we realized we didn't have the
desired video content and feed widgets available.)

* Dave Neary focused on taking the framework of the new site and
breathing life in to it with content pages, redirects, MediaWiki
extensions, and so forth. He worked on troubleshooting our transfer
details, tracking project details and progress, and generally beating on
parts until he hammered them in to shape.

Thanks also to Jason Brooks, who took advantage of the tradition of IRC
to just get involved in what was happening. Jason helped troubleshoot
and fix some of the transfer details, such as http rewrite rules.

Overall, I've been pleased with the transparency and accessibility of
the process. I hope others feel the same, but regardless of how you
feel, your feedback is very appreciated.

Thanks - Karsten

On 11/29/2012 01:02 PM, Karsten 'quaid' Wade wrote:
> This outage is now starting. We'll be freezing the wiki at
> wiki.ovirt.org for the duration of the outage window. If you want to
> watch, participate, or have urgent questions, we're on #ovirt on
> irc.oftc.net.
> 
> On 11/28/2012 10:48 PM, Karsten 'quaid' Wade wrote:
>> We are having a four-hour freeze and short outage of the wiki and www
>> portions of ovirt.org to migrate to OpenShift.
>>
>> 2100 UTC Thu 29 Nov to 0100 UTC Fri 30 Nov
>>
>> date -d '2100 UTC Thu Nov 29'
>>
>> We are targeting the DNS switch to happen at 2359 UTC Thu 29 Nov.
>>
>> This migration includes updating to a new theme for the site. We expect
>> there to be no downtime for access to content on the website. During the
>> four-hour window we'll be working to make sure URLs linking in to the
>> old content forward directly to the new website. The freeze on the wiki
>> is expected to complete on or before the four-hour mark.
>>
>> The new theme and information layout have been presented and discussed,
>> this is just the final portion where we turn the lights on in a new
>> location, and dim the lights in the old.
>>
>> Any questions, concerns, ideas, etc. just let us know. We'll do a final
>> minute reminder via email and IRC when the outage window starts. Status
>> updates will also by via email and IRC, as arisen.
>>
>> == Affected services ==
>>
>> www.ovirt.org
>> wiki.ovirt.org
>> ovirt.org/releases
>> ovirt.org/meetings
>> ovirt.org/stats
>>
>> == Future considerations ==
>>
>> If we had a strict infrastructure change management process, we would
>> have coordinated better with the rest of the contributor teams to be
>> sure this work didn't interrupt their workflow.
>>
>>
>>
>> _______________________________________________
>> 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
> 


-- 
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: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121129/b4e34013/attachment.sig>

From dneary at redhat.com  Fri Nov 30 13:18:57 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 30 Nov 2012 14:18:57 +0100
Subject: Reminder: FOSDEM Virt Call for Papers coming up soon!
Message-ID: <50B8B241.6090707@redhat.com>

Hi everyone,

This is a gentle reminder the the deadline for the FOSDEM Virtualization 
Call for Content is coming up fast:

  Announcement: 
https://lists.fosdem.org/pipermail/fosdem/2012-November/001660.html
  Web page: http://osvc.v2.cs.unibo.it/index.php/Main_Page

The deadline is on December 16th, in a little over 2 weeks. Getting your 
proposal in early is an excellent way to get the attention of the 
DevRoom organisers (which includes Itamar and myself), and allows us to 
give you feedback on your submission and allow you to improve it. I 
would really appreciate it if oVirt, VDSM and libvirt submissions could 
be submitted *next week* - before Friday 7th of December - to allow for 
feedback and to help you stand out from the crowd which will inevitably 
submit at the last minute.

Thank you all in advance!

Cheers,
Dave.

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


From iheim at redhat.com  Fri Nov 30 06:18:34 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 30 Nov 2012 01:18:34 -0500
Subject: integrating with quantum - proposal
In-Reply-To: <50B37781.3030508@redhat.com>
References: <50B37781.3030508@redhat.com>
Message-ID: <50B84FBA.6050307@redhat.com>

On 11/26/2012 09:06 AM, Livnat Peer wrote:
> Hi Guys,
> I'm about to send the proposal I worked on with Kolesnik to the list.
>
> Any political/other objections?
>
> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>
> We are starting to work on a POC to find the issues we missed in our
> research so far, sending this to the list can get the discussion going.
>
> Livnat
>

seems like an interesting solution, moving the problem of central dhcp 
to a distributed dhcp approach.

so iiuc:
- a per network config to specify if to enable IPAM on the logical
   network.
- ability to specify the ip address ranges per logical network?
- would we be able to set a policy at VM (or vnic) level to specify if
   the vnic is getting the IP from the IPAM, or not?
- do we expect another mode of IP allocation (via the payload)?
- iiuc, quantum would be the one allocating the ip addresses
   themselves. i assume there is an API allowing engine to get these ip
   addresses back to show to admin/user?
- in ec2, the ip address changes every boot. do we expect the IP to be
   reserved per mac address, or to be released when the VM goes down
   (not sure what's the default IPAM behavior).
   i could be confusing the IP behavior of the floating (public) IPs in
   ec2 with the private IPs (which may be durable.
- we'll need to think about the deployment aspects of qunatum service
   and its agents.
- you are designing a "configuration api" by changing the qunatum
   config and restarting the service. as the config file format may 
change, it may make sense to put a wrapper script around config changes, 
so the implementation of the required config could be change as qunatum 
evolves.

looking forward to see something working from all of this.

Thanks,
    Itamar


From iheim at redhat.com  Fri Nov 30 12:06:54 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 30 Nov 2012 14:06:54 +0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50AA334F.6010203@linux.vnet.ibm.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>	<509CA431.8080405@redhat.com>
	<50A1F141.9010500@redhat.com> <50A236E4.1070304@linux.vnet.ibm.com>
	<50A67925.1010704@linux.vnet.ibm.com> <50A8CAC9.9090403@redhat.com>
	<50AA334F.6010203@linux.vnet.ibm.com>
Message-ID: <50B8A15E.2010105@redhat.com>

On 11/19/2012 03:25 PM, Paulo de Rezende Pinatti wrote:
> On 11/18/2012 09:47 AM, Itamar Heim wrote:
>> On 11/16/2012 07:34 PM, Fernando Granha Jeronimo wrote:
>>> On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
>>>> On 11/13/2012 05:05 AM, Itamar Heim wrote:
>>>>> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>>>>>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine
>>>>>>> in a
>>>>>>> feature page:
>>>>>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>>>>>
>>>>>>> Suggestions and comments are greatly appreciated.
>>>>>>
>>>>>> iiuc, the most obvious change to mention is addition of an 'arch'
>>>>>> field
>>>>>> to cluster, which would affect the list of supported cpu families,
>>>>>> etc.?
>>>>>> (and to later know to filter all other aspects of entities based on
>>>>>> this
>>>>>> arch field)?
>>>>>>
>>>>>> list of possible arch's would be per cluster compatibility level.
>>>>>> i'd expect default for API of this field to be x86_64 for backward
>>>>>> compatibility, so it is not mandatory.
>>>>>> I'd also prefer this field to be disabled or hidden if there is only
>>>>>> one
>>>>>> option available in it.
>>>>>>
>>>>>> it gets more complicated, as VMs can be moved around between
>>>>>> clusters,
>>>>>> exported/imported, etc.
>>>>>>
>>>>>> you would need to validate a VM isn't moved to a cluster with a
>>>>>> different arch, or imported into a cluster with a different arch as
>>>>>> well.
>>>>>> (probably more like that).
>>>>>>
>>>>>> i assume the config to filter device types per arch like the network
>>>>>> devices is also for console (spice), audio, etc.
>>>>>>
>>>>>> the system already has the concept of filtering per cluster level, so
>>>>>> filtering per cluster level and arch would mean reviewing all
>>>>>> places in
>>>>>> code for that.
>>>>>
>>>>> I'm adding roy/omer/michal as the work on libosinfo (patches in
>>>>> gerrit[1]) seems to make some of these changes not needed (if it is
>>>>> merged).
>>>>> rather just need to extend libosinfo with the information on ppc.
>>>>>
>>>>> for sure worth reviewing both approaches to make sure the chosen
>>>>> solution benefits both and we collaborate on same end goal.
>>>>
>>>> thanks, we will check these patches and possibly change the approach
>>>> to use libosinfo.
>>>>
>>> Hello,
>>>
>>> We have carefully analyzed the engine libosinfo patches and the
>>> libosinfo itself to devise
>>> our conclusion. During this process, we found the following key points:
>>>
>>>    * In order to have a clear notion of supported versions and devices,
>>> we would
>>>      need to populate libosinfo's xmls for qemu and for devices, as well
>>> as implement logic in
>>>      ovirt-engine to process the relationship between them. This would
>>> be basically partially
>>>      reimplement the lib itself. In addition, given that we are not
>>> using the lib but actually processing
>>>      the xmls directly there is no guarantee that their structure will
>>> be preserved in the future,
>>>      which in the mid/long term may lead to code changes in the engine
>>> to adapt to it.
>>
>> I thought that is what roy's patches are doing?
>> i agree about the concern if the xml is changing.
>>
>>>    * Even if libosinfo had all the information we needed in the xmls, we
>>> would still need to validate
>>>      or filter values according to ovirt-engine's rules. For instance,
>>> if the list of network devices
>>>      for PowerKVM in libosinfo had 5 elements and the engine only
>>> intended to support/expose 2 specific models,
>>>      (for a given version for example) it has to be aware of these two
>>> models, meaning that even using libosinfo
>>>      we still need something in engine to validate them (which
>>> reinforces Itamar's filter suggestion).
>>
>> good point - Roy, how would cluster level compatibility for features
>> would work in your libosinfo approach?
>>
>>
>>>
>>> The primary concern of libosinfo patches is focused on virtual machine
>>> parameters validation based on OS.
>>> With regard to Power KVM support it doesn't address other areas like
>>> hypervisor/cluster validation logic.
>>
>> well, this could just be since it wasn't populated for a non x86_64
>> arch. would it make sense for you to discuss ppc support for libosinfo
>> regardless?
>>
>
> Thanks for your comments Itamar. It's good to discuss to find the best
> ways to proceed.
>
> I think the point Fernando made was that the libosinfo integration with
> ovirt is just for vm parameter validation, and other areas needing to
> change to support powerkvm such the hypervisor/cluster validation are
> not addressed by libosinfo at all, even for x86.

true, it doesn't solve everything, but it removes the need for the new 
config approach, if libosinfo path is chosen (since libosinfo contains 
similar metadata to the one we have in the config.

>
> It means that if we choose this path it would first be necessary to
> change ovirt code to tighter integrate with libosinfo, and implement the
> processing of links between xmls as well as validation of values against
> ovirt rules (both mentioned in bullets above). Libosinfo in turn would
> need its xmls populated to provide things like cpu flags, devices,
> hypervisor and versions information. These would be needed just for the
> code we have today, with no PowerKVM support yet.

actually, something i don't remember id discussed in the libosinfo approach:
roy - how do we handle the fact we actually need a libosinfo per cluster 
level?

>
> This would be a longer road which would be interesting to take if we had
> as a result a stable and centralized point of platform related
> information. But rather ovirt would be possibly sitting on unstable
> ground as Fernando well pointed the xmls can change at any time due to
> libosinfo projects needs, which would force ovirt to re-adapt to new xml
> formats. As to centralization, the information would still be partially
> dispersed due to the need to determine what ovirt wants to support (this
> kind of information cannot go in libosinfo).
>

yes, that is a concern.
but considering we may need to maintain a libosinfo per cluster level 
per my question above, we may want to adopt libosinfo "partially". i.e., 
we'd be copying and versioning it, or we'd be generating our own config 
format from it.
so if it changes, we'll just need to change the process we used to 
copy/generate it, but we'll be keeping our format and just leverage 
libosinfo as a db, but not the authoritative one, as we'll want to limit 
it to things we know, allow to extend it, etc.

so i agree libosinfo may not be the magic bullet, but i do think we need 
to move away from enum based OSs and db based config to a file based 
config of list of OSs and options for them (maybe simply one file per 
cluster level).

this file format can be based on libosinfo format, or another format 
which we'd be using libosinfo to populate maintain.

michael/roy - thoughts?

Thanks,
    Itamar


From dneary at redhat.com  Fri Nov 30 14:52:07 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 30 Nov 2012 15:52:07 +0100
Subject: RFC: oVirt NetApp workshop Call for Content
Message-ID: <50B8C817.3060106@redhat.com>

Hi all,

I just put a draft call for content in a new page for the NetApp 
workshop on the wiki: http://www.ovirt.org/NetApp_Workshop_January_2013

The call for contents is basically a copy of the topic list from the KVM 
Forum/oVirt Workshop in Barcelona. Some points to note:
* I set the deadline close, so that we could notify speakers before the 
holidays, and allow people coming from further away to organise travel 
arrangements. Is 2 weeks for a Call for Content enough?
* We will re-use the workshop-pc mailing list for proposals and 
discussion. There was an open discussion point about what our 
subscription and posting policy should be for the list - I suggest that 
non-members may post to the list, and anyone can subscribe.

I would like to actively reach out to some oVirt users and partners to 
ensure that we have a diverse set of content for the conference - I 
would expecially like to hear some interesting case studies about the 
ways that oVirt is being used!

Can I get some comments on this quickly, please? If it is acceptable, I 
would like to push it more widely this evening.

Thanks,
Dave.

Call for Content

We are actively seeking speakers for this workshop. We are interested in 
talks in the following areas:

  *  Case studies of oVirt deployments
  *  Using oVirt effectively
  *  oVirt Project 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

Please submit talk proposals for review by sending a message to 
workshop-pc at ovirt.org. Your email should include your full name, speaker 
biography and your talk abstract. We will accept submissions through 
Friday, 14 December 2012 at 23:55 UTC. Speakers will be notified of 
acceptance by Friday, 21 December 2012.

Accepted speakers should plan to submit their slides to the 
workshop-pc at ovirt.org mailing list no later than close of business on 
Friday, 18 January 2013.

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


From kwade at redhat.com  Fri Nov 30 18:56:13 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Fri, 30 Nov 2012 10:56:13 -0800
Subject: Move of www.ovirt.org
Message-ID: <50B9014D.2000201@redhat.com>

Since we were using the host that was www.ovirt.org for many things
other than MediaWiki, you may find that some of your automated
activities are going to fail.

We set up a new hostname for these various resources that are currently
hosted on linode01.ovirt.org, with redirects in place from www:

http://resources.ovirt.org/releases
http://resources.ovirt.org/meetings
etc.

As nothing else has changed about that host, you should be able to
s/www/resources/g wherever you use it, and things will Just Work.

If you run in to a snag, let us know - we may need to add an http
rewrite rule, etc.

- Karsten
-- 
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: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121130/0bf91350/attachment.sig>

From dfediuck at redhat.com  Fri Nov 30 22:17:20 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Fri, 30 Nov 2012 17:17:20 -0500 (EST)
Subject: New website live! Feedback welcome
In-Reply-To: <50B8A433.1050209@redhat.com>
Message-ID: <1761506442.36588886.1354313840898.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Dave Neary" <dneary at redhat.com>
> To: announce at ovirt.org, "users" <users at ovirt.org>
> Sent: Friday, November 30, 2012 2:18:59 PM
> Subject: New website live! Feedback welcome
> 
> Hi everyone,
> 
> The new oVirt website is now live!
> 
>    http://www.ovirt.org
> 
> We have made some changes to the infrastructure (the website is now
> running on MediaWiki: http://www.mediawiki.org on Red Hat's Platform
> as
> a Service offering OpenShift: https://openshift.redhat.com) and also
> to
> the look and feel. There is a new theme, designed and laid out by
> Garrett Lesage, some new content to discover, and best of all, since
> the
> entire website is now a wiki, it will be much easier to maintain over
> time.
> 
> We have been careful to ensure that all of the old website links
> redirect to appropriate pages on the new site. If you find any dead
> links, or redirects which do not make sense, please let us know! And
> as
> the site has had limited exposure up to this point, we are happy to
> hear
> your feedback on things you like, and things we can improve.
> 
> Thank you all for your support, assistance and understanding
> throughout
> this process!
> 
> Regards,
> Dave.
> 
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13

Hi Dave,
Wicked awesome ;)
Looks so much better now.

There are a few things I'm missing which may further improve the site;

- In the community page, a section called (something in the spirit of) "Getting Help",
which routes the users to the irc and users' list is much needed. It can even be one of
the menu items in the main tool-bar.

- The documentation page rightfully embeds 2 youtube clips. I think we can add a section
for the youtube ovirt area, as these clips are documenting some of our features. We got several
feedbacks that the clips are very helpful for understanding some of the concepts.

- Going forward a forum would be nice, but need to see how it integrates with the lists.
Possibly limit it to users forum?

Thanks again!
Doron