[ovirt-devel] Re: Upgrade GWT to 2.9.0

[Daniel Erez]

On Fri, Jul 24, 2020 at 1:02 PM Radoslaw Szwajkowski 
wrote:

> Hi all,
> we plan to bump the GWT version to 2.9.0 (patch [1]).
> Key changes:
> 1. support for building with Java 11
> 2. removing support for classic dev mode ( use super dev mode instead)
>

Is it mandatory to remove classic dev mode due to version bump? iirc, super
dev mode
as a limitation of supporting local debug only. I.e. engine should be on
the same machine as chrome.
Or is it already resolved by any chance?


> 3. accumulated improvements and bug fixes (from versions 2.8.1, 2.8.2,
> 2.9.0)
>
> Please review and check if your areas are impacted.
> For details see BZ [2]
>
> best regards,
> radek
>
> [1] https://gerrit.ovirt.org/110359/
> [2] https://bugzilla.redhat.com/1860309
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/UY5ML5LKOKNKT4XJ4YDMKRBVKAXYQUOM/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FXMA5AOFFJRVJXUMCTPKZOFJ4D2DHRQA/

[ovirt-devel] Re: Problem with mixing all the changes

[Daniel Erez]

On Tue, May 19, 2020 at 1:52 PM FMGarcia  wrote:

> Hello Nir,
>
> Sorry for the wait, I was involved with other issues.
>
>
> Right now I don't have much time to implement this issue. However, I could
> deploy a Centos8.1 and I'm able to test it. In a few days I could deploy it.
>
> Is there a tutorial for testing these compilations? (Necessary
> dependencies, scripts to remove all traces of the previous installed
> version, etc.)
>
> I understand that the changes you have made these days at
> https://gerrit.ovirt.org/#/c/108991/ are almost final, right? Could you
> test them already? Or do I wait a little?
>

Yes, the fix has been merged to master and ready for test :) It should
resolve: https://bugzilla.redhat.com/1707707
If you're planning to upgrade to oVirt 4.4, it should be available in a
future release candidate.
Or is it crucial for you to have it in a 4.3.z build?


>
>
>
> Despite the fact that you have implemented some very complete scripts
> (backup-disk and upload-disk). In the short term, I'm still interested in
> the snapshot-based model. Since in my Java code, I support full,
> incremental and differential backups with the limitation that the storage
> domain cannot be a block domain, in NFS(for example) it works very well!.
> However, in the vms that have some disk stored in a block domain, I can
> only make a backup by means of a snapshot clone. Until this is resolved :)
> hehe.
>
>
> BTW, thanks for your '*backup_disk.py demo*', it looks so good!. If I
> have some time I will try to test it in my environment. :)
>
>
> Best regards,
>
> Fran
>
>
> On 5/14/20 5:39 PM, Nir Soffer wrote:
>
> On Wed, May 13, 2020 at 12:19 PM FMGarcia  
>  wrote:
>
> Hi Fran, I'm moving the discussion to devel mailing list where it belongs.
>
>
> In https://gerrit.ovirt.org/#/c/107082/ we have "several problems" to decide 
> this patch:
>
> At the base (current version in github), the synergy 
> ('download_disk_snapshot.py' and 'upload_disk_snapshot.py') does not working:
>
> 'Download_disk_snapshot.py' only download volumes of a disk.
> 'Upload_disk_snapshot.py' requires: virtual machine configuration ('.ovf'), a 
> only disk to upload in path './disks/', and manual action to attach disk 
> to the vm.
>
> Then, I think that if you want a synergy with both scripts, we should change 
> 'download_disk_snapshot.py' before that 'upload_disk_snapshot.py'. If not, 
> you should edit 'upload_disk_snapshot.py' to add a variable 'vm_id'(as 
> variable sd_name in this script) to attach the uploaded disk.
>
> I agree. It would be nice if we can do:
>
> $ mkdir -p backups/vm-id
> $ download_disk_snapshots.py --backup-dir backups/vm-id ...
> $ upload_disk_snapshots.py --backup-dir backups/vm-id ...
>
> download_disk_snapshots.py will download vm ovf and all disks.
> upload_disk_snaphsots.py
> would take the output of download_disk_snapshots.py and create a new vm.
>
>
> I suppose that the best thing is to discard the gerrit, and to propose first 
> what you want with 'download_disk_snapshot.py' and 'upload_disk_snapshot.py' 
> and then act accordingly (several patch). Do you agree?
>
> This is a bigger change that can take more time. I think we better fix
> the issues in the current
> scripts - the first one is the missing attach disk that you fix in your patch.
>
> Since you posted this fix with a lot of other unrelated fixes (some
> wrong or unneeded),
> we cannot merge it. This is another reason to post minimal patches
> that do one fix.
>
>
> I'm only truly interested in opened bug with block domain and volumes of > 
> 1GB: https://bugzilla.redhat.com/show_bug.cgi?id=1707707. I make these 
> changes to help a little since you would help me by solving the bug. I don't 
> code in Python, I code in Java, using Java-sdk and the bug is a major 
> limitation in my software, so I want resolve this bug (1 year old). =( I hope 
> you understand. :)
>
> Sure, I understand.
>
> If you don't time to work on this, some other developer can take over
> this patch.
>
> The bug should be fixed by:https://gerrit.ovirt.org/c/108991/
>
> It would be nice if you can test this. I started a build 
> here:https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/5867/
>
> When the build is ready, you will be able to install engine from this
> build by adidng
> a yum repo with the 
> baseurl:https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/5867/artifact/build-artifacts.el8.x86_64/
>
> Note that this requires CentOS 8.1. If you want to test on CentOS 7,
> you need to wait until
> the fix will be backported to 4.3, or since you like Java, maybe port
> it yourself?
>
> Note also that we have a much more advanced backup and restore 
> options:https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/backup_vm.py
>
> Here is example run I did yesterday:
>
> I started with full backup of a running vm:
>
> $ ./backup_vm.py full --engine-url https://engine3/ --username
> admin@internal --password-file
> /home/nsoffer

[ovirt-devel] Re: Proposing Benny Zlotnik as an Engine Storage maintainer

[Daniel Erez]

On Fri, Feb 21, 2020 at 8:53 PM Tal Nisan  wrote:

> Hi everyone,
> Benny joined the Storage team in November 2016 and since then played a key
> role in investigating very complex customer bugs around oVirt engine as
> well as contributing to features such as DR, Cinberlib, new export/import
> mechanism and also rewrote and still maintains the LSM mechanism.
> Given his big contribution and knowledge around the engine I'd like to
> nominate Benny as an engine storage maintainer.
>
> Your thoughts please.
>

+1


> Tal.
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/G52XI2QDSJNAOMZURGAFQJH2RZIHJBRX/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/5WAJXJSAOAX2H4MM6D5WULFW4I7VEGM5/

[ovirt-devel] Re: Failed to install ovirt-imageio-proxy for fc30

[Daniel Erez]

On Tue, Jan 7, 2020 at 5:37 PM Shani Leviim  wrote:

> Hi All,
> I ran into a dependencies issue while trying to install imageio over fc30.
> I currently have a
> ovirt-imageio-common-1.6.2-0.202001051603.git77cf282.fc30.x86_64
> but when I'm trying to install ovirt-imageio-proxy, I'm getting the
> following error:
>

imageio-proxy is still not supported on python3, so it doesn't work on fc30
yet...
For now, to use the proxy you have to install the engine on fc29 or centos7.
Are you trying to resolve an issue in imageio or just use it for something?


>
> Error:
>  Problem: conflicting requests
>   - nothing provides ovirt-imageio-common = 1.5.0 needed by
> ovirt-imageio-proxy-1.5.0-0.201812112104.gitf7d8234.fc30.noarch
>
> I've also noticed that the available version in the repository for fc30 is
> ovirt-imageio-proxy-1.5.0 [1]
> While version 1.6.2 is available for rhel7 [2].
>
> Please assist.
>
> [1]
> https://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc30/noarch/ovirt-imageio-proxy-1.5.0-0.201812112104.gitf7d8234.fc30.noarch.rpm
>
> [2]
> https://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-imageio-proxy-1.6.2-0.202001021817.gitbc71b2e.el7.noarch.rpm
>
>
> *Regards,*
>
> *Shani Leviim*
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7IXIQ5QE2SLTCPLK3SMZ6UXVM7YRUE5Q/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/SO54IEZXAM65CFDJBQ5TSGUT55STDQFS/

[ovirt-devel] Re: Failure to run engine-setup

[Daniel Erez]

On Tue, Jul 30, 2019 at 1:48 PM Simone Tiraboschi 
wrote:

>
>
> On Tue, Jul 30, 2019 at 9:48 AM Eyal Shenitzky 
> wrote:
>
>> Hi All,
>>
>> I am failing to run engine-setup due to the following issue:
>>
>> [ INFO  ] Generating post install configuration file
>> '/home/eshenitz/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'
>>
>> [ ERROR ] Failed to execute stage 'Misc configuration': a bytes-like
>> object is required, not 'str'
>> [ INFO  ] Rolling back database schema
>>
>>
>> In the setup log I can see -
>>
>> 2019-07-30 10:41:31,418+0300 DEBUG otopi.transaction
>> transaction._prepare:61 preparing 'File transaction for
>> '/home/eshenitz/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-s
>> etup-ovirt-post.conf''
>> 2019-07-30 10:41:31,418+0300 DEBUG otopi.filetransaction
>> filetransaction.prepare:184 file
>> '/home/eshenitz/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.con
>>
>> f' missing
>> 2019-07-30 10:41:31,419+0300 DEBUG otopi.transaction
>> transaction._prepare:66 exception during prepare phase
>> Traceback (most recent call last):
>>  File "/usr/lib/python3.6/site-packages/otopi/transaction.py", line 62,
>> in _prepare
>>element.prepare()
>>  File "/usr/lib/python3.6/site-packages/otopi/filetransaction.py", line
>> 253, in prepare
>>os.write(fd, self._content)
>> TypeError: a bytes-like object is required, not 'str'
>> 2019-07-30 10:41:31,420+0300 DEBUG otopi.context
>> context._executeMethod:145 method exception
>> Traceback (most recent call last):
>>  File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in
>> _executeMethod
>>method['method']()
>>  File
>> "/home/eshenitz/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/postinstall.py",
>> line 98, in _misc
>>otopicons.CoreEnv.MODIFIED_FILES
>>  File "/usr/lib/python3.6/site-packages/otopi/transaction.py", line 106,
>> in append
>> self._prepare(element=element)
>>  File "/usr/lib/python3.6/site-packages/otopi/transaction.py", line 62,
>> in _prepare
>>element.prepare()
>>  File "/usr/lib/python3.6/site-packages/otopi/filetransaction.py", line
>> 253, in prepare
>>os.write(fd, self._content)
>> TypeError: a bytes-like object is required, not 'str'
>> 2019-07-30 10:41:31,421+0300 ERROR otopi.context
>> context._executeMethod:154 Failed to execute stage 'Misc configuration': a
>> bytes-like object is required, not 'str'
>> 2019-07-30 10:41:31,421+0300 DEBUG otopi.transaction
>> transaction.abort:119 aborting 'CinderLib Database Transaction'
>>
>> Does anyone encounter it?
>>
>
> Maybe is a side effect of https://gerrit.ovirt.org/#/c/102204/ on python
> 3 env.
>

Indeed. Pushed this to solve it for now:
https://gerrit.ovirt.org/#/c/102259/


> Didi?
>
>
>>
>> Thanks,
>> --
>> Regards,
>> Eyal Shenitzky
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/OXHERFXZVEJVTJSJA2CNCXNWCFYIWOPW/
>>
>
>
> --
>
> Simone Tiraboschi
>
> He / Him / His
>
> Principal Software Engineer
>
> Red Hat 
>
> stira...@redhat.com
> @redhatjobs    redhatjobs
>  @redhatjobs
> 
> 
> 
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/EFC3IDDP3TRLPDKM7K4BHWF3A4H5ITRY/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/X7VJN6JOOVGB4PGA4CQRYNAVOLWKCGSX/

[ovirt-devel] Re: proposing Ales Musil as a frontend maintainer

[Daniel Erez]

On Thu, May 2, 2019 at 9:42 PM Greg Sheremeta  wrote:

> Hi all,
>
> I'd like to propose Ales Musil as a frontend maintainer for network parts
> of the admin portal UI. Since joining the team 2 years ago, Ales has
> quickly become very knowledgeable about all of the GWT intricacies of the
> admin portal. I trust his expertise and judgment.
>

+1


>
> Best wishes,
> Greg
>
> --
>
> Greg Sheremeta
>
> Senior Software Engineer
>
> Red Hat 
> 
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/ML5UVKYABG744KHEBSMMEB26D3RYOWR7/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/N7WW4AWIZQII56TH7ATXACH5HPN5OFCC/

[ovirt-devel] Re: the mess with uploading files

[Daniel Erez]

On Mon, Mar 25, 2019 at 9:42 PM Hetz Ben Hamo  wrote:
>
> Hi,
>
> Since both export and ISO domain are being deprecated, the only place to 
> upload remains the data domain.
>
> This method works, however, it doesn't "look" good. Uploading few ISO files 
> and you won't see any problem. Upload 50-70 files, and the "directory" looks 
> very messy.
>
> So, my question, will there be any "structure" then can be created, like 
> "folders" to put those uploaded files?

Having some sort of hierarchy for disks indeed sounds like a good idea.
For now, as an alternative, you can filter the disk by 'Content Type'
to display only ISO disks
(Disks tab -> Content Type -> ISO toggle button). Or, you can try
create bookmarks for
specific searches (e.g. by name, description, etc), and use it as an
organizing mechanism.

>
> Thanks
> Hetz
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/UO4X4WN4FPPV5HH4KEXW7AY2KQLXHRGE/
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/NWZCNG2UWF7F4LEZDXDAAL6UT5V6BHY7/

[ovirt-devel] Re: Proposing Nir as ovirt-site storage mainainer

[Daniel Erez]

+1. Well deserved :)

On Wed, Dec 5, 2018 at 12:23 PM Tal Nisan  wrote:

>
>
> On Tue, Dec 4, 2018 at 8:31 PM Nir Soffer  wrote:
>
>> Nir has done significant work on vdsm and ovirt-imageio, and working
>> recently
>> on incremental backup feature page:
>>
>> https://ovirt.org/develop/release-management/features/storage/incremental-backup
>>
>> For some reason he does not have merge right in ovirt-site project. I
>> think it is time
>> to fix this issue. If we can trust his code we can trust his
>> documentation.
>>
>> Thoughts?
>>
> Tal gives his +1 :)
>
>>
>> Nir
>>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/5SEZCKWXCBX7WRWWWJMO573K4FCHPAV5/

[ovirt-devel] Re: Hosts in Unassigned state after upgrading libvirt to 4.9

[Daniel Erez]

It has been changed as part of moving the data files into src/cpu_map:
https://github.com/libvirt/libvirt/commit/3ecbac95cd2a02ba5e2f98c625386ec12c8bbdac

So as a quick workaround, copying the old 'cpu_map.xml' file into
'/usr/share/libvirt' does the trick :)

On Tue, Nov 27, 2018 at 3:01 PM Milan Zamazal  wrote:

> Nir Soffer  writes:
>
> > On Mon, Nov 26, 2018 at 10:15 PM Nir Soffer  wrote:
> >
> >> I updated 2 Fedora 28 hosts today, getting new ovirt-master-release.rpm,
> >> which exposes new virt-preview repo providing libvirt 4.9 and qemu 3.1.
> >>
> >> After the update, connecting with engine master (built few week ago)
> fail
> >> with:
> >>
> >> 2018-11-26 22:07:51,702+02 WARN
> >>
> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand]
> >> (EE-ManagedThreadFactory-engineScheduled-Thread-94) [] Unexpected return
> >> value: Status [code=-32603, message=Internal JSON-RPC error: {'reason':
> >> "[Errno 2] No such file or directory:
> '/usr/share/libvirt/cpu_map.xml'"}]
> >>
> >> Looks like contents of /usr/share/libvirt/ is different now:
> >>
> >> $ ls -1 /usr/share/libvirt/cpu_map/*.xml | head
> >> /usr/share/libvirt/cpu_map/index.xml
> >> /usr/share/libvirt/cpu_map/ppc64_POWER6.xml
> >> /usr/share/libvirt/cpu_map/ppc64_POWER7.xml
> >> /usr/share/libvirt/cpu_map/ppc64_POWER8.xml
> >> /usr/share/libvirt/cpu_map/ppc64_POWER9.xml
> >> /usr/share/libvirt/cpu_map/ppc64_POWERPC_e5500.xml
> >> /usr/share/libvirt/cpu_map/ppc64_POWERPC_e6500.xml
> >> /usr/share/libvirt/cpu_map/ppc64_vendors.xml
> >> /usr/share/libvirt/cpu_map/x86_486.xml
> >> /usr/share/libvirt/cpu_map/x86_athlon.xml
> >>
> >
> > Looks like vdsm is not ready for this change:
>
> Hm, so libvirt changed from a file to a directory structure.  The
> corresponding Vdsm code is apparently virt, so it would be on me or
> Tomasz.  In order to fix it, it must be scheduled to some sprint.
>
> Adding Ryan.
>
> > $ git grep cpu_map.xml
> > lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml'
> > tests/Makefile.am:  cpu_map.xml \
> > tests/caps_test.py:'cpu_map.xml')
> > tests/cpu_map.xml:

[ovirt-devel] Re: Proposing Fred Rolland as a Storage backend maintainer

[Daniel Erez]

+1. Congrats :)

On Thu, Nov 15, 2018 at 5:34 PM Nir Soffer  wrote:

> +1
>
> My only concern Fred will spend even less time on vdsm now :-)
>
> On Thu, Nov 15, 2018 at 1:03 PM Tal Nisan  wrote:
>
>> Hi everyone,
>> I'd like to propose Fred as a backend maintainer in Engine for the
>> storage area.
>> Fred has been contributing to ovirt-engine for the last 3.5 years and
>> have done tremendous job in adding new features, bug fixes and code review.
>>
>> Thanks,
>> Tal.
>>
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/6GRTZVSB3PK4GMRYEA7RYOOZMSJWN5C3/
>>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2F6MZ65ODFH2KJGHCD3U6TWII3USPMUU/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/ROJ7BEHVDPX3G4LTAQEWVFZCCQT5IK2H/

[ovirt-devel] Re: Image Transfer mechanism queries/API support

[Daniel Erez]

On Tue, Jul 3, 2018 at 11:32 AM Ranjit DSouza 
wrote:

> Hello oVirt Development team
>
>
>
> We had a conversation with Pavan Chavva for supporting RHV. He had
> suggested to contact you with queries related to oVirt APIs we plan to use.
>
> We have following queries:
>
>
>
> 1.   While downloading a snapshot disk, can we identify allocated
> extents and download only those using oVirt API? We are able to download
> the disk using the Image Transfer API mechanism.
>
> However, this method downloads the entire disk including the non-allocated
> extents, which is a performance overhead. If this functionality does not
> exist at this point will it be available in near future?
>
>
>
> 2.   Is there an alternate method to transfer a snapshot to and from
> RHV storage? Are there other methods such as NFS share where we can
> download snapshot image to and from RHV storage?
>
>
>

Have you tried using the sdk for download/upload disk snapshots:
https://ovirt.org/develop/release-management/features/storage/backup-restore-disk-snapshots/


Thanks
>
> Ranjit
>
> Team EverestFalcons
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/VSI3A5LJNJRKNCBZDGWOUNIXRAIOIZ5W/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/RLHVDJ4NSVHKC4UDSW7ZHIKWMJ4PYOWE/

[ovirt-devel] Re: Uploaded ISO images

[Daniel Erez]

On Mon, May 14, 2018 at 2:21 PM Sandro Bonazzola 
wrote:

> 2018-05-14 11:03 GMT+02:00 Daniel Erez :
>
>>
>>
>> On Fri, May 11, 2018 at 12:06 PM Sandro Bonazzola 
>> wrote:
>>
>>> Hi,
>>> Just noticed that when I upload an ISO into a data domain from the
>>> browser, the content is detected as ISO but once upload finishes it's
>>> listed as Type:Image. Shouldn't it be Type:ISO?
>>>
>>
>> The type column in disks tab is the 'Disk Type' (i.e. image/lun/cinder).
>> You can filter by 'Content Type' using the buttons underneath the search
>> bar.
>>
>
> Can we add the filter at column selection? having to search around for
> finding the iso looks weird compared to sorting by lun/image/cinder
>

Sure. Can you please open an rfe on it?


>
>
>
>>
>>
>>>
>>> Software Version:4.2.3.5-1.el7.centos
>>> Thanks,
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>>
>>> Red Hat EMEA <https://www.redhat.com/>
>>>
>>> sbona...@redhat.com
>>> <https://red.ht/sig>
>>> <https://redhat.com/summit>
>>>
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://red.ht/sig>
> <https://redhat.com/summit>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[ovirt-devel] Re: Uploaded ISO images

[Daniel Erez]

On Fri, May 11, 2018 at 12:06 PM Sandro Bonazzola 
wrote:

> Hi,
> Just noticed that when I upload an ISO into a data domain from the
> browser, the content is detected as ISO but once upload finishes it's
> listed as Type:Image. Shouldn't it be Type:ISO?
>

The type column in disks tab is the 'Disk Type' (i.e. image/lun/cinder).
You can filter by 'Content Type' using the buttons underneath the search
bar.


>
> Software Version:4.2.3.5-1.el7.centos
> Thanks,
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> 
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [ovirt-devel] Problem when loading images via web interface

[Daniel Erez]

On Thu, Jan 25, 2018 at 1:29 PM Nir Soffer  wrote:

> The error shows that the host was not connected to the pool. Do we check
> that host is connected before trying to upload to the host?
>
Yes, we're filtering non active hosts.


>
> בתאריך יום ה׳, 25 בינו׳ 2018, 10:33, מאת Daniel Erez ‏:
>
>> On Wed, Jan 24, 2018 at 11:28 PM Dmitry Semenov  wrote:
>>
>>> 24.01.2018, 10:58, "Yaniv Kaul" :
>>> > On Tue, Jan 23, 2018 at 10:39 PM, Dmitry Semenov  wrote:
>>> >> While loading disk image (via the web interface) in cluster01 on
>>> storage01, storage02 - everything is going well.
>>> >> While loading disk image (via the web interface) in cluster02 on
>>> storage03, storage04 - the problem occurs, the image isn't loaded, the
>>> process stops at the stage: paused by System (at the same time loading
>>> straightly through API goes without problems).
>>> >>
>>> >> screenshot: https://yadi.sk/i/9WtkDlT23Riqxp
>>> >>
>>> >> Logs are applied (engine.log): https://pastebin.com/54k5j7hC
>>> >
>>> > Can you also share vdsm logs, at least from 01c04x09.unix.local ? It
>>> seems to have failed there.
>>> > Y.
>>>
>>> Here is a link to the vdsm.log file with 01c04x09.unix.local :
>>> https://pastebin.com/KiqYSYnP
>>
>>
>> According to the log [1], there was an error on prepareImage invocation.
>> Seems like the storage pool wasn't found in vdsm cache, though according
>> to the engine log[2]
>> it sends to correct pool id ('dedc6e8b-30e3-42d1-86f4-a130110f31b1').
>>
>> @Nir - what do you think? how could the pool be missing from the host?
>> cache/connection issue?
>>
>> [1]
>>
>> 2018-01-23 23:16:44,005+0300 INFO  (jsonrpc/5) [vdsm.api] START 
>> prepareImage(sdUUID=u'629ab576-638a-4c6f-b9c4-8d5cda64f9b2', 
>> spUUID=u'dedc6e8b-30e3-42d1-86f4-a130110f31b1', 
>> imgUUID=u'636c67ca-baec-4b32-be36-c3fb0ba24e83', 
>> leafUUID=u'f03fc310-7a09-4e23-a196-7dde70a1f616', allowIllegal=True) 
>> from=:::10.65.35.10,51672, flow_id=0c170481-1518-426a-90c9-9ad7be27b926, 
>> task_id=345c9223-4425-49c3-981a-5f6a7d2dbee0 (api:46)
>> 2018-01-23 23:16:44,006+0300 INFO  (jsonrpc/5) [vdsm.api] FINISH 
>> prepareImage error=Unknown pool id, pool not connected: 
>> (u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',) from=:::10.65.35.10,51672, 
>> flow_id=0c170481-1518-426a-90c9-9ad7be27b926, 
>> task_id=345c9223-4425-49c3-981a-5f6a7d2dbee0 (api:50)
>> 2018-01-23 23:16:44,006+0300 ERROR (jsonrpc/5) [storage.TaskManager.Task] 
>> (Task='345c9223-4425-49c3-981a-5f6a7d2dbee0') Unexpected error (task:875)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in 
>> _run
>> return fn(*args, **kargs)
>>   File "", line 2, in prepareImage
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in 
>> method
>> ret = func(*args, **kwargs)
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3151, in 
>> prepareImage
>> self.getPool(spUUID)
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 349, in 
>> getPool
>> raise se.StoragePoolUnknown(spUUID)
>> StoragePoolUnknown: Unknown pool id, pool not connected: 
>> (u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',)
>> 2018-01-23 23:16:44,006+0300 INFO  (jsonrpc/5) [storage.TaskManager.Task] 
>> (Task='345c9223-4425-49c3-981a-5f6a7d2dbee0') aborting: Task is aborted: 
>> "Unknown pool id, pool not connected: 
>> (u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',)" - code 309 (task:1181)
>> 2018-01-23 23:16:44,007+0300 ERROR (jsonrpc/5) [storage.Dispatcher] FINISH 
>> prepareImage error=Unknown pool id, pool not connected: 
>> (u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',) (dispatcher:82)
>> 2018-01-23 23:16:44,007+0300 INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer] RPC 
>> call Image.prepare failed (error 309) in 0.00 seconds (__init__:573)
>>
>> [2]
>> 2018-01-23 23:16:38,408+03 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] (default
>> task-38) [0c170481-1518-426a-90c9-9ad7be27b926] START,
>> CreateImageVDSCommand(
>> CreateImageVDSCommandParameters:{storagePoolId='dedc6e8b-30e3-42d1-86f4-a130110f31b1',
>> ignoreFailoverLimit='false',
>> storageDomainId=

Re: [ovirt-devel] Problem when loading images via web interface

[Daniel Erez]

On Wed, Jan 24, 2018 at 11:28 PM Dmitry Semenov  wrote:

> 24.01.2018, 10:58, "Yaniv Kaul" :
> > On Tue, Jan 23, 2018 at 10:39 PM, Dmitry Semenov  wrote:
> >> While loading disk image (via the web interface) in cluster01 on
> storage01, storage02 - everything is going well.
> >> While loading disk image (via the web interface) in cluster02 on
> storage03, storage04 - the problem occurs, the image isn't loaded, the
> process stops at the stage: paused by System (at the same time loading
> straightly through API goes without problems).
> >>
> >> screenshot: https://yadi.sk/i/9WtkDlT23Riqxp
> >>
> >> Logs are applied (engine.log): https://pastebin.com/54k5j7hC
> >
> > Can you also share vdsm logs, at least from 01c04x09.unix.local ? It
> seems to have failed there.
> > Y.
>
> Here is a link to the vdsm.log file with 01c04x09.unix.local :
> https://pastebin.com/KiqYSYnP


According to the log [1], there was an error on prepareImage invocation.
Seems like the storage pool wasn't found in vdsm cache, though according to
the engine log[2]
it sends to correct pool id ('dedc6e8b-30e3-42d1-86f4-a130110f31b1').

@Nir - what do you think? how could the pool be missing from the host?
cache/connection issue?

[1]

2018-01-23 23:16:44,005+0300 INFO  (jsonrpc/5) [vdsm.api] START
prepareImage(sdUUID=u'629ab576-638a-4c6f-b9c4-8d5cda64f9b2',
spUUID=u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',
imgUUID=u'636c67ca-baec-4b32-be36-c3fb0ba24e83',
leafUUID=u'f03fc310-7a09-4e23-a196-7dde70a1f616', allowIllegal=True)
from=:::10.65.35.10,51672,
flow_id=0c170481-1518-426a-90c9-9ad7be27b926,
task_id=345c9223-4425-49c3-981a-5f6a7d2dbee0 (api:46)
2018-01-23 23:16:44,006+0300 INFO  (jsonrpc/5) [vdsm.api] FINISH
prepareImage error=Unknown pool id, pool not connected:
(u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',)
from=:::10.65.35.10,51672,
flow_id=0c170481-1518-426a-90c9-9ad7be27b926,
task_id=345c9223-4425-49c3-981a-5f6a7d2dbee0 (api:50)
2018-01-23 23:16:44,006+0300 ERROR (jsonrpc/5)
[storage.TaskManager.Task]
(Task='345c9223-4425-49c3-981a-5f6a7d2dbee0') Unexpected error
(task:875)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line
882, in _run
return fn(*args, **kargs)
  File "", line 2, in prepareImage
  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in method
ret = func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line
3151, in prepareImage
self.getPool(spUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line
349, in getPool
raise se.StoragePoolUnknown(spUUID)
StoragePoolUnknown: Unknown pool id, pool not connected:
(u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',)
2018-01-23 23:16:44,006+0300 INFO  (jsonrpc/5)
[storage.TaskManager.Task]
(Task='345c9223-4425-49c3-981a-5f6a7d2dbee0') aborting: Task is
aborted: "Unknown pool id, pool not connected:
(u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',)" - code 309 (task:1181)
2018-01-23 23:16:44,007+0300 ERROR (jsonrpc/5) [storage.Dispatcher]
FINISH prepareImage error=Unknown pool id, pool not connected:
(u'dedc6e8b-30e3-42d1-86f4-a130110f31b1',) (dispatcher:82)
2018-01-23 23:16:44,007+0300 INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer]
RPC call Image.prepare failed (error 309) in 0.00 seconds
(__init__:573)

[2]
2018-01-23 23:16:38,408+03 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] (default
task-38) [0c170481-1518-426a-90c9-9ad7be27b926] START,
CreateImageVDSCommand(
CreateImageVDSCommandParameters:{storagePoolId='dedc6e8b-30e3-42d1-86f4-a130110f31b1',
ignoreFailoverLimit='false',
storageDomainId='629ab576-638a-4c6f-b9c4-8d5cda64f9b2',
imageGroupId='636c67ca-baec-4b32-be36-c3fb0ba24e83',
imageSizeInBytes='23622320128', volumeFormat='COW',
newImageId='f03fc310-7a09-4e23-a196-7dde70a1f616', imageType='Sparse',
newImageDescription='{"DiskAlias":"","DiskDescription":""}',
imageInitialSizeInBytes='1068367872'}), log id: 7666c2e4



>
> And that's what I noticed, the server 01c04x09.unix.local is in cluster01
> but I upload the image-file in to the storage02 (cluster02)
>
> >
> >> image size: ~1.3 GB
> >>
> >> my scheme:
> >>
> >> data_center_01
> >>   cluster01
> >> host01  \
> >> host02  - storage01, storage02
> >> host03  /
> >>
> >>   cluster02
> >> host04  \
> >> host05  - storage03, storage04
> >> host06  /
> >>
> >> HostedEngine in cluster01
> >> oVirt: Version 4.2.0.2-1.el7.centos
> >>
> >> --
> >> Best regards,
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
>
> --
> Best regards,
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] BZ#1375139 VM lost its disk after snapshot preview/commit

[Daniel Erez]

On Wed, Jan 18, 2017 at 10:59 AM, Yaniv Dary  wrote:

> Did we instruct to test these flow to reduce this risk?
> What are the relevant cases?
>

The main scenario we've addressed is removing any newer snapshots after
restoring an older one
(of course only in case that we don't use any disk from the newer
snapshots).
This is done to simplify the behavior and avoid confusing scenarios that we
don't support
(i.e. prevent previewing VM configuration of a newer snapshot after
restoring an older snapshot).


>
> Yaniv Dary
> Technical Product Manager
> Red Hat Israel Ltd.
> 34 Jerusalem Road
> Building A, 4th floor
> Ra'anana, Israel 4350109
>
> Tel : +972 (9) 7692306 <+972%209-769-2306>
> 8272306
> Email: yd...@redhat.com
> IRC : ydary
>
>
> On Wed, Jan 18, 2017 at 1:34 AM, Tal Nisan  wrote:
>
>> It's indeed an edge case and the fix suggested while in theory better
>> than the condition before it still is quite risky.
>> Take into consideration that the old mechanism while flawed in this
>> particular case worked flawlessly for a few versions now so we've decided
>> that replacing the existing mechanism for zstream as well is not a good
>> idea.
>>
>>
>> On Sun, Jan 15, 2017 at 4:55 PM, Yaniv Dary  wrote:
>>
>>> Can we consider a backport?
>>> How complex is the fix?
>>>
>>> Yaniv Dary
>>> Technical Product Manager
>>> Red Hat Israel Ltd.
>>> 34 Jerusalem Road
>>> Building A, 4th floor
>>> Ra'anana, Israel 4350109
>>>
>>> Tel : +972 (9) 7692306 <+972%209-769-2306>
>>> 8272306
>>> Email: yd...@redhat.com
>>> IRC : ydary
>>>
>>>
>>> On Mon, Jan 9, 2017 at 4:43 PM, Pavel Gashev  wrote:
>>>
 Yaniv,



 Yes, I’ve encountered it in 4.0.5.5. That’s why I started looking for
 existing bugs.



 Thank you so much



 *From: *Yaniv Dary 
 *Date: *Monday 9 January 2017 at 17:35
 *To: *Pavel Gashev 
 *Cc: *Vinzenz Feenstra , "devel@ovirt.org" <
 devel@ovirt.org>

 *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after
 snapshot preview/commit



 The flow seem to be a edge case.

 We can reconsider, have you encountered this issue?


 Yaniv Dary

 Technical Product Manager

 Red Hat Israel Ltd.

 34 Jerusalem Road

 Building A, 4th floor

 Ra'anana, Israel 4350109



 Tel : +972 (9) 7692306 <+972%209-769-2306>

 8272306

 Email: yd...@redhat.com

 IRC : ydary



 On Mon, Jan 9, 2017 at 4:25 PM, Pavel Gashev  wrote:

 It’s weird, isn’t it? That solution is not accepted, but the issue
 still does exist in 4.0.

 There are two bugs (BZ#1379131 and BZ#1375139), but both are switched
 to 4.1.

 Does it make sense to create another one?



 Note that the bugs have urgent priority. Users can corrupt their VMs
 via the User Portal.





 *From: *Vinzenz Feenstra 
 *Date: *Monday 9 January 2017 at 14:25
 *To: *Pavel Gashev 
 *Cc: *"devel@ovirt.org" 
 *Subject: *Re: [ovirt-devel] BZ#1375139 VM lost its disk after
 snapshot preview/commit





 On Jan 9, 2017, at 12:23 PM, Pavel Gashev  wrote:



 Hello,



 https://bugzilla.redhat.com/show_bug.cgi?id=1375139



 Could somebody confirm, that the issue is not going to be fixed in 4.0?



 It has not been merged to 4.0 branch, so I don’t assume so, the
 backport for 4.0 has been abandoned





 Thanks



 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel




 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel



>>>
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Lowering the bar for wiki contribution?

[Daniel Erez]

On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan  wrote:

> I'm getting the feeling I'm not alone in this, authoring and publishing a
> wiki page isn't as used to be for long time.
>
> I want to suggest a bit lighter workflow:
>
> 1.  Everyone can merge their page - (it's a wiki)
>   Same as with (public and open) code, no one has the motivation to
> publish a badly written
>   wiki page under their name. True, it can have an impact, but not as with
> broken code
>
> +1.
Moreover, I think we shouldn't block any merging. Instead, wiki maintainers
could act afterwards and revert when needed (Wikipedia style). Another
issue is that (sadly) unlike mediawiki, we need to wait for wiki publish
after a change. So I'd suggest to build and publish the wiki at least once
a day. Any way, I think we should make the workflow much more intuitive and
pleasant like the previous wiki - i.e. much less restrictive than
manipulating a code base.


> 2. Use Page-Status marker
>  The author first merges the draft. Its now out there and should be
> updated as time goes and its
>  status is DRAFT. Maintainers will come later and after review would
> change the status to
>  PUBLISH. That could be a header in on the page:
>  ---
>  page status: DRAFT/PUBLISH
>  ---
>
>  Simple I think, and should work.
>
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Interacting with VDSM storage without oVirt Engine

[Daniel Erez]

Hi Hayley,

Have you considered facilitate DRBD using Cinder?
We've integrated Cinder storage provider, with CEPH driver, as part of
oVirt 3.6.
So it could be easier to enhance it with DRBD driver:
https://www.drbd.org/en/doc/users-guide-90/s-openstack-install
http://docs.openstack.org/developer/cinder/api/cinder.volume.drivers.drbdmanagedrv.html


On Tue, May 31, 2016 at 10:30 PM, Hayley Swimelar  wrote:

>
>
> On 05/31/2016 12:15 PM, Yaniv Dary wrote:
>
>> Have you considered submitting a design document to the oVirt website.
>> We will be happy to help in making this happen.
>>
>
>
> I believe there is already one here:
> http://www.ovirt.org/develop/release-management/features/infra/drbd/
>
> I would be happy to update it as that was written for DRBD 8.4 and I'm
> working with DRBD 9.
>
>
>
>> On Tue, May 31, 2016 at 8:54 PM, Hayley Swimelar 
>> wrote:
>>
>>
>>>
>>> On 05/31/2016 10:40 AM, Nir Soffer wrote:
>>>
>>> On Tue, May 31, 2016 at 7:25 PM, Hayley Swimelar 
 wrote:


>
> On 05/31/2016 08:25 AM, Yaniv Dary wrote:
>
>
>> Can you explain the use case? What are you trying to use VDSM for?
>> The API you want to use is internal and can break without notice.
>>
>>
>
> Hi Yaniv,
>
> I'm working to to integrate DRBD storage into VDSM.
>
> It will be a new type of storage domain, so I can't use the GUI since
> the
> engine component won't be aware of it as far as I can tell.
>
> The current plan is to have another developer on our end make changes
> to
> the
> Engine once the VDSM side is working.
>
>
 Hi Hayley,

 Sounds cool, can you describe in more details the use case, and how do
 you think this
 can work?


 Hi Nir,
>>>
>>> The use case is to make replicated block level storage available in
>>> oVirt.
>>>
>>> VDSM should be able to communicate with DRBD via DRBD Manage, which is a
>>> new administrative layer for the latest release.
>>>
>>> Cheers,
>>>
 Nir


>>> --
>>> Hayley Swimelar
>>> LINBIT | Keeping the Digital World Running
>>> DRBD — Corosync — Pacemaker
>>> +1-503-573-1262 x212
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>
> --
> Hayley Swimelar
> LINBIT | Keeping the Digital World Running
> DRBD — Corosync — Pacemaker
> +1-503-573-1262 x212
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Coming (Very) Soon - New ovirt.org Website & Deprecated Wiki

[Daniel Erez]

- Original Message -
> From: "Mikey Ariel" 
> To: us...@ovirt.org, devel@ovirt.org, in...@ovirt.org
> Sent: Thursday, February 18, 2016 1:42:56 PM
> Subject: [ovirt-devel] Coming (Very) Soon - New ovirt.org Website &   
> Deprecated Wiki
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> In the past months we've been working on upgrading the oVirt project
> infrastructure, to better support the community contributions.
> 
> One of the main platforms for our user documentation, release
> management content, and community content has been the MediaWiki site
> that you all know as ovirt.org. Most of us are familiar with the wiki
> site format, with all its advantages and disadvantages.
> 
> After several years of serving the community, I'm happy to announce
> that we are very near to completing a full upgrade of the website
> infrastructure from a wiki site to a static site, source-controlled on
> GitHub and authored in Markdown.
> 
> This email is the pre-launch announcement, as we are reaching the
> final stages of the migration, and there are a few actions that might
> affect your work on website content in the meantime.
> 
> Why migrate the website
> ===
> 
> As mentioned, wiki sites provide an open and flexible content editing
> platform. Unfortunately, as the site grows the content becomes quite
> difficult to manage and curate, resulting in lots of obsolete,
> outdated, and incorrect information.
> 
> By moving to a source-controlled repository and implementing GitHub's
> contribution workflow, we strive to ease the work of maintaining an
> up-to-date content site, employ a peer-review process for changes, and
> standardize the authoring markup language to lower the contribution
> barrier.
> 
> The Middleman framework (Ruby-based static site generator) was chosen
> based on observing successful implementation of other open-source
> community websites, such as OpenStack RDO, Project Atomic, and Gluster.
> 
> What we did so far
> ==
> 
> When we started the migration, our Web design team exported all of the
> wiki content from the old website and converted it to MD files. They
> also set up the website config flow, auto-deploy, and upgraded the
> look-and-feel of the website.
> 
> We then initiated a content review effort as well as a UX review for
> the new website in a smaller forum, which caught most of the critical
> issues with the new website and helped us get the new format to a
> place where we can release the website in a near-GA/public-beta format.
> 
> Yesterday (Wednesday Feb 17) we exported the website one more time and
> currently we're running a diff on all the files that changed since the
> initial export was done, to make sure we grab all the updates and the
> latest content before we launch the new website.
> 
> What is about to happen
> ===
> 
> Today we are initiating a **wiki freeze**, which means the old
> MediaWiki site will become read-only. This is to ensure that all of

Where's the old MediaWiki site? (seems the old URL redirects to the new one).

> our diff scripts reflect the most current state of the content on the
> website, and that we don't lose any content in the transition.
> 
> Barring any unexpected blockers, we will port the ovirt.org domain to
> point to the new website and open the new website for contributions on
> **Monday February 22** or earlier.
> 
> What do you need to do right now
> 
> 
> If you have any wiki pages that you're actively editing, please don't
> save them to the old MediaWiki site, and hold onto your pending
> changes until we send the happy launch email.
> 
> We will also include instructions on how to contribute/edit/add
> content to the new website, but in general the workflow will be
> aligned with the standard GitHub best practices
> (clone-edit-commit-pullrequest), so you can utilize all of the git
> commands that you already know or work directly within the GitHub web
> editor.
> 
> 
> I'd like to thank all of the people who were involved with this
> migration so far, ovirt.org is a big website with lots of content and
> it was no small task to upgrade it.
> 
> Please feel free to ping me on- or off-list if you have any questions
> about the next steps, and expect a happy launch email soon!
> 
> Cheers,
> Mikey
> 
> 
> - --
> Mikey Ariel
> Community Lead, oVirt
> www.ovirt.org
> 
> "To be is to do" (Socrates)
> "To do is to be" (Jean-Paul Sartre)
> "Do be do be do" (Frank Sinatra)
> 
> Mobile: +420-702-131-141
> IRC: mariel / thatdocslady
> Twitter: @ThatDocsLady
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJWxa5AAAoJEHYPPTOszxHow10H/jeuhzMrUrPsCBedLg7OKnNh
> jdKDujT/aCyA4LgnRHnVBEASunShmVaOJrMdU4r0PZbdkX1Mf5/SvCEFGKY14qAg
> m/5CnDhlwbp5rqo09VOGLMg20CaMtpUoE1LpKE/epGYEKSBr2JIAA+HAsYa1OEyS
> 9oHDDx+ZIbfHNlygW1KpW6dsuZRscTbfy4kk8rY83YdJGyQiQN+ulsjT/c2N8ArR
> WylohBE2OcC7+nzf7AejKJ94loWxnVhO4qWbNWAH00LArG

Re: [ovirt-devel] Vdsm: extending maintainers team

[Daniel Erez]

- Original Message -
> From: "Dan Kenigsberg" 
> To: devel@ovirt.org
> Cc: pklic...@redhat.com
> Sent: Tuesday, August 4, 2015 11:58:53 AM
> Subject: [ovirt-devel] Vdsm: extending maintainers team
> 
> If you follow Vdsm development, you probably have noticed that we are
> short of active maintainers.
> 
> Thankfully, we have have great developers that - in my opinion - can
> fill that gap. I am impressed by the quality of their reviews, their
> endurance, and most importantly - their ability to unbreak whatever
> code they approve.
> 
> I'd like to nominate
> - Nir Soffer - for storage
> - Francesco Romani - for virt
> - Piotr Kliczewski - for infra
> 
> For the mean while, I would like to keep my own single point of merger
> (unless I'm away, of course).
> 
> Active and former maintainers: please approve

+1!

> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Live snapshot with ceph disks

[Daniel Erez]

- Original Message -
> From: "Nir Soffer" 
> To: "devel" 
> Cc: "Eric Blake" , "Daniel Erez" , 
> "Francesco Romani" ,
> "Adam Litke" , "Federico Simoncelli" 
> , "Yaniv Dary" 
> Sent: Friday, June 19, 2015 11:40:23 PM
> Subject: [VDSM] Live snapshot with ceph disks
> 
> Hi all,
> 
> For 3.6, we will not support live vm snapshot, but this is a must for the
> next
> release.
> 
> It is trivial to create a disk snapshot in ceph (using cinder apis). The
> snapshot
> is transparent to libvirt, qmeu and the guest os.
> 
> However, we want to create a consistent snapshot, so you can revert to the
> disk
> snapshot and get a consistent file system state.
> 
> We also want to create a complete vm snapshot, including all disks and vm
> memory.
> Libvirt and qemu provides that when given a new disk for the active layer,
> but
> when using ceph disk, we don't change the active layer - we continue to use
> the
> same disk.
> 
> Since 1.2.5, libvirt provides virDomainFSFreeze and virDomainFSThaw:
> https://libvirt.org/hvsupport.html
> 
> So here is possible flows (ignoring engine side stuff like locking vms and
> disks)
> 
> Disk snapshot
> -
> 
> 1. Engine invoke VM.freezeFileSystems
> 2. Vdsm invokes libvirt.virDomainFSFreeze
> 3. Engine creates snapshot via cinder
> 4. Engine invokes VM.thawFileSystems
> 5. Vdsm invokes livbirt.virDomainFSThaw
> 
> Vm snapshot
> ---
> 
> 1. Engine invoke VM.freezeFileSystems
> 2. Vdsm invokes libvirt.virDomainFSFreeze
> 3. Engine creates snapshot via cinder
> 4. Engine invokes VM.snapshot
> 5. Vdsm creates snapshot, skipping ceph disks
> 6. Engine invokes VM.thawFileSystems
> 7. Vdsm invokes livbirt.virDomainFSThaw
> 
> API changes
> ---
> 
> New verbs:
> - VM.freezeFileSystems - basically invokes virDomainFSFreeze
> - VM.thawFileSystems - basically invokes virDomainFSThaw
> 
> 
> What do you think?

OpenStack uses two different approaches for live snapshot:
1. When taking a snapshot of an instance, a new image (of the entire
   instance) is created on Glance in qcow2 format - orchestrated by
   Nova and libvirt (Snapshot xml).
2. When taking a snapshot of a single volume while the VM is running
   (i.e. the volume is attached to an instance), the snapshot is taken
   using Cinder with the relevant driver. The following message is displayed
   in Horizon: "This volume is currently attached to an instance.
   In some cases, creating a snapshot from an attached volume can result
   in a corrupted snapshot." (see attached screenshot)

Since the current integration is directly with Cinder and VM snapshot
is handled by oVirt engine, we should go with a variant of option 2...
If it's too late to integrate the new verbs into 3.6, maybe we could just
settle with a similar warning when creating a live snapshot? Or block
the feature for now to avoid possible data inconsistency?

> 
> Nir
> ___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] openstack-java-sdk - version 3.1.1 availability

[Daniel Erez]

Hi,

oVirt engine is now using openstack-java-sdk version 3.1.1 [1].
The new version RPM packages are available as part of the
'ovirt-master-snapshot-static' repository [2].
The new jars can be found at the maven central repository [3].

[1] https://gerrit.ovirt.org/#/c/38741/
[2] http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/fc20/noarch/
[3] http://central.maven.org/maven2/com/woorea/

Regards,
Daniel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Docker containers for ovirt-engine

[Daniel Erez]

Hi,

I've created a couple of Docker images with a running ovirt-engine service
and uploaded to the Docker registry [1].

Quite useful for quickly having a ready-to-use environment (tests, demos, etc)
or to be used as a base image for building new Docker Images.
Note that currently the container is not persistent by its nature,
hence for saving changes, take use of the 'commit' functionality [2].

[1] https://registry.hub.docker.com/u/danielerez/ovirt-engine/
[2] https://docs.docker.com/reference/commandline/cli/#commit
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] SortedListModel

[Daniel Erez]

- Original Message -
> From: "Alexander Wels" 
> To: devel@ovirt.org
> Sent: Thursday, May 29, 2014 4:05:13 PM
> Subject: [ovirt-devel] SortedListModel
> 
> Hi guys,
> 
> I have a question about the SortedListModel. If you look at the
> setItems(Collection value) method. You will notice that eventually all the
> items are added to a SortedSet. This is not a problem if all the elements of
> your collection are different. But what happens if the elements of your
> collection are not all different. More specifically if I pass in a comparator
> that matches on a field of the object that is not different like description,
> or
> size or something of that nature.
> 
> The set will reduce the number of elements. Before I change it to be a list
> that can have duplicates, I would like to know the origin of the set and if
> there are going to be any issues when I do that.

afaik, SortedListModel only maintains a list of business entities,
hence there isn't an issue with duplicate objects (as all displayed 
entities are unique). Are you trying to make use of SortedListModel
with a list of strings or something similar?

> 
> Thanks,
> Alexander
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel