Agenda for today's call
by abaron＠redhat.com
Hi all,
I would like to discuss the following on today's call:
1. Gerrit vs. mailing list
2. mandatory unittest per patch
3. pep8
4. ??
If you have anything else you'd like to discuss, please reply to this email.
Regards,
Ayal.
11 years, 8 months
Re: [vdsm] [Users] How to configure sharedFS ?
by deepakcs＠linux.vnet.ibm.com
On 02/29/2012 08:06 PM, Dan Kenigsberg wrote:
> On Wed, Feb 29, 2012 at 07:42:15PM +0530, Deepak C Shetty wrote:
>> On 02/27/2012 04:55 AM, Ayal Baron wrote:
>>> Any help on documenting this so people would not have to dig into the code would be greatly appreciated.
>>>
>>>> Great, let me start and get back if i land up into issues.
>>>> thanks for the pointer.
>>> Let us know if you need further assistance..
>>
> If you have that python script working for LOCALFS, I'd suggest you try
> making it work for SHAREDFS too.
>
>
I was able to use the VDSM_Standalone example, and modify it to use SHAREDFS
and export glusterfs as a DATA_DOMAIN and invoke VM backed by gluster
storage.
I edited http://www.ovirt.org/wiki/Vdsm_Standalone (scroll below) &
added it as
a SHAREDFS example.
11 years, 10 months
Re: [vdsm] Storage Device Management in VDSM and oVirt
by Dan Kenigsberg
On Wed, Apr 18, 2012 at 09:06:36AM -0400, Ayal Baron wrote:
>
>
> ----- Original Message -----
> > On Tue, Apr 17, 2012 at 03:38:25PM +0530, Shireesh Anjal wrote:
> > > Hi all,
> > >
> > > As part of adding Gluster support in ovirt, we need to introduce
> > > some Storage Device management capabilities (on the host). Since
> > > these are quite generic and not specific to Gluster as such, we
> > > think it might be useful to add it as a core vdsm and oVirt
> > > feature.
> > > At a high level, this involves following:
> > >
> > > - A "Storage Devices" sub-tab on "Host" entity, displaying
> > > information about all the storage devices*
> > > - Listing of different types of storage devices of a host
> > > - Regular Disks and Partitions*
> > > - LVM*
> > > - Software RAID*
> > > - Various actions related to device configuration
> > > - Partition disks*
> > > - Format and mount disks / partitions*
> > > - Create, resize and delete LVM Volume Groups (VGs)
> > > - Create, resize, delete, format and mount LVM Logical Volumes
> > > (LVs)
> > > - Create, resize, delete, partition, format and mount Software
> > > RAID devices
> > > - Edit properties of the devices
> > > - UI can be modeled similar to the system-config-lvm tool
> > >
> > > The items marked with (*) in above list are urgently required for
> > > the Gluster feature, and will be developed first.
> > >
> > > Comments / inputs welcome.
> >
> > This seems like a big undertaking, and I would like to understand the
> > complete use case of this. Is it intended to create the block storage
> > devices on top of which a Gluster volume will be created?
>
> Yes, but not only.
> It could also be used to create the file system on top of which you create a local storage domain (just an example, there are many others, more listed below).
>
> >
> > I must tell that we had a bad experience with exposing low level
> > commands over the Vdsm API: A Vdsm storage domain is a VG with some
> > metadata on top. We used to have two API calls for creating a storage
> > domain: one to create the VG and one to add the metadata and make it
> > an
> > SD. But it is pretty hard to handle all the error cases remotely. It
> > proved more useful to have one atomic command for the whole sequence.
> >
> > I suspect that this would be the case here, too. I'm not sure if
> > using
> > Vdsm as an ssh-replacement for transporting lvm/md/fdisk commands is
> > the
> > best approach.
>
> I agree, we should either provide added value or figure out a way where we don't need to simply add a verb every time the underlying APIs added something.
>
> >
> > It may be better to have a single verb for creating Gluster volume
> > out
> > of block storage devices. Something like: "take these disks,
> > partition
> > them, build a raid, cover with a vg, carve some PVs and make each of
> > them a Gluster volume".
> >
> > Obviously, it is not simple to define a good language to describe a
> > general architecture of a Gluster voluem. But it would have to be
> > done
> > somewhere - if not in Vdsm then in Engine; and I suspect it would be
> > better done on the local host, not beyond a fragile network link.
> >
> > Please note that currently, Vdsm makes a lot of effort not to touch
> > LVM
> > metadata of existing VGs on regular "HSM" hosts. All such operations
> > are
> > done on the engine-selected "SPM" host. When implementing this, we
> > must
> > bear in mind these safeguards and think whether we want to break
> > them.
>
> I'm not sure I see how this is relevant, we allow creating a VG on any host today and that isn't going to change...
We have one painful exception, that alone is no reason to add more. Note
that currently, Engine uses the would-be-spm for vg creation. In the
gluster use case, any host is expected to do this on async timing. It
might be required, but it's not warm and fuzzy.
>
> In general, we know that we already need to support using a LUN even if it has partitions on it (with force or something).
>
> We know that we have requirements for more control over the VG that we create e.g. support striping, control over max LV size (limited by pv extent size today) etc.
>
> We also know that users would like a way not only to use a local dir for a storage domain but also create the directory + fs?
These three examples are storage domain flavors..
>
> We know that in the gLuster use case we would like the ability to setup samba over the gluster volume as well as iSCSI probably.
Now I do not see the relevance. Configuring gluster and how it exposes
its volume is something other than preparing block storage for gluster
bricks.
>
> So although I believe that when we create a gluster volume or an ovirt storage domain then indeed we shouldn't need a lot of low level commands, but it would appear to me that not allowing for more control when needed is not going to work and that there are enough use cases which do not involve a gluster volume nor a storage domain to warrant this to be generic.
I'm not against more control; I'm against uncontrollable API such as
runThisLvmCommandAsRoot()
11 years, 11 months
pep8 check in vim
by smizrahi＠redhat.com
Now that we started moving to conform with pep8 you would probably like to be able to easily check your code.
If you use vim you could use this vim script
http://www.vim.org/scripts/script.php?script_id=2914
I you are not using vim follow these 3 simple steps:
1. Switch to vim
2. Install the script
3. Profit
11 years, 12 months
reserve virtio-balloon device created by libvirt
by wudxw＠linux.vnet.ibm.com
Hi guys,
I saw that an option to create balloon device was added by Gal in
http://gerrit.ovirt.org/1573
I have a question about it. Why don we preserve the old default
behaviour? I know it's not supported by ovirt-engine now, but I can't
figure out what will break if it's not disabled explicitly. So do you
think we can just make use of the balloon device added by libvirt?
Thanks!
Mark
11 years, 12 months
vdsm on openSuSE
by Sascha Littel
Hi everybody, I'm working currently on a running version of vdsm 4.9.1
for openSuSE 11.3. I'm changing many lines in the start/stop scripts
e.g. paths, rc commands. Most of this work looks fine but if I try to
get a connection between the oVirt engine (runs on a openSuSE 12.1) and
the vdsm host I get a ssl error. Also after setting ssl in vdsm.conf to
false and changing the settings in oVirt engine database I still get
this error.
So the general question, is there someone working on a openSuSE 11.3 or
11.4 version of vdsm? Or someone who has experience how to get it work?
Regards
Sascha Littel
--
SASCHA LITTEL
Systemintegration
AIGES oHG
Maternuskirchplatz 9 / 50678 Köln / Germany
Phone: +49-(0)221-3401-334
Fax: +49-(0)221-3401-471
sascha.littel(a)aiges.de / www.aiges.de
facebook.com/AIGES
twitter.com/aigesnews
Sitz der Gesellschaft: Köln
Geschäftsführung: Athansios Bountos, Jan Zimmerschied
Registergericht: Amtsgericht Köln /HRA 22818
Vat-ID DE242593530
-- Disclaimer ------------------------------------
Diese E-mail und alle Anhänge sind vertrauliche Korrespondenz, die nur für
den Gebrauch durch die oben genannten Empfänger bestimmt ist. Wenn Sie nicht
der beabsichtigte Empfänger oder dessen Vertreter sind, werden Sie hiermit
unterrichtet, dass jede mögliche Druckausgabe, Verteilung oder Kopie dieser
Korrespondenz grundsätzlich verboten ist. Wenn Sie diese Korrespondenz
aufgrund eines Versehens empfangen haben, teilen Sie dies bitte dem Absender
durch Telefon oder indem Sie dieser E-Mail antworten, mit und löschen Sie dann
diese E-Mail aus Ihrem System.
***
This e-mail and any attachments is a confidential correspondence intended
only for use of the individual or entity named above. If you are not the
intended recipient or the agent responsible for delivering the message to the
intended recipient, you are hereby notified that any disclosure, distribution
or copying of this communication is strictly prohibited. If you have received
this communication in error, please notify the sender by phone or by replying
this message, and then delete this message from your system.
***
11 years, 12 months
Re: [vdsm] vdsm on openSuSE
by dfediuck＠redhat.com
np
Community's here for you :)
Sent from my Android phone. Please ignore typos.
-----Original Message-----
From: Sascha Littel [sascha.littel(a)aiges.de]
Received: Monday, 30 Apr 2012, 18:46
To: Doron Fediuck [dfediuck(a)redhat.com]
CC: vdsm-devel(a)lists.fedorahosted.org
Subject: Re: [vdsm] vdsm on openSuSE
Am Montag, 30. April 2012, 16:45:12 schrieben Sie:
> Hi Sasha,
> This may be an issue of SSH authentication method.
> Can you please check you SSH server in the host-
> Password auth should be password and not Keyboard-interactive.
> This may lead to SSH auth failure as you engine log indicates.
Thanks dude this was the hint I need. I changed the PasswordAuthentication in
/etc/ssh/sshd_config. Now I can add the vdsm into the oVirt engine host. Now
the real work can beginn.
>
> > Am Montag, 30. April 2012, 13:09:25 schrieben Sie:
> >> On 04/30/2012 02:07 PM, Sascha Littel wrote:
> >> > Am Montag, 30. April 2012, 05:04:09 schrieben Sie:
> >> >> On 04/29/2012 10:24 PM, S. Littel wrote:
> >> >>> Hi everybody, I'm working currently on a running version of vdsm
> >> >>> 4.9.1 for openSuSE 11.3. I'm changing many lines in the start/stop
> >> >>> scripts e.g. paths, rc commands. Most of this work looks fine but
> >> >>> if I try to get a connection between the oVirt engine (runs on a
> >> >>> openSuSE 12.1) and the vdsm host I get a ssl error. Also after
> >> >>> setting ssl in vdsm.conf to false and changing the settings in
> >> >>> oVirt engine database I still get this error.
> >> >>
> >> >> which settings are you changing in the db?
> >> >
> >> > I changed the seetings in the database with this 2 commands:
> >> did you restart engine after changing these?
> >
> > Yes. I found this page in the oVirt Wiki:
> > http://ovirt.org/w/index.php?title=OVirt_-
> > _disable_SSL_in_VDSM&diff=3036&oldid=prev
> >
> >> > psql engine -U postgres -c "UPDATE vdc_options set option_value =
> >> > 'false' where option_name = 'SSLEnabled'"
> >> >
> >> > psql engine -U postgres -c "UPDATE vdc_options set option_value =
> >> > 'false' where option_name = 'UseSecureConnectionWithServers'"
> >> >
> >> >> UseSecureConnectionWithServers?
> >> >
> >> > Yes.
> >> >
> >> >>> So the general question, is there someone working on a openSuSE 11.3
> >> >>> or 11.4 version of vdsm? Or someone who has experience how to get
> >> >>> it work?
> >> >>>
> >> >>> Regards
> >> >>>
> >> >>> Sascha Littel
> >> >
> >> > Here is the failure massage from the vdsm-reg.log I get on the vdsm
> >> > host:
> >> >
> >> > SSLError: [Errno 185090050] _ssl.c:328: error:0B084002:x509
> >> > certificate routines:X509_load_cert_crl_file:system lib
> >> > MainThread::DEBUG::::deployUtil::1413::root::getRemoteFile end.
> >> > MainThread::DEBUG::::deployUtil::621::root::handleSSHKey start
> >> > MainThread::ERROR::::deployUtil::614::root::restorecon
> >> > /root/.ssh/authorized_keys failed
> >> >
> >> > And this is the failure message from engine.log on the oVirt engine
> >> > host:
> >> >
> >> > ERROR [org.ovirt.engine.core.utils.hostinstall.MinaInstallWrapper]
> >> > (http--0.0.0.0-8443-1) Could not connect to server
> >> > xen007.f1.aiges.net: Failed connecting
> >> >
> >> > to xen007.f1.aiges.net using given password! Please verify your
> >> > password is
> >> >
> >> > correct and that the host accepts password-based authentication
> >> > WARN [org.ovirt.engine.core.bll.AddVdsCommand] (http--0.0.0.0-8443-1)
> >> > CanDoAction of action AddVds failed.
> >> > Reasons:VDS_CANNOT_CONNECT_TO_SERVER,VAR__ACTION
> >> > __ADD,VAR__TYPE__HOST
> >> >
> >> > Regards
> >> >
> >> > Sascha Littel
--
SASCHA LITTEL
Systemintegration
AIGES oHG
Maternuskirchplatz 9 / 50678 Köln / Germany
Phone: +49-(0)221-3401-334
Fax: +49-(0)221-3401-471
sascha.littel(a)aiges.de / www.aiges.de
facebook.com/AIGES
twitter.com/aigesnews
Sitz der Gesellschaft: Köln
Geschäftsführung: Athansios Bountos, Jan Zimmerschied
Registergericht: Amtsgericht Köln /HRA 22818
Vat-ID DE242593530
-- Disclaimer ------------------------------------
Diese E-mail und alle Anhänge sind vertrauliche Korrespondenz, die nur für
den Gebrauch durch die oben genannten Empfänger bestimmt ist. Wenn Sie nicht
der beabsichtigte Empfänger oder dessen Vertreter sind, werden Sie hiermit
unterrichtet, dass jede mögliche Druckausgabe, Verteilung oder Kopie dieser
Korrespondenz grundsätzlich verboten ist. Wenn Sie diese Korrespondenz
aufgrund eines Versehens empfangen haben, teilen Sie dies bitte dem Absender
durch Telefon oder indem Sie dieser E-Mail antworten, mit und löschen Sie dann
diese E-Mail aus Ihrem System.
***
This e-mail and any attachments is a confidential correspondence intended
only for use of the individual or entity named above. If you are not the
intended recipient or the agent responsible for delivering the message to the
intended recipient, you are hereby notified that any disclosure, distribution
or copying of this communication is strictly prohibited. If you have received
this communication in error, please notify the sender by phone or by replying
this message, and then delete this message from your system.
***
Sent from my Android phone. Please ignore typos.
11 years, 12 months
Installation dependency for VDSM-4.9.6-0.109 package on FC16
by shuming＠linux.vnet.ibm.com
Hi,
I am trying to upgrade my VDSM to the latest version. But it seems
that several things should be upgraded before the new version of VDSM
can be installed on fc16. I am wondering if FC16 is the recommended
system for this upgrade. Can anyone tell me if the newer version of
Fedora(FC17, FC18) are more compatible with the latest VDSM packages?
Dependency check failed here.
-----------------------------------------------l
[root@ovirt-node2 ~]# yum install vdsm
Loaded plugins: langpacks, presto, refresh-packagekit
fedora/metalink | 9.5 kB 00:00
ovirt-engine | 1.3 kB 00:00
updates/metalink | 4.4 kB 00:00
updates | 4.5 kB 00:00
updates/primary_db | 5.9 MB 00:14
updates/group | 1.9 MB 00:04
vdsm-changes | 2.9 kB 00:00
vdsm-changes/primary_db | 5.4 kB 00:00
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package vdsm.x86_64 0:4.9.3.2-0.fc16 will be updated
---> Package vdsm.x86_64 0:4.9.6-0.109.git009bc0c.fc16 will be an update
--> Processing Dependency: vdsm-python = 4.9.6-0.109.git009bc0c.fc16 for
package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: libvirt-python >= 0.9.10 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: lvm2 >= 2.02.95 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: libvirt >= 0.9.10 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: sanlock >= 2.1 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: ntp for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: sanlock-python for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Running transaction check
---> Package ntp.x86_64 0:4.2.6p4-1.fc16 will be installed
--> Processing Dependency: ntpdate = 4.2.6p4-1.fc16 for package:
ntp-4.2.6p4-1.fc16.x86_64
---> Package sanlock-python.x86_64 0:1.9-8.fc16 will be installed
--> Processing Dependency: sanlock-lib = 1.9-8.fc16 for package:
sanlock-python-1.9-8.fc16.x86_64
--> Processing Dependency: libsanlock.so.1()(64bit) for package:
sanlock-python-1.9-8.fc16.x86_64
---> Package vdsm.x86_64 0:4.9.6-0.109.git009bc0c.fc16 will be an update
--> Processing Dependency: libvirt-python >= 0.9.10 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: lvm2 >= 2.02.95 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: libvirt >= 0.9.10 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: sanlock >= 2.1 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
---> Package vdsm-python.noarch 0:4.9.6-0.109.git009bc0c.fc16 will be
installed
--> Running transaction check
---> Package ntpdate.x86_64 0:4.2.6p4-1.fc16 will be installed
---> Package sanlock-lib.x86_64 0:1.9-8.fc16 will be installed
---> Package vdsm.x86_64 0:4.9.6-0.109.git009bc0c.fc16 will be an update
--> Processing Dependency: libvirt-python >= 0.9.10 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: lvm2 >= 2.02.95 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: libvirt >= 0.9.10 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Processing Dependency: sanlock >= 2.1 for package:
vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64
--> Finished Dependency Resolution
Error: Package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 (vdsm-changes)
Requires: sanlock >= 2.1
Available: sanlock-1.8-1.fc16.x86_64 (fedora)
sanlock = 1.8-1.fc16
Available: sanlock-1.9-8.fc16.x86_64 (updates)
sanlock = 1.9-8.fc16
Error: Package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 (vdsm-changes)
Requires: libvirt-python >= 0.9.10
Installed: libvirt-python-0.9.6-4.fc16.x86_64 (@updates)
libvirt-python = 0.9.6-4.fc16
Available: libvirt-python-0.9.6-2.fc16.x86_64 (fedora)
libvirt-python = 0.9.6-2.fc16
Available: libvirt-python-0.9.6-5.fc16.x86_64 (updates)
libvirt-python = 0.9.6-5.fc16
Error: Package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 (vdsm-changes)
Requires: lvm2 >= 2.02.95
Installed: lvm2-2.02.86-5.fc16.x86_64
(@koji-override-0/$releasever)
lvm2 = 2.02.86-5.fc16
Available: lvm2-2.02.86-6.fc16.x86_64 (updates)
lvm2 = 2.02.86-6.fc16
Error: Package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 (vdsm-changes)
Requires: libvirt >= 0.9.10
Installed: libvirt-0.9.6-4.fc16.x86_64 (@updates)
libvirt = 0.9.6-4.fc16
Available: libvirt-0.9.6-2.fc16.x86_64 (fedora)
libvirt = 0.9.6-2.fc16
Available: libvirt-0.9.6-5.fc16.x86_64 (updates)
libvirt = 0.9.6-5.fc16
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
[root@ovirt-node2 ~]#
--
Shu Ming<shuming(a)linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory
12 years
upstream/downstream compat
by Ryan Harper
I've submitted some changes to start some of the work of removing the
RHEV/RHEVM names throughout the vdsm code. In one of the patches,
there's a good discussion on compatibility with downstream[1]
And I wanted to continue that on the mailing list so we could have more
eyes; it's not clear to me if everyone is able to see/participate in an
inline thread to just one of my patches.
To the point; as we look at moving toward an upstream vdsm which may be
used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
driving actions. I'm interested in hearing details what our
requirements for compatibility are and which parts of the tree might be
affected.
I'd like to posit that downstream compat is the responsibility of the
distro versus the upstream community; though that's not a license to
make things difficult. IMHO, this means we can do things that help
clean up the code or move the project in a particular direction without
having to always worry about what the package looks like in a particular
distro.
The other aspect to compatibility I'd like to hear details/discussion on
the interfaces (explicit or implicit) between vdsm and ovirt-engine.
I rekindled a discussion[2] on at least one known issue around engine
including the qemu machine type in the database; Any pointers to other
places would be helpful as I'm wrapping my head around the back and
forth between vdsm and engine.
1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py
2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
12 years
