November 2011 - Devel - oVirt List Archives

[Engine-devel] Stable PCI Addresses design wiki
by Eli Mesika 04 Dec '11

04 Dec '11

http://www.ovirt.org/wiki/Features/Design/StablePCIAddresses

9 19

[Engine-devel] Proposed next-generation vdsm API
by Adam Litke 03 Dec '11

03 Dec '11

Recently we've had some very productive discussions concerning the VDSM API. I want to attempt to refocus the discussion around an emerging proposal and see if we can agree on a sensible path forward. Based on the discussion, I have identified the following requirements that a new API for vdsm should have: 1.) Single API that can be consumed by ovirt-engine and ISVs - We don't want to maintain multiple parallel APIs - To develop a vendor ecosystem, we must have a robust external API to vdsm 2.) Full vdsm capabilities are exposed without requiring ovirt-engine - ovirt components should be modular and independently useful - Some deployments might want to manage nodes without ovirt-engine 3.) Standardized protocol with low overhead - Required for widespread adoption 4.) Support for asynchronous tasks and events - Needed by ovirt-engine and other consumers Based on these requirements, the following proposal has started to emerge: Create a REST API that will provide all of the functionality that is currently available via the xmlrpc interface (with the goal of deprecating xmlrpc once it becomes mature enough). To support advanced clustering features that ovirt-engine is planning, we'll write an QMF broker that can proxy the REST API onto a message bus. ovirt-engine will interact with vdsm exclusively over this bus but the REST API will be the principle API and the entry point for ISV apps. A REST API provides a light-weight and standard way to access all of the vdsm functionality. The REST API will handle events by exposing a new 'events' collection at the api root. REST users will use some sort of polling to collect these events. The details of this interface are being worked on. Several ways for minimizing the impact of polling have been discussed. The QMF broker can expose a publish/subscribe model for events as appropriate. Is this model an acceptable way to improve the vdsm API? I would like to hear the opinions of ovirt-engine developers, vdsm developers, and other stakeholders. Thanks for providing feedback on this proposal! -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

7 13

Re: [Engine-devel] Announcing a proof of concept REST API for VDSM
by Itamar Heim 30 Nov '11

30 Nov '11

On 11/29/2011 11:36 PM, Adam Litke wrote: > On Tue, Nov 29, 2011 at 12:54:44PM -0800, Chris Wright wrote: >> * Adam Litke (agl(a)us.ibm.com) wrote: >>> On Tue, Nov 29, 2011 at 11:39:08AM -0800, Chris Wright wrote: >>>> * Adam Litke (agl(a)us.ibm.com) wrote: >>>>> >>>>> https://github.com/aglitke/vdsm-rest/ >>>>> >>>>> Today I am releasing a proof of concept implementation of a REST API for vdsm. >>>>> You can find the code on github. My goal is to eventually replace the current >>>>> xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to >>>>> this new API. The major advantages to making this change are: 1) VDSM will gain >>>>> a structured API that conceptually, structurally, and functionally aligns with >>>>> the ovirt-engine REST API, 2) this new API can be made public, thus providing an >>>>> entry point for direct virtualization management@the node level. >>>> >>>> Adam, this looks like a nice PoC. I didn't see how API versioning is >>>> handled. Any VDSM developers willing to review this work? >>> >>> Thanks for taking a look. I am not handling versioning yet. I think we can add >>> a version field to the root API object. As for compatibility, we'll just have >>> to decide on an API backwards-compat support policy. Would this be enough to >>> handle versioning issues? We shouldn't need anything like capabilities because >>> the API is discoverable. >> >> Right, that seems sensible. >> >> Did you find cases where RPC to REST resource mapping was difficult? > > I haven't yet fully implemented the current vdsm API but I suspect that certain > calls (like the ones you mention below) will require some extensions to what I > have available currently. The main missing piece is probably events and a nice > polling API. Another big piece of work will be to rebase onto the newly > redesigned storage model. > >> I could see something like migrate() plus migrateStatus() and >> migrateCancel() needing to add some kind of operational state that to the >> resource. And something like monitorCommand() which has both a possible >> side-effect and some freefrom response... > > Hopefully monitorCommand will not be too bad, since vdsm should be asking > libvirt for the VM details when they are needed. Of course we'll need to be > testing to make sure we aren't keeping state around. Also, I would expect > monitorCommand to 'taint' the VM in the eyes of the vdsm API (as it does for > libvirt). > >>>> <snip> >>>>> ovirt-engine wants to subscribe to asynchronous events. REST APIs do not >>>>> typically support async events and instead rely on polling of resources. I am >>>>> investigating what options are available for supporting async events via REST. >>>> >>>> I think typical is either polling or long polling. If it's a single >>>> resource, then perhaps long polling would be fine (won't be a large >>>> number of connections tied up if it's only a single resource). >>> >>> Not sure if this is what you are referring to, but I was thinking we could do a >>> batch-polling mechanism where an API user passes in a list of task UUIDs and/or >>> event URIs. The server would respond with the status of these resources in one >>> response. I have some ideas on how we could wire up asynchronous events on the >>> server side to reduce the amount of actual work that such a batch-polling >>> operation would require. >> >> Oh, I just meant this: >> >> Polling (GET /event + 404 loop) >> Long polling (GET + block ... can chew up a thread connection) > > Yep. And we can talk later about building an API for efficient, repeated > polling. I wonder if the ovirt-engine guys could weigh in as to whether a REST cc-ing engine-devel... > interface with event polling would be acceptable to them. It is critical that > we settle on an API that can become _the_ first-class vehicle for interacting > with vdsm. > > Thanks! > i have two points for consideration around this: 1. as the api between ovirt-engine and vdsm, I had a preference for the bus like nature of QMF, as it would allow multiple ovirt-engine to load balance handling of messages from the queue, and multiple consumers for some messages (say, history service picking up the stats in parallel to engine picking them, rather than copying them from engine). 2. as node level api, i think a lightweight ovirt-engine managing a single node and exposing the exact same REST API and behavior of the multi-node ovirt engine would be easier to cosnume for someone that wants to interact with a single node same way they would interact with ovirt-engine.

7 19

[Engine-devel] Quota feature design
by Maor 30 Nov '11

30 Nov '11

Hi everyone, Following the introduction of Quota feature description, The following link is the design of Quota feature: http://www.ovirt.org/wiki/Features/Design/Quota Please feel free, to share your comments. Thank you, Maor

1 0

[Engine-devel] Requirement for Locking Mechanism
by Michael Kublin 29 Nov '11

29 Nov '11

Hi All, We are introducing a new short term locking mechanism at engine. The motivation is races which are occurring between different flows, the main problem is : we did not update status of some entity and other flow was started , which is a main cause for different collisions and situation which can not be fixed in appropriate way by engine or vdsm. The current status is a workaround which is trying to reduce a race : in many places in the code, there is additional query to DB in order to check the appropriate status of entity. The proposed solution is internal locking mechanism - which will lock an appropriate entity until its status will not be updated in DB, after that an internal short term lock will be released. The design for locking mechanism can be found here: http://www.ovirt.org/wiki/Features/DetailedLockMechanism The patch which is introduce an implementation for mechanism can be found here: http://gerrit.ovirt.org/#change,403 (Using of new mechanism all around a code and integration with bll will be sent in the future, including cleaning of workaround) Regards Michael

5 6

[Engine-devel] Feedback on ovirt-engine-sdk
by Geert Jansen 28 Nov '11

28 Nov '11

Hi Michael, i just wrote a small program with the new Python SDK. I found it very easy to use, so great work. I do have a few points of feedback: * Probably we want all Exceptions derived from a single base class. That way, the user can intercept any ovirtsdk with a single try/except clause. Currently that's not possible, as all your exceptions derive directly from Exception. * I think the .get() method should be id-based not name based. Using "id" as a primary key has a number of advantages over name: - It is immutable, which makes e.g. renaming a lot easier. - It allows you to retrieve an object without a search query or a filter. - It matches how the API works as well. Also currently i think it's not possible to retrieve a resource by its ID, unless you use the id= keyword argument to list() which retrieves the whole collection and then filters out the matching id. * You may want to introduce some non-entity related operations, like ping(), and connect(). These allow you to better control when you connect, and allow an program to test if the connection details work. That helps client except the right exceptions at the right time, and display more relevant error messages. * There's two Python objects involved for each API object. For a VM for example, you have params.VM and brokers.VM. This distinction is made visible to the user, for example: template = api.templates.get('Blank') vm = params.VM() vm.name = 'foo' vm.template = template # ERROR The last line need to be: vm.template = params.Template(id=template.id) In my version of the Python API i used mix-in classes to add the OO behavior to the generated classes. It was easy, because PyXB had support for that. This gave me the single class behavior. I am not sure if GenerateDS generated code allows that. I'm pretty sure it could be done though, but you may need to do some Python magic. * Nitpick: should this just be called "ovirt" instead of "ovirtsdk"? Overall great work though! Regards, Geert

3 4

[Engine-devel] timeout when starting a new VM
by Geert Jansen 27 Nov '11

27 Nov '11

Hi, i've got a setup with 1500 guests, of which about 800 are running now. Things start getting a little slow. I'm trying to start more guests via the ovirt-engine-sdk, but i get this error: File "/usr/bin/labmgr", line 171, in func_start vm.start(action) File "/usr/lib/python2.6/site-packages/ovirt_engine_sdk-1.0_SNAPSHOT-py2.6.egg/ovirtsdk/infrastructure/brokers.py", line 2389, in start body=ParseHelper.toXml(action)) File "/usr/lib/python2.6/site-packages/ovirt_engine_sdk-1.0_SNAPSHOT-py2.6.egg/ovirtsdk/infrastructure/proxy.py", line 42, in request conn=self.getConnectionsPool().getConnection()) File "/usr/lib/python2.6/site-packages/ovirt_engine_sdk-1.0_SNAPSHOT-py2.6.egg/ovirtsdk/infrastructure/proxy.py", line 54, in __doRequest raise ConnectionError, str(e) ovirtsdk.infrastructure.errors.ConnectionError: [ERROR]::oVirt API connection failure, The read operation timed out Any ideas? Regards, Geert

2 1

[Engine-devel] SDK: multi threading
by Geert Jansen 27 Nov '11

27 Nov '11

Hi Michael, two questions about threading..: - Is the SDK thread safe? - Can I make multiple concurrent requests to the API by using multiple threads, or do the threads block each other? Regards, Geert

2 1

[Engine-devel] SDK: multiple instances of API?
by Geert Jansen 27 Nov '11

27 Nov '11

Hi Michael, when i try to create multiple instances of the API object like this: from ovirtsdk.api import API url = 'xxx' username = 'admin@internal' password = 'yyy' a1 = API(url, username, password) a2 = API(url, username, password) I get this error: Traceback (most recent call last): File "test.py", line 8, in <module> a2 = API(url, username, password) File "/home/geertj/Source/ovirt-engine-sdk/src/ovirtsdk/api.py", line 47, in __init__ Mode.R) File "/home/geertj/Source/ovirt-engine-sdk/src/ovirtsdk/infrastructure/contextmanager.py", line 53, in add raise ImmutableError(key) ovirtsdk.infrastructure.errors.ImmutableError: [ERROR]::'proxy' is immutable. Any ideas? Thanks, Geert

2 1

Re: [Engine-devel] (no subject)
by Saggi Mizrahi 27 Nov '11

27 Nov '11

On Wed 16 Nov 2011 02:48:40 PM IST, Maor wrote: > Hello all, > > The Quota feature description is published under the following links: > http://www.ovirt.org/wiki/Features/DetailedQuota > http://www.ovirt.org/wiki/Features/Quota > Notice that screens of UI mockups should be updated. > > Please feel free, to share your comments about it. > > Thank you, > Maor > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel I can't see how the host is supposed to enforce and handle it. Pause the VM? Crash it? raise ENOMEM\ENOSPC in the guest? Also what about cases of KSM\QCow2, disk\memory overcommit. Disk Templates. Storage for hibernation disk. Temporary and shared disks. Shared disks between VMs owned by different users. Backup snapshots (should they count in the quota? They are transient) I also don't see how vcpu limiting is any good? I don't even know what it means. What happens in migration between hosts with different amount of physical CPUs? I also don't think CPU limiting is even a thing to be managed by a quota. There is no reason not to use 100% of the CPU if you are the only VM active. CPU scheduling should use a priority model and not a quota IMHO.

3 6

Re: [Engine-devel] [rhevm-api] Event notifications in RHEVM 3
by Itamar Heim 27 Nov '11

27 Nov '11

On 11/25/2011 02:48 PM, David Curylo wrote: > In our use case, we are trying to get real time notifications of events into our own application tier, so there would only be one or two of our application servers connected at a time. It need not be REST or HTTP - a persistent TCP connection will work just as well for us, the importance is that we are notified as quickly as possible. We have a similar need for real time notifications throughout our system and our architecture can be summarized as follows: > > Application server(s) --> AMQP topic exchange --> AMQP queue topic binding --> Web server(s) > > I will share more of our usage scenarios and a little about our architecture as it pertains to the discussion: > > When our application tier is notified of events, it performs other actions. For example, for Red Hat certification, we track the power off and power on events so we can provide a report of OS usage - polling every minute or so would work fine here. We also need to notify server monitoring systems that a system was powered off so they can stop monitoring rather than alerting of an outage - in this case, we need to be notified ASAP. Additionally, we need to notify any connected clients that a system has changed state (any event). Those clients are connected to web servers, which we notify by a message queuing infrastructure. All events are published to an AMQP topic exchange, to which web servers (and other systems) may subscribe based on their connected client's needs. The transport and scalability requirements no longer need to be handled by our application tier. > > The web servers, in the end, have to support a lot of client scenarios that include polling, long polling, sending HTTP requests, maintaining a TCP channel for streaming events, etc. We can easily scale up web servers, and we need to provide transports that are suitable for whatever our clients may need. > > I hope this helps explain our usage scenarios and suggest an additional technology to consider. (moving the discussion to the new upstream mailing list) do you care about all events, or specific ones? the event notifier is about sending registered events per user. maybe extend it to send the amqp events directly / extend the list of events it cares about? > > -----Original Message----- > From: Yaniv Kaul [mailto:ykaul@redhat.com] > Sent: Thursday, November 24, 2011 8:56 AM > To: Geert Jansen > Cc: Itamar Heim; rhevm-api(a)lists.fedorahosted.org; David Curylo > Subject: Re: [rhevm-api] Event notifications in RHEVM 3 > > On 11/24/2011 03:14 PM, Geert Jansen wrote: >> >> On 11/24/2011 01:18 PM, Itamar Heim wrote: >>> On 11/24/2011 01:37 PM, David Curylo wrote: >>>> I don't know the capabilities of this daemon. Can it do other notifications besides email, such as execute curl to send a request to my system? I would like to get notifications as close to real time as possible. >>> I think it's every 5 minutes right now, but can be configured (in 3.0). >> I don't believe though, that out notification service suits this use >> case. The use case is to get almost real-time notifications via an API >> when a change has been made. >> >> In my view, the best way to do this in HTTP/REST, is so-called long >> polling. It's not perfect, and not terribly scalable (i takes up one >> TCP connection, and in the simplest implementation, one app server slot). >> But on the other side, i do not see a need for 100s of clients polling >> a single RHEV systems. Typically, a customer may have 1-2 ISV packages >> on top of RHEV that need events. In my view, 10s of clients should be >> easily doable with long polling. > > - A single persistent TCP connection is "cheaper" to everyone than open-request-response-close-open-request-response-close .... > - This is widely used over HTTP with "100 continue" messages that never actually complete with a 200. It's neat and takes very little bandwidth, actually. > Y. > >> >> If we want to scale higher than this, probably a different >> architecture like e.g. a pub/sub architecture using a protocol >> optimized for binary messaging would make sense. But again, for now, i >> have not seen this need so for 3.1 i think we need to focus on the >> simplest solution that will satisfy 95% of the requirements. >> >> Regards, >> Geert >> _______________________________________________ >> rhevm-api mailing list >> rhevm-api(a)lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/rhevm-api >

1 0

[Engine-devel] Ovirt/VDSM installation Status
by Ronen Angluster 25 Nov '11

25 Nov '11

Hello, We successfully installed Ovirt-engine & VDSM (on the same host!) from the ovirt's repository. The Steps were as following: 1. add a repository to /etc/yum.repo.d (will be replaced by a RPM package containing all the needed information) 2. execute: "yum install -y ovirt-engine; yum install -y vdsm*" 3. disable NetworkManager and activating the network service 4. create a bridge interface named "engine" 5. change configuration in /etc/libvirt/qeum.conf /etc/libvirt/libvirtd.conf & /etc/vdsm/vdsm.conf 6. configure postgresql for first time installation 7. execute /usr/share/ovirt-engine/dbscripts/create_db_devel.sh 8. change vdc_options option 'EmulatedMachine' from 'rhel6.2.0' to 'pc-0.14' (known bug in ovirt-engine, patch already submitted) 9. start vdsm & jboss services After those steps were carried, we were able to: 1. add new data center, cluster & host 2. configure storage 3. create and run a new VM a wiki page containing all the necessary information will be delivered tomorrow. Ronen

5 5

[Engine-devel] Quota open issues following oVirt-engine-core meeting
by Maor 24 Nov '11

24 Nov '11

Hi all. Following the oVirt-engine-core meeting today, and the introduction of the Quota feature, a few open issues were discussed, and are described as follow: 1. Grace limit - We relinquish the grace limit property, since the threshold property should be good enough, for the alert functionality, the administrator needs. 2. Email notifications - The administrator will use the notification service for the Quota threshold event messages, to configure which users, will get notification email on Quota that exceeded the threshold. (We should consider using postponed notifications, to avoid flood). 3, Quota feature scope - Just to clarify, Quota is not designed from hardware point of view, but more from the billing POV. It will only be managed in the ovirt-engine scope. Regards, Maor Lipchuk

2 2

[Engine-devel] The ovirg-mange-domains tool makes super user by design?
by Juan Hernandez 24 Nov '11

24 Nov '11

Hello, I see that the "ovirt-manage-domains" tool updates the "users" and "permissions" table to make the user given in the "-user" option a super user. Is this by design? Shouldn't it just add the domain and leave the "permissions" and "users" table untouched? Thanks in advance, Juan Hernandez

2 1

[Engine-devel] REST for non-admin account
by Marc-André Lureau 23 Nov '11

23 Nov '11

Hi Is there any plan making part of the REST api accessible for non-admin accounts? How can I request and track such a feature? Is ovirt still using bugzilla.redhat.com for bugs? thanks -- Marc-André Lureau

2 1

[Engine-devel] First Nightly build of ovirt-engine & VDSM + Installation Guides
by Ronen Angluster 23 Nov '11

23 Nov '11

Hello, We've published 2 guides that describe how to install & configure ovirt-engine & VDSM from a nightly build placed on ovirt.org's repository. http://www.ovirt.org/wiki/Installing_ovirt_from_rpm http://www.ovirt.org/wiki/Installing_VDSM_from_rpm Please note the following: 1. At the time, nightly builds are not going to be carried out "nightly", we will publish new versions from time to time until we'll establish a mature and working release process 2. The installation process contains interim steps and will change as we mature the ovirt-engine product's deployment and may change significantly between revisions. Regards, Ronen Angluster

3 2

[Engine-devel] Fwd: [Openstack] FOSDEM 2012: Open source Virtualization and Cloud devroom: Call for speakers
by Alan Pevec 23 Nov '11

23 Nov '11

---------- Forwarded message ---------- From: Thierry Carrez <thierry(a)openstack.org> Date: Wed, Nov 23, 2011 at 2:48 PM Subject: [Openstack] FOSDEM 2012: Open source Virtualization and Cloud devroom: Call for speakers To: fosdem(a)lists.fosdem.org Cc: devrooms(a)fosdem.org, Lars Kurth <lars.kurth(a)xen.org>, "openstack(a)lists.launchpad.net" <openstack(a)lists.launchpad.net>, Renzo Davoli <renzo(a)cs.unibo.it> Hello everyone, The devroom named "Open Source Virtualization and Cloud" (OSVC2012) scheduled at FOSDEM on both days, February 4-5 2012, is a meeting opportunity for the developers of all the innovative open source projects around virtualization and cloud computing. OSVC2012 will include: * state-of-the-art presentations of virtualization/cloud projects * workshops to brainstorm and discuss new user requests, new developer ideas, and the possible synergies between projects All information about the devroom will be posted on the wiki at: http://osvc.v2.cs.unibo.it Relevant topics =============== All developers who want to present their ideas and software at OSVC2012 are welcome, provided that: * Their project is related to virtualization or cloud computing * They join the devroom as developers. Developers working for companies, public/private agencies or universities speak for themselves and not for their employer. OSVC2012 is about how to develop more effective virtualizing/cloud solutions (ideas and code, not marketing) * The code for their project must have been released under a free software or open source license (its license must meet the FSF definition of Free Software or the OSI definition of Open Source) Call for Presentations and Workshops ==================================== All submissions must be sent to osvc(a)cs.unibo.it and include the following information: * Type of submission: Presentation or Workshop * Desired length: "20min presentation + 5min Q&A", "45min presentation + 10min Q&A", or "no preference" * Title * Abstract / Description * Speaker / Moderator bio * Comments: scheduling constraints, remarks... * Links to the project (including its source code) * Related projects Dates: * Deadline for submission: December 18, 2011 * Notification of accepted submissions: January 5, 2012 -- Thierry Carrez Renzo Davoli Lars Kurth _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack(a)lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp

1 0

[Engine-devel] Pain Points: Adding NFS Storage
by Steve Gordon 22 Nov '11

22 Nov '11

Hi guys, By far the most common query that I have seen posed in the IRC channel since the workshop has been around how to successfully add an NFS storage domain. I know there are a host of reasons that this can fail (NFSv4 instead of NFSv3, path is not chown'd 36:36, firewall/server not reachable, bad export configuration) but it's still a pretty obvious pain point and it can be difficult to walk people through troubleshooting all of these possibilities on IRC. I haven't filed a bug around this (yet) but I thought it might be worth trying to come with some ideas for what, if anything, we can change code wise to make this easier for people (and more obvious exactly what is actually wrong when it doesn't work) and then maybe some bugs can be raised from that? I have also created the following page to attempt to collate the requirements for an NFS share to be used by oVirt and how to troubleshoot this issue, please feel free to contribute: http://www.ovirt.org/wiki/Troubleshooting_NFS_Storage_Issues Thanks, Steve

1 0

[Engine-devel] Fwd: Re: Classifying engine errors
by Michael Pasternak 21 Nov '11

21 Nov '11

-------- Original Message -------- Subject: Re: Classifying engine errors Date: Mon, 21 Nov 2011 09:32:10 -0500 (EST) From: Jon Choate <jchoate(a)redhat.com> To: Michael Pasternak <mpastern(a)redhat.com> ----- Original Message ----- > From: "Michael Pasternak" <mpastern(a)redhat.com> > Sent: Monday, November 21, 2011 9:10:46 AM > Subject: Classifying engine errors > > > Hi, > > i would like to suggest classifying engine errors (VdcBllMessages) > using these categories: > > 100-199. entity not found > 200-300. missing parameters > 300-399. no resources available > 400-499. can't perform - user error > 500-599. can't perform - server error > 600-699. Unauthorized > 700-x. Forbidden > > this way rest api will be able mapping them to HTTP errors > e.g any error returned by engine CAN_DO_ACTION 100 < x < 200 will be > converted > to HTTP 404 with CAN_DO_ACTION message detail > > - this can be easily done by assigning id to each VdcBllMessages > enum member in range of one of mentioned categories. > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > > Wouldn't it make more sense for this mapping to happen within the REST API since that is the component that cares about HTTP codes? The engine core should be agnostic to any particular client to ensure its flexibility and separation of concern. -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

[Engine-devel] Classifying engine errors
by Michael Pasternak 21 Nov '11

21 Nov '11

Hi, i would like to suggest classifying engine errors (VdcBllMessages) using these categories: 100-199. entity not found 200-300. missing parameters 300-399. no resources available 400-499. can't perform - user error 500-599. can't perform - server error 600-699. Unauthorized 700-x. Forbidden this way rest api will be able mapping them to HTTP errors e.g any error returned by engine CAN_DO_ACTION 100 < x < 200 will be converted to HTTP 404 with CAN_DO_ACTION message detail - this can be easily done by assigning id to each VdcBllMessages enum member in range of one of mentioned categories. -- Michael Pasternak RedHat, ENG-Virtualization R&D -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

[Engine-devel] engine-core bi-weekly agenda
by Livnat Peer 21 Nov '11

21 Nov '11

Hi All, Agenda for the core-engine meeting on Wednesday: * Building oVirt-engine * Maor Lipchuk will present the Quota feature. http://www.ovirt.org/wiki/Features/Quota http://www.ovirt.org/wiki/Features/DetailedQuota If you have more items you want to discuss please send to list and we'll add them to the agenda. Thank, Livnat

1 0

[Engine-devel] logging in engine
by Laszlo Hornyak 21 Nov '11

21 Nov '11

Hi, In oVirt's logging configuration we direct org.ovirt.* loggers to the engine log appender, org.ovirt.engine.ui to the ui's log and then the rest to the server log. The difficulties come when you start to do cross-component debugging. E.g. you see the logs of the engine in the engine log, but you would also like to see the logs of the components the engine is building upon: persistence API's (jdbc, hibernate) network communication components (e.g. httpclient, vdsm, ssh client), data processing API's (xml or json-parsers, apache commons apis) and all these logs go to the generic engine log. So when debugging you would have to merge these logs, otherwise you may miss some important details. I believe Moti's patch (http://gerrit.ovirt.org/#patch,sidebyside,257,3,backend/manager/conf/jboss-…) is one step in the another (I believe more useful) direction. But rather than specifying all the components that the engine uses, wouldn't it make sense to take just let all the logs flow into a single appender? What is your opinion? Thank you, Laszlo

3 6

[Engine-devel] Please run the upgrade script
by Yair Zaslavsky 20 Nov '11

20 Nov '11

Hi all, After you fetch and rebase, please run the db upgrade script located at ovrit_engine/backend/manager/dbscripts Kind regards, Yair

7 7

[Engine-devel] About mix storage domains
by wangbo 17 Nov '11

17 Nov '11

ÕâÊÇÒ»·â MIME žñÊœµÄ¶à²¿·ÖÓÊŒþ¡£ ------=_NextPart_000_01F2_01CCA491.8894D450 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi! =20 I want to know when will we can have a datacenter where we can mix = storage domains=A3=ACespecially we can add more than one host into a datacenter = with local storage domain. Thanks!! =20 ------=_NextPart_000_01F2_01CCA491.8894D450 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=3DZH-CN link=3Dblue vlink=3Dpurple = style=3D'text-justify-trim:punctuation'> <div class=3DSection1> Hi!<o:p></o:p> <o:p> </o:p> I want to know when will we can = have a datacenter where we can mix storage domains=A3=ACespecially we can add more than one host into a datacenter = with local storage domain.<o:p></o:p> Thanks!! =  <o:p></o:p> </div> </body> </html> ------=_NextPart_000_01F2_01CCA491.8894D450--

2 1

[Engine-devel] oVirt engine core
by Livnat Peer 17 Nov '11

17 Nov '11

--=_70458e0c-dd83-40d7-88a2-e6d5539f52fc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The following is a new meeting request: Subject: oVirt engine core Organizer: "Livnat Peer" <lpeer(a)redhat.com> Time: 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem Recurrence : Every 2 week(s) on Wednesday No end date Effective Nov 23, 2011 Invitees: engine-devel(a)ovirt.org *~*~*~*~*~*~*~*~*~* This is a bi-weekly call about oVirt engine core development issues upstream. You are welcome to join. Bridge ID: 1814335863 Dial-in information: Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 Reservationless-Plus International Dial-In Number: (212) 729-5016 Conference code: 1814335863 Global Access Numbers Local: Australia, Sydney Dial-In #: 0289852326 Austria, Vienna Dial-In #: 012534978196 Belgium, Brussels Dial-In #: 027920405 China Dial-In #: 4006205013 Denmark, Copenhagen Dial-In #: 32729215 Finland, Helsinki Dial-In #: 0923194436 France, Paris Dial-In #: 0170377140 Germany, Berlin Dial-In #: 030300190579 Ireland, Dublin Dial-In #: 014367793 Italy, Milan Dial-In #: 0236269529 Netherlands, Amsterdam Dial-In #: 0207975872 Norway, Oslo Dial-In #: 21033188 Singapore Dial-In #: 64840858 Spain, Barcelona Dial-In #: 935452328 Sweden, Stockholm Dial-In #: 0850513770 Switzerland, Geneva Dial-In #: 0225927881 United Kingdom Dial-In #: 02078970515 United Kingdom Dial-In #: 08445790676 United Kingdom, LocalCall Dial-In #: 08445790678 United States Dial-In #: 2127295016 Global Access Numbers Tollfree: Argentina Dial-In #: 8004441016 Australia Dial-In #: 1800337169 Austria Dial-In #: 0800005898 Bahamas Dial-In #: 18002054776 Bahrain Dial-In #: 80004377 Belgium Dial-In #: 080048325 Brazil Dial-In #: 08008921002 Bulgaria Dial-In #: 008001100236 Chile Dial-In #: 800370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #: 08000131048 Cyprus Dial-In #: 80095297 Czech Republic Dial-In #: 800700318 Denmark Dial-In #: 80887114 Dominican Republic Dial-In #: 18887512313 Estonia Dial-In #: 8000100232 Finland Dial-In #: 0800117116 France Dial-In #: 0805632867 Germany Dial-In #: 8006647541 Greece Dial-In #: 00800127562 Hong Kong Dial-In #: 800930349 Hungary Dial-In #: 0680016796 Iceland Dial-In #: 8008967 India Dial-In #: 0008006501533 Indonesia Dial-In #: 0018030179162 Ireland Dial-In #: 1800932401 Israel Dial-In #: 1809462557 Italy Dial-In #: 800985897 Jamaica Dial-In #: 18002050328 Japan Dial-In #: 0120934453 Korea (South) Dial-In #: 007986517393 Latvia Dial-In #: 80003339 Lithuania Dial-In #: 880030479 Luxembourg Dial-In #: 80026595 Malaysia Dial-In #: 1800814451 Mexico Dial-In #: 0018664590915 New Zealand Dial-In #: 0800888167 Norway Dial-In #: 80012994 Panama Dial-In #: 008002269184 Philippines Dial-In #: 180011100991 Poland Dial-In #: 008001210187 Portugal Dial-In #: 800814625 Russian Federation Dial-In #: 81080028341012 Saint Kitts and Nevis Dial-In #: 18002059252 Singapore Dial-In #: 8006162235 Slovak Republic Dial-In #: 0800001441 South Africa Dial-In #: 0800981148 Spain Dial-In #: 800300524 Sweden Dial-In #: 200896860 Switzerland Dial-In #: 800650077 Taiwan Dial-In #: 00801127141 Thailand Dial-In #: 001800656966 Trinidad and Tobago Dial-In #: 18002024615 United Arab Emirates Dial-In #: 8000650591 United Kingdom Dial-In #: 08006948057 United States Dial-In #: 8004518679 Uruguay Dial-In #: 00040190315 Venezuela Dial-In #: 08001627182 --=_70458e0c-dd83-40d7-88a2-e6d5539f52fc Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><h3>The following is a new meeting request:</h3> <table border=3D'0'> <tr><th align=3Dleft>Subject:</th><td>oVirt engine core </td></tr> <tr><th align=3Dleft>Organizer:</th><td>"Livnat Peer" <lpeer(a)redhat.com&= gt; </td></tr> </table> <table border=3D'0'> <tr><th align=3Dleft>Time:</th><td>4:00:00 PM - 5:00:00 PM GMT +02:00 Jerus= alem </td></tr><tr><th align=3Dleft>Recurrence</th><td>: Every 2 week(s) on Wed= nesday No end date Effective Nov 23, 2011</td></tr> </table> <table border=3D'0'> <tr><th align=3Dleft>Invitees:</th><td>engine-devel(a)ovirt.org </td></tr> </table> <div>*~*~*~*~*~*~*~*~*~*</div> This is a bi-weekly call about oVirt engi= ne core development issues upstream. You are welcome to join. Bri= dge ID: 1814335863 Dial-in information: Reservationless-Plus Toll= Free Dial-In Number (US & Canada): (800) 451-8679 Reservationless-P= lus International Dial-In Number: (212) 729-5016 Conference code: 181433= 5863 Global Access Numbers Local: Australia, Sydney Dial-In #: 02= 89852326 Austria, Vienna Dial-In #: 012534978196 Belgium, Brussels Di= al-In #: 027920405 China Dial-In #: 4006205013 Denmark, Copenhagen Di= al-In #: 32729215 Finland, Helsinki Dial-In #: 0923194436 France, Par= is Dial-In #: 0170377140 Germany, Berlin Dial-In #: 030300190579 Irel= and, Dublin Dial-In #: 014367793 Italy, Milan Dial-In #: 0236269529 N= etherlands, Amsterdam Dial-In #: 0207975872 Norway, Oslo Dial-In #: 2103= 3188 Singapore Dial-In #: 64840858 Spain, Barcelona Dial-In #: 935452= 328 Sweden, Stockholm Dial-In #: 0850513770 Switzerland, Geneva Dial-= In #: 0225927881 United Kingdom Dial-In #: 02078970515 United Kingdom= Dial-In #: 08445790676 United Kingdom, LocalCall Dial-In #: 08445790678= United States Dial-In #: 2127295016 Global Access Numbers To= llfree: Argentina Dial-In #: 8004441016 Australia Dial-In #: 18003371= 69 Austria Dial-In #: 0800005898 Bahamas Dial-In #: 18002054776 Ba= hrain Dial-In #: 80004377 Belgium Dial-In #: 080048325 Brazil Dial-In= #: 08008921002 Bulgaria Dial-In #: 008001100236 Chile Dial-In #: 800= 370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #: 0800013= 1048 Cyprus Dial-In #: 80095297 Czech Republic Dial-In #: 800700318<b= r>Denmark Dial-In #: 80887114 Dominican Republic Dial-In #: 18887512313<= br>Estonia Dial-In #: 8000100232 Finland Dial-In #: 0800117116 France= Dial-In #: 0805632867 Germany Dial-In #: 8006647541 Greece Dial-In #= : 00800127562 Hong Kong Dial-In #: 800930349 Hungary Dial-In #: 06800= 16796 Iceland Dial-In #: 8008967 India Dial-In #: 0008006501533 In= donesia Dial-In #: 0018030179162 Ireland Dial-In #: 1800932401 Israel= Dial-In #: 1809462557 Italy Dial-In #: 800985897 Jamaica Dial-In #: = 18002050328 Japan Dial-In #: 0120934453 Korea (South) Dial-In #: 0079= 86517393 Latvia Dial-In #: 80003339 Lithuania Dial-In #: 880030479<br= >Luxembourg Dial-In #: 80026595 Malaysia Dial-In #: 1800814451 Mexico= Dial-In #: 0018664590915 New Zealand Dial-In #: 0800888167 Norway Di= al-In #: 80012994 Panama Dial-In #: 008002269184 Philippines Dial-In = #: 180011100991 Poland Dial-In #: 008001210187 Portugal Dial-In #: 80= 0814625 Russian Federation Dial-In #: 81080028341012 Saint Kitts and = Nevis Dial-In #: 18002059252 Singapore Dial-In #: 8006162235 Slovak R= epublic Dial-In #: 0800001441 South Africa Dial-In #: 0800981148 Spai= n Dial-In #: 800300524 Sweden Dial-In #: 200896860 Switzerland Dial-I= n #: 800650077 Taiwan Dial-In #: 00801127141 Thailand Dial-In #: 0018= 00656966 Trinidad and Tobago Dial-In #: 18002024615 United Arab Emira= tes Dial-In #: 8000650591 United Kingdom Dial-In #: 08006948057 Unite= d States Dial-In #: 8004518679 Uruguay Dial-In #: 00040190315 Venezue= la Dial-In #: 08001627182</body></html> --=_70458e0c-dd83-40d7-88a2-e6d5539f52fc Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Asia/Jerusalem BEGIN:STANDARD DTSTART:19710101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0300 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=2SU TZNAME:IST END:STANDARD BEGIN:DAYLIGHT DTSTART:19710101T020000 TZOFFSETTO:+0300 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR TZNAME:IDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:f9f190e9-f568-4103-b8bc-f549b2d47ece RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=WE SUMMARY:oVirt engine core ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine- devel(a)ovirt.org ORGANIZER;CN=Livnat Peer:mailto:lpeer@redhat.com DTSTART;TZID="Asia/Jerusalem":20111123T160000 DTEND;TZID="Asia/Jerusalem":20111123T170000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20111117T070813Z DTSTAMP:20111117T070813Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: oVirt engine core \nOrganizer: "Livnat Peer" <lpeer(a)redhat.com> \n\nTime: 4:00:00 PM - 5 :00:00 PM GMT +02:00 Jerusalem\n Recurrence : Every 2 week(s) on Wednesday N o end date Effective Nov 23\, 2011\n\nInvitees: engine-devel(a)ovirt.org \n\n\ n*~*~*~*~*~*~*~*~*~*\n\nThis is a bi-weekly call about oVirt engine core dev elopment issues upstream.\nYou are welcome to join.\n\nBridge ID: 1814335863 \n\nDial-in information:\nReservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679\nReservationless-Plus International Dial-In Number : (212) 729-5016\nConference code: 1814335863\n\nGlobal Access Numbers Local :\nAustralia\, Sydney Dial-In #: 0289852326\nAustria\, Vienna Dial-In #: 012 534978196\nBelgium\, Brussels Dial-In #: 027920405\nChina Dial-In #: 4006205 013\nDenmark\, Copenhagen Dial-In #: 32729215\nFinland\, Helsinki Dial-In #: 0923194436\nFrance\, Paris Dial-In #: 0170377140\nGermany\, Berlin Dial-In #: 030300190579\nIreland\, Dublin Dial-In #: 014367793\nItaly\, Milan Dial-I n #: 0236269529\nNetherlands\, Amsterdam Dial-In #: 0207975872\nNorway\, Osl o Dial-In #: 21033188\nSingapore Dial-In #: 64840858\nSpain\, Barcelona Dial -In #: 935452328\nSweden\, Stockholm Dial-In #: 0850513770\nSwitzerland\, Ge neva Dial-In #: 0225927881\nUnited Kingdom Dial-In #: 02078970515\nUnited Ki ngdom Dial-In #: 08445790676\nUnited Kingdom\, LocalCall Dial-In #: 08445790 678\nUnited States Dial-In #: 2127295016\n\n\nGlobal Access Numbers Tollfree :\nArgentina Dial-In #: 8004441016\nAustralia Dial-In #: 1800337169\nAustria Dial-In #: 0800005898\nBahamas Dial-In #: 18002054776\nBahrain Dial-In #: 8 0004377\nBelgium Dial-In #: 080048325\nBrazil Dial-In #: 08008921002\nBulgar ia Dial-In #: 008001100236\nChile Dial-In #: 800370228\nColombia Dial-In #: 018009134033\nCosta Rica Dial-In #: 08000131048\nCyprus Dial-In #: 80095297\ nCzech Republic Dial-In #: 800700318\nDenmark Dial-In #: 80887114\nDominican Republic Dial-In #: 18887512313\nEstonia Dial-In #: 8000100232\nFinland Dia l-In #: 0800117116\nFrance Dial-In #: 0805632867\nGermany Dial-In #: 8006647 541\nGreece Dial-In #: 00800127562\nHong Kong Dial-In #: 800930349\nHungary Dial-In #: 0680016796\nIceland Dial-In #: 8008967\nIndia Dial-In #: 00080065 01533\nIndonesia Dial-In #: 0018030179162\nIreland Dial-In #: 1800932401\nIs rael Dial-In #: 1809462557\nItaly Dial-In #: 800985897\nJamaica Dial-In #: 1 8002050328\nJapan Dial-In #: 0120934453\nKorea (South) Dial-In #: 0079865173 93\nLatvia Dial-In #: 80003339\nLithuania Dial-In #: 880030479\nLuxembourg D ial-In #: 80026595\nMalaysia Dial-In #: 1800814451\nMexico Dial-In #: 001866 4590915\nNew Zealand Dial-In #: 0800888167\nNorway Dial-In #: 80012994\nPana ma Dial-In #: 008002269184\nPhilippines Dial-In #: 180011100991\nPoland Dial -In #: 008001210187\nPortugal Dial-In #: 800814625\nRussian Federation Dial- In #: 81080028341012\nSaint Kitts and Nevis Dial-In #: 18002059252\nSingapor e Dial-In #: 8006162235\nSlovak Republic Dial-In #: 0800001441\nSouth Africa Dial-In #: 0800981148\nSpain Dial-In #: 800300524\nSweden Dial-In #: 200896 860\nSwitzerland Dial-In #: 800650077\nTaiwan Dial-In #: 00801127141\nThaila nd Dial-In #: 001800656966\nTrinidad and Tobago Dial-In #: 18002024615\nUnit ed Arab Emirates Dial-In #: 8000650591\nUnited Kingdom Dial-In #: 0800694805 7\nUnited States Dial-In #: 8004518679\nUruguay Dial-In #: 00040190315\nVene zuela Dial-In #: 08001627182 X-ALT-DESC;FMTTYPE=text/html:<html><body><h3>The following is a new meeting request:</h3>\n\n\n<table border='0'>\n<tr><th align=left>Subject:</th><t d>oVirt engine core </td></tr>\n<tr><th align=left>Organizer:</th><td>"Livna t Peer" &lt\;lpeer(a)redhat.com&gt\; </td></tr>\n</table>\n\n<table border= '0'>\n<tr><th align=left>Time:</th><td>4:00:00 PM - 5:00:00 PM GMT +02:00 Je rusalem\n </td></tr><tr><th align=left>Recurrence</th><td>: Every 2 week(s) on Wednesday No end date Effective Nov 23\, 2011</td></tr>\n</table>\n\n< table border='0'>\n<tr><th align=left>Invitees:</th><td>engine-devel(a)ovirt.o rg </td></tr>\n</table>\n<div>*~*~*~*~*~*~*~*~*~*</div> This is a bi-week ly call about oVirt engine core development issues upstream. You are welc ome to join. Bridge ID: 1814335863 Dial-in information: Res ervationless-Plus Toll Free Dial-In Number (US &amp\; Canada): (800) 451-867 9 Reservationless-Plus International Dial-In Number: (212) 729-5016 Co nference code: 1814335863 Global Access Numbers Local: Australia\, Sydney Dial-In #: 0289852326 Austria\, Vienna Dial-In #: 012534978196 Belgium\, Brussels Dial-In #: 027920405 China Dial-In #: 4006205013 D enmark\, Copenhagen Dial-In #: 32729215 Finland\, Helsinki Dial-In #: 092 3194436 France\, Paris Dial-In #: 0170377140 Germany\, Berlin Dial-In #: 030300190579 Ireland\, Dublin Dial-In #: 014367793 Italy\, Milan Di al-In #: 0236269529 Netherlands\, Amsterdam Dial-In #: 0207975872 Norw ay\, Oslo Dial-In #: 21033188 Singapore Dial-In #: 64840858 Spain\, Ba rcelona Dial-In #: 935452328 Sweden\, Stockholm Dial-In #: 0850513770 Switzerland\, Geneva Dial-In #: 0225927881 United Kingdom Dial-In #: 0207 8970515 United Kingdom Dial-In #: 08445790676 United Kingdom\, LocalCa ll Dial-In #: 08445790678 United States Dial-In #: 2127295016 Global Access Numbers Tollfree: Argentina Dial-In #: 8004441016 Austra lia Dial-In #: 1800337169 Austria Dial-In #: 0800005898 Bahamas Dial-I n #: 18002054776 Bahrain Dial-In #: 80004377 Belgium Dial-In #: 080048 325 Brazil Dial-In #: 08008921002 Bulgaria Dial-In #: 008001100236 Chile Dial-In #: 800370228 Colombia Dial-In #: 018009134033 Costa Rica Dial-In #: 08000131048 Cyprus Dial-In #: 80095297 Czech Republic Dial -In #: 800700318 Denmark Dial-In #: 80887114 Dominican Republic Dial-I n #: 18887512313 Estonia Dial-In #: 8000100232 Finland Dial-In #: 0800 117116 France Dial-In #: 0805632867 Germany Dial-In #: 8006647541 G reece Dial-In #: 00800127562 Hong Kong Dial-In #: 800930349 Hungary Di al-In #: 0680016796 Iceland Dial-In #: 8008967 India Dial-In #: 000800 6501533 Indonesia Dial-In #: 0018030179162 Ireland Dial-In #: 18009324 01 Israel Dial-In #: 1809462557 Italy Dial-In #: 800985897 Jamaica Dial-In #: 18002050328 Japan Dial-In #: 0120934453 Korea (South) Dial- In #: 007986517393 Latvia Dial-In #: 80003339 Lithuania Dial-In #: 880 030479 Luxembourg Dial-In #: 80026595 Malaysia Dial-In #: 1800814451Mexico Dial-In #: 0018664590915 New Zealand Dial-In #: 0800888167 No rway Dial-In #: 80012994 Panama Dial-In #: 008002269184 Philippines Di al-In #: 180011100991 Poland Dial-In #: 008001210187 Portugal Dial-In #: 800814625 Russian Federation Dial-In #: 81080028341012 Saint Kitts and Nevis Dial-In #: 18002059252 Singapore Dial-In #: 8006162235 Slova k Republic Dial-In #: 0800001441 South Africa Dial-In #: 0800981148 Sp ain Dial-In #: 800300524 Sweden Dial-In #: 200896860 Switzerland Dial- In #: 800650077 Taiwan Dial-In #: 00801127141 Thailand Dial-In #: 0018 00656966 Trinidad and Tobago Dial-In #: 18002024615 United Arab Emirat es Dial-In #: 8000650591 United Kingdom Dial-In #: 08006948057 United States Dial-In #: 8004518679 Uruguay Dial-In #: 00040190315 Venezuela Dial-In #: 08001627182</body></html> BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --=_70458e0c-dd83-40d7-88a2-e6d5539f52fc--

1 0