Re: [Engine-devel] Application URI - saved anywhere?
- Original Message -
From: Ori Liel ol...@redhat.com
To: engine-devel engine-devel@ovirt.org
Sent: Wednesday, January 22, 2014 2:32:29 PM
Subject: [Engine-devel] Application URI - saved anywhere?
Hi,
RSDL lists the possible links that the user can activate in Rest-API. The URI
of A link looks something like this:
/ovirt-engine/api/vms/{vm:id}/start
My question is about the prefix: /ovirt-engine/api/. Until now RSDL was
generated at run-time, under a running application server, and this prefix
was received by querying for the base-uri of the current user's request. I'm
in the process of enabling RSDL generation at build time, and thus won't
have a request to get this URI from. I'm thinking to add this constant:
/ovirt-engine/api somewhere in pom.xml files, and use it. Does that sound
reasonable? (if not, why, and what do you think I should do instead?)
This entry already exists today in the ovirt-engine repo, in ear/pom.xml as the
contextRoot of the API webapp.
Would that be enough?
Thanks,
Ori.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] IMPORTANT: FindBugs threshold update
Hi all, Up until now the jenkins jobs on the gerrit patches included a findbugs job, that failed only in case of a warning of level NORMAL or higher. Now we update this threshold to fail on any findbugs warning, including LOW ones. Please make sure to rebase your current patches and check that the findbugs job finish successfully. It will probably fail without a rebase, as the last patches clearing the warnings were merged a few hours ago. Kodus to everyone involved in clearing all the LOW level warnings... mostly Allon and Alissa, but others helped as well! :-) Cheers, Oved ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Setting cluster CPU
- Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Sandro Bonazzola sbona...@redhat.com, Roy Golan rgo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, December 9, 2013 5:50:49 PM Subject: Re: [Engine-devel] Setting cluster CPU On Dec 9, 2013, at 16:01 , Sandro Bonazzola sbona...@redhat.com wrote: Hi, I'm trying to set the cluster CPU type while adding the first host to the Default cluster. I know how to set the CPU type on a new cluster, since I'll do that in AIO plugin. But I'm not sure to understand how to set the CPU on an existing cluster. Should it be enough to specify cpu arg while adding the host to the cluster? (before adding an host, cpu is None on the cluster) Because I'm trying to do that without success (obtaining a sandybridge cluster while specifying westmere cpu). The CPU should be set from the first host if None. That is needed for the PPC support. Roy, we talked about it recently, where are we with this patch. We already support modifying the CPU level of an existing cluster. If changing it to a higher level then we just change it. If changing it to a lower level, and there are running VMs on the cluster, then we warn the user that some VMs might not be migrate-able, as we added a scheduling filter to filter out hosts with improper CPU level. Unless I'm missing something, that covers the use-case, isn't it? Thanks, michal Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Setting cluster CPU
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: Michal Skrivanek michal.skriva...@redhat.com, Oved Ourfalli ov...@redhat.com, Roy Golan rgo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, December 10, 2013 9:12:14 AM Subject: Re: [Engine-devel] Setting cluster CPU Il 09/12/2013 19:37, Michal Skrivanek ha scritto: On 09 Dec 2013, at 18:58, Oved Ourfalli ov...@redhat.com wrote: - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Sandro Bonazzola sbona...@redhat.com, Roy Golan rgo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, December 9, 2013 5:50:49 PM Subject: Re: [Engine-devel] Setting cluster CPU On Dec 9, 2013, at 16:01 , Sandro Bonazzola sbona...@redhat.com wrote: Hi, I'm trying to set the cluster CPU type while adding the first host to the Default cluster. I know how to set the CPU type on a new cluster, since I'll do that in AIO plugin. But I'm not sure to understand how to set the CPU on an existing cluster. Should it be enough to specify cpu arg while adding the host to the cluster? (before adding an host, cpu is None on the cluster) Because I'm trying to do that without success (obtaining a sandybridge cluster while specifying westmere cpu). The CPU should be set from the first host if None. That is needed for the PPC support. Roy, we talked about it recently, where are we with this patch. We already support modifying the CPU level of an existing cluster. If changing it to a higher level then we just change it. If changing it to a lower level, and there are running VMs on the cluster, then we warn the user that some VMs might not be migrate-able, as we added a scheduling filter to filter out hosts with improper CPU level. Unless I'm missing something, that covers the use-case, isn't it? Not sure. I thought this is None to something, where it should work automatically without specifying anything. Just add an operational host Well, here the issue is that while deploying hosted-engine VM, I'm on a SandyBridge host, with 1 VM running on it (the hosted engine VM). That VM has been created with CPU model Westmere to be able to migrate it to other hosts Westmere compatible. But the Default cluster is automatically set to SandyBridge when I add the host also if I specify Westmere as CPU family in Host parameter. We may be able to set manually the CPU level later somehow, but since we've already asked the user about the CPU level I think we should avoid to ask the user to change it again later. See Bug 1034821 - Hosted-setup asks for CPU type but it doesn't set cluster to that CPU Level You can set the CPU level through the SDK, after you add the host (didn't check that, but see no reason it won't work). Thanks, michal Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Adding users and assigning roles in Ovirt
Your E-mail made me look a bit and check the different flows. I think the only use-case for adding users without giving any permissions is when you add a user for notification reasons. You can add a user, and then in the Event Notifier sub-tab define what events he will get via E-mail. afaik (and I'm not an event notifier expert), this user doesn't have to be able to login, or to have permissions of any kind. He just gets events. Other than that you're right. A user which is added to the system can't do much without assigning him roles. I think adding roles assignment to this dialog may be a bit cumbersome. Perhaps some wizard is required in that case. Or at least some checkbox saying allow user to login. That way the new user will be able to login, and he will have some default permissions as well (permissions granted to Everyone). Let's see what others think. Regards, Oved - Original Message - From: Ramesh rnach...@redhat.com To: engine-devel@ovirt.org Sent: Monday, December 2, 2013 7:22:53 AM Subject: [Engine-devel] Adding users and assigning roles in Ovirt Hi All, We have 'Add' action under 'Users' main tab to add users in Ovirt . It looks slightly different from the Add user option of the Configure option. Actually, this one is missing the Role to Assign option. I think without assigning any role, adding a user is not meaningful and it didn't complete the flow. Currently to assign any role to the user, either we have to use 'Configure' option ( to add system permission) or we have to go to the specific entity and add permission for that entity. It will be nice if we can assign roles( system level permissions) while adding users in 'Users' tab itself. It will be a clear user flow where one can add user and assign role in the same place. I have attached both the screen shots. please share your thoughts. Regards, Ramesh ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] What type of DB inheritance to use?
- Original Message - From: Itamar Heim ih...@redhat.com To: Mike Kolesnik mkole...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, May 12, 2013 5:05:52 PM Subject: Re: [Engine-devel] What type of DB inheritance to use? On 05/12/2013 04:31 PM, Mike Kolesnik wrote: - Original Message - On 05/12/2013 03:16 PM, Mike Kolesnik wrote: - Original Message - On 05/12/2013 12:42 PM, Mike Kolesnik wrote: Hi All, I would like to have your opinions on which inheritance type to use in the DB. We are adding an external provider entity to the system which will be able to provide various resources (networks, hosts, etc). These providers will be distinguishable by type. The basic definition of a provider contains: * name * description * url * type Some providers might need additional properties such as: * user * password what type of provider won't require authentication? Quantum provider in the 1st implementation will not require these fields. It will eventually require some sort of authentication, but not necessarily these fields, or only these fields. I'm not talking about a POC. unless we pass through credentials of users for some actions, how do you use a provider without user/password (or client cert, etc. - i.e., all authentication methods are usually similar on the info you need to persist)? I did not say that we will use Quantum without auth, only that these fields may or may not necessarily be in the Quantum provider entity. I think this is regardless of the main discussion here of inheritance, which I think will happen regardless of how Quantum provider is implemented. If you wish to discuss these details I'll be happy do it on a new thread, so that this one can stay focused on the subject of DB inheritance. how many discrepancies do we expect between the various providers, to be actually defined at provider level rather than consumption level? IMO, the following fields will fit most providers, at least the ones we plan to support in the near future: * id * name * type * URL * requires_authentication (boolean) to support development/POC/testing... mode * username * password In Java this is easily represented by inheritance. In the DB however, there are 3 approaches that we can take: 1. No inheritance. This means that each type will wit in his own table, with no relation or re-use. 2. Single table inheritance. All types sit in a single table, and each has his corresponding columns. 3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers). Pros for each approach: 1. None that I can think of. 2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse 3. Constraints can be set on each column Cons for each approach: 1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers 2. Can't put some constraints on non-base columns (esp. not null) 3. Joins are needed - opposite of the pros of 2. From personal experience, I find #2 to be better and easier to work with maintain. What are your thoughts? Regards, Mike ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Location of findbugs filter.xml file
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 4:55:46 PM Subject: [Engine-devel] Location of findbugs filter.xml file Hi all, I sent a patch upstream to add findbugs filter that will filter out bug reports that we decided that are not bugs. We have a debate on whether to have the findbugs filter definition in the root pom.xml or to put it in the jenkins jobs repo and treat it as an external tool. I would like to hear opinions about what you think should be the proper location Putting it in the root pom.xml file will allow running filtered findbugs using maven, without the need to use jenkins, so I'd go with that approach. Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to make REST API more webapp-friendly
- Original Message - From: Vojtech Szocs vsz...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, April 15, 2013 2:04:24 PM Subject: [Engine-devel] Proposal to make REST API more webapp-friendly Hi guys, having worked with Engine REST API from web application (JavaScript) perspective, there are things that could be improved to make REST API more webapp-friendly. First of all, webapps are *not* traditional HTTP clients, i.e. they have *not* full control over HTTP processing. There are some standard conventions and behaviors built into web browsers that any REST API implementation should be aware of. -- (1) Don't force clients to use cookies for transmitting authentication information! (or don't use cookies at all) Good explanation can be found at [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many disadvantages: * cookie parsing/formatting is not trivial -- extra complexity imposed on REST clients * in addition to Same-Origin Policy [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set *only* for the given path -- JavaScript running at [http://example.com/webapp] *cannot* get/set cookies from requests at [http://example.com/restapi] * cookies are the primary source of Cross-Site Request Forgery [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks -- malicious websites/scripts can forge requests to REST API that will include the cookie, compromising user session Alternative: clients could be given the *option* to use regular HTTP header for transmitting authentication information. For example, webapp could read such (sensitive information) header, store it securely via HTML5 Session Storage [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP processing on its own, e.g. pass this header for all authenticated requests (instead of pushing this responsibility to browser). Option #1: We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? If not, then we might be able to do option #2: Today, we keep the engine session ID on the HTTP session attributes. So, we can support either passing the cookie with the JSESSIONID (taking the engine session ID from the http session), or passing the engine session ID as HTTP header (assuming we would also return the engine session ID upon first REST request). This approach is problematic, as it might work well now, when the only attribute we use is the engine session ID, but in the future that might not be the case. If it is important enough (i.e., you can't really work with option #1) , then we can make a decision to save the attributes on the engine session, rather than on the HTTP session. So, we would start by supporting them both together, adding new attributes only to the engine session, and in the future deprecating the use of cookies, and only supporting HTTP headers. cc-ed Juan and Michael, as they might have some input on that. -- (2) Straight-forward HTTP Basic Auth has some drawbacks! HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] over (non-secure) HTTP connection means sending user credentials (username/password/domain) in easy-to-decode cleartext, i.e. the value is *not* encrypted or hashed in any way. Using secure lower-level protocol (SSL) fixes the consequence, rather than the root cause of the confidentiality issue. Furthermore, browsers typically remember HTTP Basic Auth information (either via browser-specific popup, or via XmlHttpRequest) until the browser window is closed. This means the webapp has no control over HTTP Basic Auth header after it has been set! This is the reason why it's hard to implement logout functionality in webapps when using HTTP Basic Auth. Last but not least, HTTP Basic Auth is vulnerable to Replay attacks [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and server can intercept requests and replay them, compromising user session. Alternative: clients could be given the *option* to use more advanced authentication scheme. I've just read an excellent article at [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] which describes easy yet secure authentication scheme inspired by Amazon Web Services REST API authentication [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. The idea is simple: collect auth information, hash (sign) it with a private key, and send everything to server. To guard against Replay attacks, just provide some timestamp to enforce request expiry after some time (say, 5-15 minutes). Easy and simple! -- (3) Support JSON for resource representations! I think
Re: [Engine-devel] Proposal to make REST API more webapp-friendly
- Original Message - From: Vojtech Szocs vsz...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Wednesday, April 17, 2013 1:25:06 PM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly Hi Oved, thanks for your feedback! We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? Right, currently REST API responds with JSESSIONID cookie + separate JSESSIONID response header, both carrying session ID value. As I wrote in my original email: JavaScript running at [http://example.com/webapp] *cannot* get/set cookies from requests at [http://example.com/restapi] So WebAdmin cannot get/set REST API JSESSIONID cookie directly, which is why it uses separate JSESSIONID response header in order to *read* the session ID value. As for sending JSESSIONID cookie, WebAdmin currently relies on standard cookie-handling implemented in browsers: all cookies for location X [http://example.com/restapi] will be part of any request to location X. So it's the browser who sets JSESSIONID cookie for REST API request, not WebAdmin. To answer your question, currently it's enough to work around the cookie access limitation, but it's not good enough in my opinion (from JavaScript/webapp perspective).. If not, then we might be able to do option #2: Today, we keep the engine session ID on the HTTP session attributes. So, we can support either passing the cookie with the JSESSIONID (taking the engine session ID from the http session), or passing the engine session ID as HTTP header (assuming we would also return the engine session ID upon first REST request). Well, the problem I described only relates to the way how JSESSIONID value is transmitted between client and server: currently using cookies, so REST API client has to do cookie handling. It would be really great if I could tell REST API to use plain (i.e. *not* Set-Cookie Cookie) HTTP header, for example JSESSIONID, for the purpose of transmitting session ID value between client and server. For example, the request to acquire session would be: GET /api HTTP/1.1 Host: www.example.org Prefer: use-jsessionid-header JSESSIONID: xxx [Feel free to replace use-jsessionid-header with anything you like. If client doesn't specify use-jsessionid-header, server expects Cookie header by default to preserve compatibility.] And the response would be: HTTP/1.1 200 OK JSESSIONID: xxx [If client didn't specify use-jsessionid-header, server would use Set-Cookie header by default to preserve compatibility.] This approach is problematic, as it might work well now, when the only attribute we use is the engine session ID, but in the future that might not be the case. If it is important enough (i.e., you can't really work with option #1) , then we can make a decision to save the attributes on the engine session, rather than on the HTTP session. So, we would start by supporting them both together, adding new attributes only to the engine session, and in the future deprecating the use of cookies, and only supporting HTTP headers. I think you can keep the current implementation, i.e. use REST API HttpSession to store Engine session ID value. The only difference would be, when REST API receives the request, it looks for Prefer:use-jsessionid-header, and if it's present, it uses JSESSIONID header value to look up HttpSession in some way (not sure about implementation details, though, but this should be possible to do). So, what do you think? As far as I saw, the handling of the cookie is done before the REST code, and that's why we need the cookie. Perhaps there is a way to make jboss take the JSESSIONID from the HTTP header, and not the cookie, but I didn't find a way to do that yet. Vojtech - Original Message - From: Oved Ourfalli ov...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Juan Hernandez jhern...@redhat.com, Michael Pasternak mpast...@redhat.com Sent: Wednesday, April 17, 2013 11:13:12 AM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly - Original Message - From: Vojtech Szocs vsz...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, April 15, 2013 2:04:24 PM Subject: [Engine-devel] Proposal to make REST API more webapp-friendly Hi guys, having worked with Engine REST API from web application (JavaScript) perspective, there are things that could be improved to make REST API more webapp-friendly. First of all, webapps are *not* traditional HTTP clients, i.e. they have
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
- Original Message - From: Wei D Chen wei.d.c...@intel.com To: Doron Fediuck dfedi...@redhat.com, Ofri Masad oma...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, April 15, 2013 8:54:18 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Doron and Ofri, Thanks for your reply, here is some other question. ii. When adding a host into the trusted cluster, the host will be attested via OAT service, only trusted hosted can be added. Would you also kindly tell me if there is any mandatory logic check when adding a host into a cluster, so we can also put attestation logic with these mandatory check together? Some example or code location is better. Thanks a lot. I think there are two approaches, depending on the use case. #1: If the host trusted property is static, then you can narrow the tests to two locations: * AddVdsCommand - (Vds = Host) - This command is triggered when a new host is added to the system. You can use the canDoAction method (which we have on all commands, and it determines whether an action can be run or not), and there, if cluster requires trusted hosts only, you can test whether this host is trusted or not. * ChangeVdsClusterCommand - this command is used when you change the cluster of a host. So, if the target cluster requires tursted hosts, you can do a similar test in its canDoAction method. #2: If the host trusted property can change, then I'd suggest using the NonOperational property of a host. We have a class called VdsUpdateRunTimeInfo that does periodic tests of hosts, deciding what's their status, according to specific flags. The code there is quite complex, and would require refactoring at some point, but in the meantime you can use the MonitoringStrategy interface that is being used there, and implement a new monitoring strategy for Open Attestation. There, in the processHardwareCapabilities, you can test that the host is trusted. When creating the strategy, using the MonitoringStrategyFactory, you'll need to create the appropriate strategy. Currently we support either virt strategy or gluster strategy or both. In your case you would need virt+attestation / gluster+attestation / virt+gluster+attestation, according to the services deployed on the cluster. Does that make sense? Doron and Ofri, what did you have in mind for this feature? Regards, Oved Best Regards, Dave Chen -Original Message- From: Doron Fediuck [mailto:dfedi...@redhat.com] Sent: Wednesday, April 10, 2013 8:03 PM To: Ofri Masad Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Ofri Masad oma...@redhat.com To: Gang Wei gang@intel.com Cc: Wei D Chen wei.d.c...@intel.com, Buddy Cao buddy@intel.com, Lijuan Zhang lijuan.zh...@intel.com, Doron Fediuck dfedi...@redhat.com Sent: Wednesday, April 10, 2013 2:23:57 PM Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi, answers inside the mail body. - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Gang Wei gang@intel.com, Buddy Cao buddy@intel.com, Lijuan Zhang lijuan.zh...@intel.com, Ofri Masad oma...@redhat.com Sent: Wednesday, April 10, 2013 12:12:26 PM Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Adding Ofri to answer your questions. - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Gang Wei gang@intel.com, Doron Fediuck dfedi...@redhat.com, Buddy Cao buddy@intel.com, Lijuan Zhang lijuan.zh...@intel.com Sent: Wednesday, April 10, 2013 6:31:05 AM Subject: RE: minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Doron, iii.Then periodic trust check will be added into background process for all existing hosts, once becoming non-trusted, mark it as non-operational. - [Dave] Would you give me some details about the “background process” mentioned in our sync up meeting? What’s the process and where is related code? The use Quartz Job to scheduled background processes. An example can be found in: ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: 222) This code calls a method that is located in: ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engin e/core/bll/quota/QuotaManager.java (Line: 1000) the @OnTimerMethodAnnotation annotation and the unique job name connects the two in runtime. The job can query the attestation server for all the host and then set untrusted hosts to Non-Operational. the best way would be to call
Re: [Engine-devel] Cloud-Init integration
- Laszlo Hornyak lhorn...@redhat.com wrote: Hi Greg, Cool feature :) Some questions: - Maybe the IP (and probably the hostname) should be enforced to be unique on the same network? Or at least warning if duplicates found? If we will persist it then we can warn for duplicated, but looks like cloud init is mainly used for one time initialization, so in that case we won't persist it, thus we won't have this information in the engine. - Let's say if the IP is set by cloud-init, then you may also have it in the guest agent info if the guest agent is installed. This may make life a bit more difficult for the developers who build on rest-api. Is there a nice solution for this? Can you elaborate on that? What would be hard on developers? - for authorized keys, it would be a pain to copy-paste the public key each time you install a guest. Could a default be stored let's say in the user's data? We might store those in the engine, allowing users to select one they have permissions on. Not sure we would do it in the first phase, though. - the hostname set for the guest could default to the VM name? That can indeed be nice. Thank you, Laszlo - Original Message - From: Greg Padgett gpadg...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Friday, March 29, 2013 12:35:23 AM Subject: [Engine-devel] Cloud-Init integration Hi Everyone, I'd like to propose a feature we've been doing some investigation into, which is to integrate cloud-init support into oVirt. Cloud-init is used to help provision new Linux systems by setting the hostname, ip, ssh keys, timezone, injecting files, and more. It's used by OpenStack (amongst others) now, and has a lot of features that may be helpful to our users. Details are still evolving, but for more info please see the wiki page: http://www.ovirt.org/Features/Cloud-Init_Integration All feedback is welcome! Thanks, Greg ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Rebasing a patch on an updated dependency
Hi Chris, how are you? You can do that using git commands, but the easiest way to rebase would be to go to the gerrit UI, and press the rebase change button. Then, you can verify it using the checkout command that gerrit would give you (the command appears above the rebase change button), in your git repository. btw, why is the patch it depends on not merged yet? do you need to verify them together before merging it? Because I saw it is acked, so if it is also verified then we can merge it. Hope I helped, Oved - Original Message - From: Christopher Morrissey christopher.morris...@netapp.com To: engine-devel@ovirt.org Sent: Wednesday, February 27, 2013 8:38:18 PM Subject: [Engine-devel] Rebasing a patch on an updated dependency Hi All, I have a patch, http://gerrit.ovirt.org/#/c/11783/, that is dependent on another unmerged patch and the dependent patch has been updated with a new patch set. I know I need to somehow rebase my patch on the updated dependent patch set, but I'm new to git and gerrit and have not been able to figure out the right combination of git commands to accomplish this. Any ideas on what steps I need to take? Thanks! -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from
- Original Message - From: Doron Fediuck dfedi...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from - Original Message - From: Michael Pasternak mpast...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 20, 2013 2:56:59 PM Subject: Re: [Engine-devel] REST API calls from On 02/14/2013 11:20 AM, Doron Fediuck wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is easy as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK pros - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC thoughts? [1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context? Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api-GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that. Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well. I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine. In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. I think we should probably do the same for engine plugins, giving the basic API, and giving a REST session for more advanced operations. The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, without creating a new layer of abstraction. I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the worst case, will interact directly with the API. On 02/12/2013 06:13 PM, Libor Spevak wrote: Hi, I would like to ask, if there have been discussions about an
Re: [Engine-devel] Changing Gerrit -1 message
- Original Message - From: Maor Lipchuk mlipc...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, February 21, 2013 12:25:57 AM Subject: Re: [Engine-devel] Changing Gerrit -1 message I tend to agree as well regarding the -1 message, although I think that since -2 blocks your change from, merging it, it should still be strict. Perhaps we could consider adding one more negative value? In my opinion, adding another negative value isn't so friendly... we should be more positive and not negative :-) I liked the -1: Please review my comments proposed below. I think the current -2: do not submit is pretty polite If you guys think it requires a change, then I'd change it to: -2: do not submit. Please review my comments. Oved Regards, Maor On 02/20/2013 11:59 AM, Antoni Segura Puimedon wrote: I like most of these proposals. It'll make gerrit friendlier :-) - Original Message - From: Itamar Heim ih...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, February 20, 2013 9:32:53 AM Subject: Re: [Engine-devel] Changing Gerrit -1 message On 19/02/2013 12:06, Laszlo Hornyak wrote: Hi, I agree with that. for the - messages this in my opinion would be both more clear and friendly: -1: In my opinion it needs work. how about -1: Please review my comments -2: I disagree. -2: Please reconsider - Original Message - From: Ofer Schreiber oschr...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, February 19, 2013 10:51:15 AM Subject: [Engine-devel] Changing Gerrit -1 message I feel that the current -1 I would prefer that you didn't submit this message in Gerrit is pretty rude, as usually those -1 reviews are just small fix-ups in the code itself. Any thoughts about a more suitable -1 message? I thought about -1 Please fix your code or something similar. Thanks, Ofer Schreiber ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Instance Types Feature
- Original Message - From: Tomas Jelinek tjeli...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, February 5, 2013 6:14:00 PM Subject: Re: [Engine-devel] Instance Types Feature 1. Why do we need a new set of permissions for Create Instance and Instance Owner? Aren't the VmCreator role and the UserVmManager role enough in these use-cases? so checked this with Andy: - Create Instance: it is a permission to actually see the instance types in the list of instance types when creating the VM and to be able to create a VM from that instance type Wouldn't we want the instance types to be public, limiting the user on resources according to his Quota? What worries me is that you currently need VmCreator role on a DC in order to be able to create VMs there, add disks, and etc. So, now you would also need to have a CreateInstance permission. And, in addition, you also need the right Quota. Why not simplifying things, saying all instance types are public, and you only need VmCreator role, and the Quota for your new resources? - Instance Owner: if the user has this permission, he can edit the fields marked as Basic User in the table in the wiki (but not the others) - Original Message - From: Oved Ourfalli ov...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, January 29, 2013 2:54:13 PM Subject: Re: [Engine-devel] Instance Types Feature Some questions: 1. Why do we need a new set of permissions for Create Instance and Instance Owner? Aren't the VmCreator role and the UserVmManager role enough in these use-cases? 2. iiuc, the internal implementation of instance types and images will be done using templates. However, I guess we plan to expose instance types and images as REST resources, right? Thank you, Oved - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, January 22, 2013 3:09:51 PM Subject: [Engine-devel] Instance Types Feature Hi All, this is the proposed new feature called instance types: http://www.ovirt.org/Features/Instance_Types Long story short - it should basically split the VM template into: - hardware profile called instance types - software profile called image This should enable to do something like: Create a new small VM and attach a disk with RHEL + Postgres installed. Any comments are more than welcome! Tomas ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Instance Types Feature
Some questions: 1. Why do we need a new set of permissions for Create Instance and Instance Owner? Aren't the VmCreator role and the UserVmManager role enough in these use-cases? 2. iiuc, the internal implementation of instance types and images will be done using templates. However, I guess we plan to expose instance types and images as REST resources, right? Thank you, Oved - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, January 22, 2013 3:09:51 PM Subject: [Engine-devel] Instance Types Feature Hi All, this is the proposed new feature called instance types: http://www.ovirt.org/Features/Instance_Types Long story short - it should basically split the VM template into: - hardware profile called instance types - software profile called image This should enable to do something like: Create a new small VM and attach a disk with RHEL + Postgres installed. Any comments are more than welcome! Tomas ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Problem in ovirt-reports sso
See comments/questions inline. Oved - Original Message - From: ly pan ply...@gmail.com To: engine-devel@ovirt.org Sent: Thursday, January 3, 2013 5:23:32 AM Subject: [Engine-devel] Problem in ovirt-reports sso Hello, I have a reports problem which has got me for many days now. The reports sso feature is not functioning in my invironment. I followed the steps from the wiki page: http://www.ovirt.org/How_to_setup_a_oVirt_Reports_development_environment http://www.ovirt.org/Features/Design/Reports_Dashboard and the patch related to sso: http://gerrit.ovirt.org/#change,3355 here is my steps: 1. install jasperreports 4.7.0 using the bundled tomcat and the existing DB 2. modify the db password in ovirt.xml 3. import the reports using js-import.sh 4. add the EngineSimplePreAuthFilter in applicationContext-security-web.xml Can you share that file with us? (obviously remove sensitive data from it, such as keystore password). 5. add Reports.xml to the wenadmin folder and change RedirectServletReportsPage in db 6. generate a keystore using keytool and update EngineSimplePreAuthFilter in applicationContext-security-web.xml You're supposed to create a trust store, that trusts the certificate of the oVirt engine. Did you do that? 7. install the ovirt-dwh rpm package made from source and run ovirt-engine-dwh-setup 8. start the ovirt-engine service and the tomcat And all the projects, ovirt-dwh, ovirt-reports, ovirt-engine, is build from the latest source. When I browse to the dashboard in webadmin portal,it just shows a jasper login page, so the sso is not functioning, right? Can you please attach the jboss logs? (engine.log and server.log). I can login and browse jasper reports in a browser page normally. So I try to login in dashboard using reports user, tomcat gives me a Exception: java.lang.IllegalArgumentException: An id is required to lookup a FlowDefinition Not sure if that error is related or not, but hopefully the logs will point us to the problem. What might be the problem? Am I missing anything? Any help would be appriciated, thanks. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Problem in ovirt-reports sso
Hey,
First of all, you forgot to add the EngineSimplePreAuthFilter to the filter
chain (you just added the bean).
See http://gerrit.ovirt.org/#/c/3355/:
* Adding the EngineSimplePreAuthFilter filter to the filter chain for /**:
/**=httpSessionContextIntegrationFilter,multipartRequestWrapperFilter,webAppSecurityFilter,jsCsrfGuardFilter,${bean.loggingFilter},${bean.userPreferencesFilter},${bean.authenticationProcessingFilter},${bean.userPreferencesFilter},${bean.basicProcessingFilter},EngineSimplePreAuthFilter,requestParameterAuthenticationFilter,JIAuthenticationSynchronizer,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,switchUserProcessingFilter,iPadSupportFilter
You basically defined the pre authentication filter, but it wasn't used in your
filter chain.
As for http / https for the jasper server, not sure they should be equal (i.e.,
both http or both https). I think it should work well even if one is secured
while the other isn't.
First try to add the the Filter to the filter chain, and let's see what happens.
Also, you can set the following options in the EngineSimplePreAuthFilter bean
in case of ssl issues (in case you want to skip validation just to see that it
works, without the need to troubleshoot exactly what's the problem):
sslIgnoreCertErrors
sslIgnoreHostVerification
You set them by adding the lines
property name=sslIgnoreCertErrors value=true/
property name=sslIgnoreHostVerification value=true/
to the bean definition (in addition to all the other options you used):
So, in your resulting file you should have:
/**=httpSessionContextIntegrationFilter,multipartRequestWrapperFilter,webAppSecurityFilter,jsCsrfGuardFilter,${bean.loggingFilter},${bean.userPreferencesFilter},${bean.authenticationProcessingFilter},${bean.userPreferencesFilter},${bean.basicProcessingFilter},EngineSimplePreAuthFilter,requestParameterAuthenticationFilter,JIAuthenticationSynchronizer,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,switchUserProcessingFilter,iPadSupportFilter
and also have (if you choose to change the ssl definitions to be more
permissive):
bean id=EngineSimplePreAuthFilter
class=org.ovirt.authentication.EngineSimplePreAuthFilter
property name=authenticationManager
ref bean=authenticationManager/ref
/property
property name=servletURL
value=http://localhost/OvirtEngineWeb/ValidateSession;/property
property name=pollingTimeout value=60/property
property name=trustStorePath
value=/etc/pki/ovirt-engine/.truststore/property
property name=trustStorePassword value=/property
property name=sslIgnoreCertErrors value=true/
property name=sslIgnoreHostVerification value=true/
/bean
Also, try looking out for the jasper server log in case of problems.
btw, does the report server work well for you when working with it not through
the webadmin? Make sure it does before you bother to troubleshoot the SSO.
Hope it helps,
Oved
- Original Message -
From: ly pan ply...@gmail.com
To: Oved Ourfalli ov...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Thursday, January 3, 2013 5:43:25 PM
Subject: Re: [Engine-devel] Problem in ovirt-reports sso
Thanks for the help, Oved
I want to add some info:
1. my environment is fc17, my browser is firefox.
2. I access admin portal using https (rpm has done that for me) while
my jasper configuration is http
in db's RedirectServletReportsPage and
applicationContext-security-web.xml, every time I browse to
dashboard the browser prompt me with the message about
unencrypted
connection in encrypted page.
Should I use https for jasper as well?
If this is the case, what configuration shoud be added?
Thanks!
ly pan
2013/1/3 Oved Ourfalli ov...@redhat.com:
See comments/questions inline.
Oved
- Original Message -
From: ly pan ply...@gmail.com
To: engine-devel@ovirt.org
Sent: Thursday, January 3, 2013 5:23:32 AM
Subject: [Engine-devel] Problem in ovirt-reports sso
Hello, I have a reports problem which has got me for many days
now.
The reports sso feature is not functioning in my invironment.
I followed the steps from the wiki page:
http://www.ovirt.org/How_to_setup_a_oVirt_Reports_development_environment
http://www.ovirt.org/Features/Design/Reports_Dashboard
and the patch related to sso:
http://gerrit.ovirt.org/#change,3355
here is my steps:
1. install jasperreports 4.7.0 using the bundled tomcat and the
existing DB
2. modify the db password in ovirt.xml
3. import the reports using js-import.sh
4. add the EngineSimplePreAuthFilter in
applicationContext-security-web.xml
Can you share that file with us? (obviously remove sensitive data
from it, such as keystore password).
Of course, see the attached files.
5. add Reports.xml to the wenadmin folder and change
RedirectServletReportsPage
Re: [Engine-devel] Engine local configuration
- Original Message -
From: Doron Fediuck dfedi...@redhat.com
To: Juan Hernandez jhern...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Tuesday, January 1, 2013 12:41:27 PM
Subject: Re: [Engine-devel] Engine local configuration
- Original Message -
From: Juan Hernandez jhern...@redhat.com
To: Doron Fediuck dfedi...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Tuesday, January 1, 2013 12:17:33 PM
Subject: Re: [Engine-devel] Engine local configuration
On 01/01/2013 10:51 AM, Alon Bar-Lev wrote:
- Original Message -
From: Doron Fediuck dfedi...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Juan Hernandez jhern...@redhat.com,
engine-devel@ovirt.org
Sent: Tuesday, January 1, 2013 10:30:29 AM
Subject: Re: [Engine-devel] Engine local configuration
All we are saying is DEVELOPMENT=1 is the default, since the
code
is built differently for production, and installed
accordingly.
Additionally you may have more than one devel setup, for
example
for
different versions. So unless you override something (such as
keystore
pass, jboss location) mvn -Pdep should simply work, and make
XXX
will
ensure whatever you need to override is done properly.
No, you miss the point.
I want to be able to have a full blown product installed for
development as well.
The only difference is the PREFIX and may be some other stuff I
don't
think of that are specific of development.
I put the DEVELOPMENT=1 to focus the discussion.
I should have written the following steps to be more clear:
$ OEHOME=$HOME/ovirt-engine-root
$ make PREFIX=$OEHOME
$ make PREFIX=$OEHOME DEVELOPMENT=1 install
$ cd ${OEHOME}
$ . ./ovirt-engine.vars
$ engine-setup
snip
$ sbin/engie-service.py start
We probably need more vars on the make install, such as
JBOSS_HOME,
but the idea is that you have fully functional product in
development mode, including PKI and support scripts.
Regards,
Alon
Alon,
most universities today will not give you admin privileges.
We must be able to download the code and run it without
additional
requirements. It is possible to run jboss with local
configuration
(per user). So we should minimize the restrictions and not
impose
new once. Running the installation script is nice to have, but
should be completely optional. Especially if you'd like to see
it
being deployed in various distro's. So at least developers
should
be able to git clone, compile and run. Everything else is
packaging.
You don't need any admin to install at
PREFIX=$HOME/ovirt-engine-root
We should make sure that we can run all components within PREFIX
without root.
As far as I can tell, we do not actually need root access for 99%
of the implementation, one of the trivial differences is to
replace systemctl start/stop with direct script execution in
non-root mode.
Alon
As I mentioned on my first response to this thread I have been
working
on trying to make the build system able to install the engine to a
directory chosen by the developer, and without root permissions.
This
is
the patch that I prepared for that, please take a look at the
commit
message:
http://gerrit.ovirt.org/10539
The idea is that the developer can chose a directory and then just
run
the following:
./make.py --build --install --devel --target /that/directory
Even the complexity of this command line can be hidden in a make
target,
or made the default, so the developer will only need to run
something
like this:
make install
This will prepare an environment similar to the production
environment,
with the same directory structure (except the /that/directory
prefix)
where the engine can run, so to start it the developer only needs
to
go
to that directory and execute the same script that we use in
production
environments:
cd /that/directory/usr/bin
./engine-service start
This will also automatically configure the engine for remote
debugging
(adding ENGINE_DEBUG_ADDRESS=0.0.0.0:8787 to the configuration) so
that
the developer can connect to the engine with her/his favorite IDE
and
start debugging immediately.
The make.py script also includes options to create Eclipse project
files
and to configure the Eclipse workspace, which I think is very
useful,
specially for new developers:
./make.py --eclipse-projects
That creates the .project and .classpath files for Eclipse and adds
the
required variables to the workspace, so after that all what the
developer has to do to start working is open Eclipse and import the
projects.
The patch is not yet ready to merge, as there are a few missing
things,
like changing the ownership of files when running as root, but I
would
appreciate if you
[Engine-devel] oVirt-Foreman UI plugin
Hey all, I've been working on an oVirt-Foreman UI-plugin recently, using oVirt's new UI-plugin infrastructure. It allows users to see Foreman data on oVirt entities, from inside Webadmin. I wrote a blog post describing this plugin, what can he do, some challenges that I faced and solutions, some screenshots, future work and more. Check it out at: ovedou.blogpost.com I'll be happy to hear your feedback both on the blog and on the plugin itself! If you need help installing the plugin feel free to contact me :-) Cheers, Oved ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] oVirt-Foreman UI plugin
All links below work for me, from several devices. Is it still broken for someone? - Itamar Heim ih...@redhat.com wrote: On 12/20/2012 06:35 PM, Oved Ourfalli wrote: Hey all, I've been working on an oVirt-Foreman UI-plugin recently, using oVirt's new UI-plugin infrastructure. It allows users to see Foreman data on oVirt entities, from inside Webadmin. I wrote a blog post describing this plugin, what can he do, some challenges that I faced and solutions, some screenshots, future work and more. Check it out at: ovedou.blogpost.com link is broken... http://ovedou.blogspot.co.il/ http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html I'll be happy to hear your feedback both on the blog and on the plugin itself! If you need help installing the plugin feel free to contact me :-) Cheers, Oved ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Users] oVirt-Foreman UI plugin
- Christopher Morrissey christopher.morris...@netapp.com wrote: The issue was blogpost.com vs. blogspot.com. Thank you for pointing it out. So the correct link is: http://ovedou.blogspot.com and there you will see the new post. (both links Itamar wrote below will work as well). Sorry for the inconvenience, Oved -Chris -Original Message- From: engine-devel-boun...@ovirt.org [mailto:engine-devel- boun...@ovirt.org] On Behalf Of Oved Ourfalli Sent: Thursday, December 20, 2012 12:52 PM To: Itamar Heim Cc: Ohad Levy; engine-devel; us...@ovirt.org; Joseph Magen Subject: Re: [Engine-devel] [Users] oVirt-Foreman UI plugin All links below work for me, from several devices. Is it still broken for someone? - Itamar Heim ih...@redhat.com wrote: On 12/20/2012 06:35 PM, Oved Ourfalli wrote: Hey all, I've been working on an oVirt-Foreman UI-plugin recently, using oVirt's new UI-plugin infrastructure. It allows users to see Foreman data on oVirt entities, from inside Webadmin. I wrote a blog post describing this plugin, what can he do, some challenges that I faced and solutions, some screenshots, future work and more. Check it out at: ovedou.blogpost.com link is broken... http://ovedou.blogspot.co.il/ http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html I'll be happy to hear your feedback both on the blog and on the plugin itself! If you need help installing the plugin feel free to contact me :-) Cheers, Oved ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] UI plugins - next steps
Nice work!
See some comments inline.
- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: engine-devel engine-devel@ovirt.org
Sent: Wednesday, December 12, 2012 2:57:11 PM
Subject: [Engine-devel] UI plugins - next steps
Hi guys,
here's my list of tasks that didn't make it into UI plugins yet.
These tasks should be revisited and implemented in future patches.
The list isn't sorted in any way, so feel free to comment or
highlight specific tasks to raise their priority, or add your own
tasks/ideas.
1. Pass proper (restapi-definition) entities to UI plugins, instead
of simple {entityId:guidAsString} objects
- using restapi-types mappers to map backend business entities to
restapi-definition entities (Java POJOs generated from api.xsd
via JAXB)
- exporting restapi-definition entities for use with JavaScript
(UI plugins), e.g. using gwt-exporter [1] (alternatively, we
could use GWT deferred binding and do this ourselves)
2. showDialog API function should integrate with WebAdmin dialog
infrastructure
- shouldn't be too hard, need to create custom dialog
PresenterWidget/View and bind it as non-singleton (just like
other popups in oVirt GUI)
3. Extend existing WebAdmin dialogs - prototype Doron's proposal to
extend Edit Cluster Policy dialog with custom options that would be
passed to backend
4. Introduce form-based tabs - custom tab that would display
key/value pairs organized in columns, just like in standard
General sub tabs
5. Introduce table-based tabs - custom tab that would display grid
(table) just like in standard main tabs, with API to add columns,
set data, etc.
6. Improve api.addMainTabActionButton to allow different button vs.
context menu item representations (only button, only menu item,
both)
7. Add api.currentUserName and api.currentUserId API functions (these
would return same data as with UserLogin event parameters)
Pushing this now.
http://gerrit.ovirt.org/#/c/9998/
8. Minor things: consider renaming UiInit to PluginInit (one-time
plugin initialization, called only once, can do non-UI init stuff
there as well), consider renaming api.ready to api.initialize
(plugin indicates that infrastructure can proceed with initializing
itself)
I think we should also consider adding an option to add a button in a more
general scope, for things that aren't entity-specific, but system-specific.
Maybe next to the configure button, in the upper right corner of the screen?
Regards,
Vojtech
[1] http://code.google.com/p/gwt-exporter/wiki/GettingStarted
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Trusted Compute Pools
- Original Message - From: Gang Wei gang@intel.com To: Itamar Heim ih...@redhat.com Cc: engine-devel@ovirt.org, James Rankin jran...@redhat.com, Oved Ourfalli oourf...@redhat.com, Barak Azulay bazu...@redhat.com, Michal Skrivanek mskri...@redhat.com, Buddy Cao buddy@intel.com, Jeff Ruby jeff.r...@intel.com, Gang Wei gang@intel.com Sent: Tuesday, December 11, 2012 1:35:59 PM Subject: RE: [Engine-devel] Trusted Compute Pools Itamar Heim wrote on 2012-11-30: for a POC patch i suggest: 1. use vm custom level property as simpler for first phase then changing the db scheme. 2. use bare minimum engine config support for service location/authentication. A dummy question: where is the engine config file? The engine configuration is in the database, in the vdc_options table. You can edit it manually. In an installed environment we also have the engine-config utility, which allows to modify existing configuration entries. Oved Jimmy 3. assume no plugins and just add the code to the relevant part in RunVM which filters the relevant hosts: ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] network subnet
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Livnat Peer lp...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, August 30, 2012 11:11:30 PM Subject: Re: [Engine-devel] network subnet - Original Message - From: Livnat Peer lp...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, August 30, 2012 10:16:05 PM Subject: Re: [Engine-devel] network subnet On 30/08/12 21:39, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, August 30, 2012 3:22:29 PM Subject: [Engine-devel] network subnet Hi All, Today when a user wants to define a network subnet mask, he does it when he attaches the network to a host NIC. I was wondering if there is a reason not to define the network subnet on the logical network entity (Data center level). Thanks, Livnat Hello, I am sorry, maybe I do not understand... the IP scheme enforces the use of address mask in order to properly route packets. of course. My proposal is related to our user usage of the system. Today ovirt user, who wants to define a network subnet, has to type the subnet per host (per network), I think the user should only define it once on the logical network entity in the Data Center. Propagating the value to all hosts is needed but it should be our internal implementation detail. I guess that would be solved by using host-network profiles/templates. The user will define it once, and apply each host with the relevant profile. Hope we will get to that sometime in the near future. It will surely save a lot of time and effort when trying to set up new environments. Network mask is used in any case, I guess it can be dropped from configuration in favour of using the address class as mask, is that what you suggest? No, hope the above paragraph made it more clear. Hello, Then you assume that a logical network, which is actually layer 2 network in our implementation, has layer 3 characteristics, right? In our current implementation data center logical network is pure layer 2 segment aka layer 2 broadcast domain. One can use the same logical network for multiple layer 3 segments, which is totally valid and consistent with standard physical layer 2 setup. Unless I am missing something crucial, I would suggest to keep the consistent physical-virtual mapping, unless we emulate layer 3 switching. Layer 2 does not have layer 3 characteristics. Regards, Alon. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] VM migration state in after_vm_destroy hook
Not a hook expert, but I looked at the code, and besides after_vm_destroy we also have: before_vm_migrate_source after_vm_migrate_source before_vm_migrate_destination after_vm_migrate_destination So, I guess you can put the relevant code in the after_vm_migrate_source for the migration use-case, and after_vm_destroy for the destroy use-case. Oved - Original Message - From: Irena Berezovsky ire...@mellanox.com To: engine-devel@ovirt.org Sent: Sunday, September 2, 2012 3:33:38 PM Subject: [Engine-devel] VM migration state in after_vm_destroy hook Hi, Is there any way to know in context of VDSM ‘after_vm_destroy’ hook if VM is terminated (globally in the cluster) or migrated to other Host? Is there some Environment parameter or other indication? Thanks a lot, Irena ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to add Alona Kaplan as maintainers to webadmin
- Original Message - From: Einav Cohen eco...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Asaf Shakarchi ashak...@redhat.com, engine-devel@ovirt.org Sent: Sunday, August 12, 2012 8:47:25 AM Subject: Re: [Engine-devel] Proposal to add Alona Kaplan as maintainers to webadmin - Original Message - From: Livnat Peer lp...@redhat.com Sent: Sunday, August 12, 2012 8:23:00 AM On 12/08/12 01:20, Itamar Heim wrote: Alona has worked on oVirt for the past 9 months, developing several features in the webadmin (including localization and integrated dashboards) and also a slew of bugs... I'd like to propose Alona as a maintainer of the webadmin In the past 3 months Alona was focused on the new setup network dialog and she did a great Job, we started with a dialog that de-facto was not working and ended up with one of the more attractive dialogs in the webadmin. +1 +1 +1 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Confusing Attach Disk checkbox in Add Virtual Disk dialog
- Original Message - From: Roy Golan rgo...@redhat.com To: engine-devel@ovirt.org Sent: Sunday, July 29, 2012 7:11:23 PM Subject: [Engine-devel] Confusing Attach Disk checkbox in Add Virtual Disk dialog Hi all, I find the new Attach Disk checkbox very confusing. It doesn't feel like a feature of the dialog but some kind of a disk property laid in the wrong place. Totally agree it is confusing, and that it seems misplaced. There is a radio button in this dialog, for internal/external disk. I'd add another one for attach disk. Thinking of it, (Roy - perhaps I'm saying what you said, but in my own words), it would be nice if the dialog has three different tabs (instead of radio buttons) for these options (add internal disk/add external disk/attach existing disk). I'd expect toggling between two ways of adding disk using tabs or inner menu. even simple inner add | attach feels more friendly. Is that an early sketch waiting to be changed? - Roy ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Ovirt on Fedora17
Hey, You should really send such question to engine-devel, as someone might have encountered such an issue, so there might be a solution for that. Can you also attach the vdsm.log file (in the host, under the directory /var/log/vdsm/vdsm.log). Thank you, Oved - Original Message - From: ov...@qip.ru To: Oved Ourfalli ov...@redhat.com Sent: Wednesday, June 6, 2012 5:55:44 PM Subject: Re: Re: Ovirt on Fedora17 I use rpms from http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms /lastSuccessfulBuild/artifact/output/*zip*/output.zip and another problem that not solved is that VM don't start with attached CD if only I attach CD to VM I got libvirt error ( i use only needed pachages from fedora17 repo except ovirt-engine and vdsm ) in webadmin error VM VM01-Fedora17 is down. Exit message: internal error unsupported configuration: Readonly leases are not supported in VM01-Fedora17.log red_worker_main: begin display_channel_create: create display channel cursor_channel_create: create cursor channel Domain id=2 is tainted: custom- mon itor qemu: terminat ing on signal 15 from pid 606 2012-06-06 14:39:15.167+: shutt ing down 2012-06-06 14:39:37.381+: start ing up LC_ALL=C PATH=/ usr /local/sbin:/ usr /local/bin:/ usr /sbin:/ usr /bin QEMU _AUDIO_ DRV =none / usr /bin/qemu- kvm -S -M pc -0.14 - cpu kvm 64,+ lahf _lm,+ ssse 3,- cx 16 -enable- kvm -m 1024 - smp 1,sockets=1,cores=1,threads=1 -name VM01-Fedora17 - uuid e0a70093-5b11-472f-b452-d1ae815028f4 - smbios type=1,manufacturer=Red Hat,product= RHEV Hyperv iso r ,version=17-1,serial=49434D53-0200-9066-2500-66902500FE53_00:25:90:66:53:fe, uuid =e0a70093-5b11-472f-b452-d1ae815028f4 -nodefconfig - nodefaults - chardev socket,id= char mon itor ,path=/var/lib/ libvirt /qemu/VM01-Fedora17. mon itor,server, nowait - mon chardev = char mon itor ,id= mon itor,mode=control - rtc base=2012-06-06T14:39:37, driftfix =slew -no-shutdown -device piix 3- usb - uhci ,id= usb ,bus= pc i.0, addr =0x1.0x2 -device virtio -serial- pc i,id= virtio -serial0,bus= pc i.0, addr =0x4 -drive file=/ rhev /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/d2221 cee -7146-4197- aecf -0 dfad 32b54ea/images/----/Fedora-17-x86_64- netinst . iso ,if=none,media= cdrom ,id=drive- ide 0-1-0, readonly =on,format=raw,serial= -device ide -drive,bus= ide .1,unit=0,drive=drive- ide 0-1-0,id= ide 0-1-0 -drive file=/ rhev /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/e5485577-8f51-4213- acd 8-f38e064cf308/images/9865260a-7480-4cd2-8352-9f44ee2d6c37/00ed2438-6768-4c94-8215-8a678d4d0d50,if=none,id=drive- virtio -disk0,format= qcow 2,serial=9865260a-7480-4cd2-8352-9f44ee2d6c37,cache=none, werror =stop, rerror =stop, aio =native -device virtio - blk - pc i, scsi =off,bus= pc i.0, addr =0x5,drive=drive- virtio -disk0,id= virtio -disk0, bootindex =1 - netdev tap,fd=25,id= hostnet 0, vhost =on, vhost fd=26 -device virtio -net- pc i, netdev = hostnet 0,id=net0,mac=00:1a:4a:10:00:00,bus= pc i.0, addr =0x3 - chardev socket,id= charchannel 0,path=/var/lib/ libvirt /qemu/channels/VM01-Fedora17.com. redhat . rhev m. vdsm ,server, nowait -device virtserialport,bus= virtio -serial0.0,nr=1, chardev = charchannel 0,id=channel0,name=com. redhat . rhev m. vdsm - chardev pty ,id= charconsole 0 -device vi rtc onsole, chardev = charconsole 0,id=console0 -device usb -tablet,id=input0 - vnc 0:0,password -k en-us - vga qxl -global qxl - vga . vram _size=67108864 -device virtio -balloon- pc i,id=balloon0,bus= pc i.0, addr =0x6 l ibvir: Lock ing error : unsupported configuration: Readonly leases are not supported 2012-06-06 14:39:37.412+: shutt ing down I tried to use this patch on libvirt http:// www .mail-archive.com/libvir-list@ redhat .com/ msg 56247. html but it didn't help ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Improve classpath building
- Original Message - From: Juan Hernandez jhern...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, June 5, 2012 3:53:08 PM Subject: [Engine-devel] Improve classpath building Hello all, I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths: 1. Hard coded in the scripts, with maybe some variables: CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:... This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices. 2. Use the build-classpath script: CP=`build-classpath engine-encryptutils engine-compat ...` This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations. None of these is good for all environments. I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc). In general it looks like a very good idea. Running the utilities in a development environment today is a real pain, so such a change will save a lot of time both when setting the development environment, and when testing changes. Didn't review all the whole source code, but from a quick glance I saw the preferredJars dictionary. IMO it is better to put this configuration in a configuration file, instead of a dictionary. Also, I would allow to change the path to this file, to allow developers to create a custom file (if they need one). My proposal is to create a engine-java script that we should use always when invoking java programs. This script will receive the same parameters that the java launcher receives, but the -cp or -classpath options will contain not the absolute name of the jar files, but just a simple jar name instead, something like commons-logging, commons-codec or engineencryptutils. The script will extract the -cp or -classpath options given and use them to do a search of the jar files in the locations where they can be in different environments: /usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib your jboss development installation/engine.ear your jboss development installation/engine.ear/lib In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing. Find attached the initial version of the proposed script. Let me know what you think. Regards, Juan Hernandez -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] IMPORTANT: Root web application moved
Hey, Is there a reason not to push the changes in standalone.xml (true--false) as a patch? Thank you, Oved - Original Message - From: Juan Hernandez juan.hernan...@redhat.com To: engine-devel@ovirt.org, shire...@redhat.com Sent: Thursday, May 17, 2012 11:13:50 PM Subject: [Engine-devel] IMPORTANT: Root web application moved Hello, I have recently merged a change that moves the root web application to the .ear directory: http://gerrit.ovirt.org/3782 This change could break your environment if you apply the patch and you don't do a clean installation. You may find an error like this in your server log and the application can fail to deploy: JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./: Failed to start service That means that you have more than one / application. Please make sure that you don't have the old ROOT.war in your deployment directory. Just remove it and the corresponding ROOT.war.dodeploy file. Also make sure that you don't have the following parameter in your standalone.xml file: enable-welcome-root=true Change the value to false. None of this actions are needed if you are building new RPMs and doing a clean installation. If you still have problems starting the application server after applying this change please let me know. Regards, Juan Hernandez ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] IMPORTANT: Root web application moved
Your fix is now merged. Everyone - please note that in order to apply the fix in your environment you need to run the maven build with -Psetup (just do the command you always do, and add the setup to the profiles in the -P option). However, it will only work if you upgraded your Jboss to 7.1.1, so make sure you upgrade! If you are still working with jboss 7.1.0 then it will fail to parse the jboss configuration. Regards, Oved - Original Message - From: Juan Hernandez juan.hernan...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, May 20, 2012 4:29:07 PM Subject: Re: [Engine-devel] IMPORTANT: Root web application moved On 05/20/2012 10:49 AM, Oved Ourfalli wrote: Hey, Is there a reason not to push the changes in standalone.xml (true--false) as a patch? I think there is no reason. I already submitted the change to gerrit: http://gerrit.ovirt.org/4524 Thank you, Oved - Original Message - From: Juan Hernandezjuan.hernan...@redhat.com To: engine-devel@ovirt.org, shire...@redhat.com Sent: Thursday, May 17, 2012 11:13:50 PM Subject: [Engine-devel] IMPORTANT: Root web application moved Hello, I have recently merged a change that moves the root web application to the .ear directory: http://gerrit.ovirt.org/3782 This change could break your environment if you apply the patch and you don't do a clean installation. You may find an error like this in your server log and the application can fail to deploy: JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./: Failed to start service That means that you have more than one / application. Please make sure that you don't have the old ROOT.war in your deployment directory. Just remove it and the corresponding ROOT.war.dodeploy file. Also make sure that you don't have the following parameter in your standalone.xml file: enable-welcome-root=true Change the value to false. None of this actions are needed if you are building new RPMs and doing a clean installation. If you still have problems starting the application server after applying this change please let me know. Regards, Juan Hernandez ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [libvirt]Supporting native USB in oVirt
- Original Message - From: Daniel P. Berrange berra...@redhat.com To: Hans de Goede hdego...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel engine-devel@ovirt.org, libvirt-l...@redhat.com Sent: Thursday, May 10, 2012 4:05:11 PM Subject: Re: [Engine-devel] [libvirt]Supporting native USB in oVirt On Thu, May 10, 2012 at 02:12:42PM +0200, Hans de Goede wrote: Hi, On 05/10/2012 01:39 PM, Oved Ourfalli wrote: Rephrasing my question a bit, to make it more clear. We are now working on adding the support for native USB devices on oVirt. This requires adding composite PCI devices to a VM (details below), requiring specific set of restrictions on the addresses of these devices, and the connections between them. Is it possible to add such a composite set of devices to a VM while using automatic address assignment, as we do today on the other PCI devices? To be clear, what the ovirt-engine people want to do (AFAIK), is add an EHCI controller with UHCI companion controllers to a vm, which would normally be done in the xml file like this: controller type='usb' index='0' model='ich9-ehci1' address type='pci' domain='0x' bus='0x00' slot='0x08' function='0x7'/ /controller controller type='usb' index='0' model='ich9-uhci1' master startport='0'/ address type='pci' domain='0x' bus='0x00' slot='0x08' function='0x0' multifunction='on'/ /controller controller type='usb' index='0' model='ich9-uhci2' master startport='2'/ address type='pci' domain='0x' bus='0x00' slot='0x08' function='0x1'/ /controller controller type='usb' index='0' model='ich9-uhci3' master startport='4'/ address type='pci' domain='0x' bus='0x00' slot='0x08' function='0x2'/ /controller Without manually specifying the addresses, ie they want to be able to write something like: controller type='usb' index='0' model='ich9-ehci1' /controller controller type='usb' index='0' model='ich9-uhci1' master startport='0'/ /controller controller type='usb' index='0' model='ich9-uhci2' master startport='2'/ /controller controller type='usb' index='0' model='ich9-uhci3' master startport='4'/ /controller Which currently does not work, and even if it would work libvirt does not seem to know that all devices here should share one pci slot using different functions of that slot (and the EHCI controller must have the highest function) I can imagine a syntax like this: controller type='usb' index='0' model='ich9-ehci1' /controller controller type='usb' index='0' model='ich9-uhci1' master id='usb' startport='0'/ /controller controller type='usb' index='0' model='ich9-uhci2' master id='usb' startport='2'/ /controller controller type='usb' index='0' model='ich9-uhci3' master id='usb' startport='4'/ /controller Where the id='usb' tells libvirt which master usb controller the companions belong to, and that libvirt would then automatically assign them all the same pci-slot, with different function number, ensuring the EHCI device gets the highest function nr. While I don't much fancy adding support for automatic assignment with the companion controllers, we could probably make it work, even without needing an extra 'id' attribute. We'd just have to special-case handling of model names uhci[1-3], and apply a first-match rule against ehci controller, if there were multiple That would be very helpful indeed. We would need something similar for the redirect devices, as they also requiring their address to be assigned to the same bus as the controllers. Daniel -- |: http://berrange.com -o- | http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- |http://virt-manager.org :| |: http://autobuild.org -o- |http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- | http://live.gnome.org/gtk-vnc :| ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [libvirt] Supporting native USB in oVirt
- Original Message - From: Gerd Hoffmann kra...@redhat.com To: Hans de Goede hdego...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel engine-devel@ovirt.org, libvirt-l...@redhat.com, Eli Mesika emes...@redhat.com Sent: Thursday, May 10, 2012 4:24:31 PM Subject: Re: [libvirt] [Engine-devel] Supporting native USB in oVirt Hi, I can imagine a syntax like this: controller type='usb' index='0' model='ich9-ehci1' /controller controller type='usb' index='0' model='ich9-uhci1' master id='usb' startport='0'/ /controller controller type='usb' index='0' model='ich9-uhci2' master id='usb' startport='2'/ /controller controller type='usb' index='0' model='ich9-uhci3' master id='usb' startport='4'/ /controller I think this should have been just something like ... controller type='usb' model='ich9-ehci-with-companions' / ... since day one. It's not like those are 4 independant usb controllers. I totally agree. That would make things much more simple, as each component now has to be aware of all the controller (EHCI + companion controllers), without any good reason. Is that possible to do this change? cheers, Gerd ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Supporting native USB in oVirt
cc-ing engine-devel.
Oved
- Original Message -
From: Hans de Goede hdego...@redhat.com
To: Oved Ourfalli ov...@redhat.com
Cc: Dave Allan dal...@redhat.com, Jiri Denemark jdene...@redhat.com,
Michal Privoznik
mpriv...@redhat.com, Itamar Heim ih...@redhat.com, Igor Lvovsky
ilvov...@redhat.com, Eli Mesika
emes...@redhat.com, Dan Kenigsberg dan...@redhat.com, Andrew Cathrow
acath...@redhat.com
Sent: Tuesday, May 8, 2012 10:48:32 AM
Subject: Re: Supporting native USB in oVirt
Hi,
On 05/08/2012 09:19 AM, Oved Ourfalli wrote:
Hi,
We are now working on adding the support for native USB devices on
oVirt.
As far as we understand, in order to use it we need to pass the
following devices with the following restrictions (according to
the EHCI spec):
1. EHCI USB controller - with the highest function number, #7.
devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x,bus:0x00,slot:0x04,function:0x7}}'
2. 3 UHCI USB controllers, on the same bus and PCI slot as the EHCI
controller. Set the multifunction bit to on, on the controller
with function #0.
devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x,bus:0x00,slot:0x04,function:0x0,multifunction:on}}'
devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x,bus:0x00,slot:0x04,function:0x1}}'
devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x,bus:0x00,slot:0x04,function:0x2}}'
3. USB redirect devices (according to the needed number of USB
slots, maximum 6) on the same bus, each one having a different
port.
devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}'
devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}'
devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}'
devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}'
devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}'
devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}'
To the best of my knowledge, the above is all correct.
4. If we want more than 6 USB slots, we need to have 2 EHCI
controllers, and 6 UHCI controllers, that are consistent with the
restrictions above, on different bus.
(we need them to be on different bus, since the connection between
the redirect devices and the controllers is the bus).
Correct, note that this may change in the future. Specifically I'm
thinking about
adding support for USB-2 hubs, and then have libvirt automatically
add new
redir-devices when all but one are in use. This is all just an idea
at the moment,
so don't count on it, I just wanted you to know that we are thinking
about making
it easier to make the number of devices dynamic in the future. So for
now you
could consider simply limiting redirection to max 6 devices.
According to Hans (cc-ed), if we let libvirt pick its own
addresses, it will put each controller of the composite USB
controller device on its own pci slot, which is a violation of the
EHCI spec.
Correct.
The problem is that the oVirt engine is not aware of addresses. They aren't
managed by it.
They are chosen automatically by libvirt, returned to the engine, and they
saved in the engine database in order to provide the ability to retain the
same PCI addresses after VM restart.
So, in order to support the EHCI spec, oVirt will have to be aware of
addresses, manage them (allocate them, check for collisions, update on every
libvirt change regarding that, etc...). Obviously, it doesn't feel right,
and in fact it is also not feasible, to manage these addresses in the oVirt
domain.
Is all the above correct, or are we missing something?
If so, can you address the issues above, and provide the ability to manage
these devices in libvirt?
Regards,
Hans
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] namingcontexts getting ignored.
Hey,
In case the namingContexts field contains more than one naming context, we have
no way of knowing which one is the required one.
We take the first one. In active directory, for example (and as far as I
understand in the newest free-ipa) you have a defaultNamingContext field, and
if so we take it, and it contains only one naming context.
As you see in the code below, we have a special treatment for RHDS, as it
always contains o=netscaperoot in the namingContexts field (not necessary at
the beginning of the list), so we filter it out.
It was enough for now, but I agree that if adding new LDAP providers, which
usually have a more complex and unpredictable data in the namingContext field,
then we would probably need to ask the user to specify the naming context for
us, and if he didn't specify it then assume it is identical to the domain name.
Oved
- Original Message -
From: Sharad Mishra snmis...@linux.vnet.ibm.com
To: engine-devel@ovirt.org
Sent: Saturday, April 28, 2012 2:51:25 AM
Subject: [Engine-devel] namingcontexts getting ignored.
Hi,
I enter getDefaultNamingContextFromNamingContexts() with
namingContexts set to -
namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES, O=IBM.COM,
O=DELETED.IBM.COM
But this method only takes the first case CN=SCHEMA and ignores
the rest. Actually I am interested in O=IBM.COM.
Is this working as designed or needs improvement?
-Sharad Mishra
IBM
public class RootDSEData {
private String domainDN = null;
private LdapProviderType ldapProviderType = null;
private final static String RHDS_NAMING_CONTEXT =
o=netscaperoot;
public static String
getDefaultNamingContextFromNamingContexts(Attribute namingContexts) {
for (int index = 0; index namingContexts.size(); ++index)
{
String namingContext;
try {
namingContext = (String) namingContexts.get(index);
} catch (NamingException e) {
return null;
}
if
(!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext))
{
return namingContext;
}
}
return null;
}
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] namingcontexts getting ignored.
- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: engine-devel@ovirt.org
Sent: Sunday, April 29, 2012 11:02:00 AM
Subject: Re: [Engine-devel] namingcontexts getting ignored.
On 04/29/2012 09:49 AM, Oved Ourfalli wrote:
Hey,
In case the namingContexts field contains more than one naming
context, we have no way of knowing which one is the required one.
We take the first one. In active directory, for example (and as far
as I understand in the newest free-ipa) you have a
defaultNamingContext field, and if so we take it, and it contains
only one naming context.
As you see in the code below, we have a special treatment for
RHDS, as it always contains o=netscaperoot in the namingContexts
field (not necessary at the beginning of the list), so we filter
it out.
It was enough for now, but I agree that if adding new LDAP
providers, which usually have a more complex and unpredictable
data in the namingContext field, then we would probably need to
ask the user to specify the naming context for us, and if he
didn't specify it then assume it is identical to the domain name.
Oved
Another idea -
Now that we provide the provider type in manage domains, maybe we
should
add a logic for getting naming contexts based on the provider type.
Thoughts on this?
That's pretty much what we do (although it is all in one method, so it should
be extracted to an interface). But, it is assuming one can predict what will be
in this field.
In IPA we now have the defaultNamingContext, so we can use it (like we do in
AD). In RHDS we know what it contains, so we can deduce the naming context. Not
sure about IBM- directory services. So, we might need to provide a
configuration entry for that as well (same as we do with the provider type).
- Original Message -
From: Sharad Mishra snmis...@linux.vnet.ibm.com
To: engine-devel@ovirt.org
Sent: Saturday, April 28, 2012 2:51:25 AM
Subject: [Engine-devel] namingcontexts getting ignored.
Hi,
I enter getDefaultNamingContextFromNamingContexts() with
namingContexts set to -
namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES,
O=IBM.COM,
O=DELETED.IBM.COM
But this method only takes the first case CN=SCHEMA and
ignores
the rest. Actually I am interested in O=IBM.COM.
Is this working as designed or needs improvement?
-Sharad Mishra
IBM
public class RootDSEData {
private String domainDN = null;
private LdapProviderType ldapProviderType = null;
private final static String RHDS_NAMING_CONTEXT =
o=netscaperoot;
public static String
getDefaultNamingContextFromNamingContexts(Attribute
namingContexts) {
for (int index = 0; index namingContexts.size();
++index)
{
String namingContext;
try {
namingContext = (String)
namingContexts.get(index);
} catch (NamingException e) {
return null;
}
if
(!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext))
{
return namingContext;
}
}
return null;
}
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Moving oVirt engine to Jboss AS 7.1.1
Hey all, We have pushed patches that make the necessary adjustments to allow working with the newest Jboss version, Jboss AS 7.1.1 Final. After fetching please do the following: * Download Jboss AS 7.1.1.Final from http://download.jboss.org/jbossas/7.1/jboss-as-7.1.1.Final/jboss-as-7.1.1.Final.tar.gz * Change the JBOSS_HOME wherever you defined it. * Change the Jboss Home in ~/.m2/settings.xml. * Run a full build, including setup: mvn clean install -DskipTests -Psetup,dep (consider using flags -Dgwt.userAgent=gecko1_8 and -Dgwt.draftCompile=true to avoid compiling GWT on all permutations). * Run jboss as usual. If you have any issues, reply here and we'll do anything to help. The oVirt engine wiki page (http://www.ovirt.org/wiki/Building_oVirt_engine) was changes accordingly. Thank you, Oved ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] StorageHelperDirector factory and StorageType
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 19, 2012 7:34:34 PM Subject: [Engine-devel] StorageHelperDirector factory and StorageType Hi all, StorageHelperDirector.java implements a mechanism that creates instances of classes implementing IStorageHelper based on String value of StorageType enum. Although the InitializeHelpers method has an automated mechanism for creating the helpers, I think it causes some bad practice - It creates a tight coupling between the StorageType values and the class names of storage helpers, and a result of that, Java naming convention is broken (we use upper case enum literals at StorageType which yield class names such as LOCALFSStorageHelper. I think that this mechanism is an overkill, and during addition of new storage type, its easily to detect during development if one has forgotten to add the helper to the factory (if done manually). Thoughts about this issue are more than welcome I agree that it is an overkill, especially because we don't add new storage types very often, and even if we do the programmer who added it will probably find out about it one way or another (while testing he will see an exception, leading him to the correct place). If it doesn't sound reasonable to others then there are other solutions (only if we really really have to): 1. Have the Enum contain also a class name or class prefix name for that specific type, which will be used instead of the enum value. It can be useful in cases in which there are a few classes needed for this type (might not be relevant to the specific case you described, but might be useful in other cases). 2. Make a checklist in the Enum of places to touch when changing the enum - hopefully the programmer will read it, and do as he is told... Also, this checklist should be updated as well when new interfaces are added, and I don't see how we can automatically update this checklist :-) 3. Assuming there is a tester to the factory, we can add an assert that checks how many values are there in the enum. Once the enum is extended, the test will fail, and we will know that we need to check for related things (we can put a comment in the tester, specifying a checklist). - from my experience, in most cases it will end in the programmer doing everything needed, then failing on this test and fixing it (updating the number of values) Compile-time assertions are useful in such cases, but didn't find such an option in Java (perhaps we should move the engine to C++ ;-) ). I'd go with option #1 (again... only if we really need to provide an automatic factory). Oved Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST session management
- Original Message - From: Geert Jansen gjan...@redhat.com To: Miki Kenneth mkenn...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel engine-devel@ovirt.org, Eoghan Glynn egl...@redhat.com Sent: Monday, April 16, 2012 11:34:26 AM Subject: Re: [Engine-devel] REST session management On 04/16/2012 10:04 AM, Miki Kenneth wrote: I Agree on that, although I'm not sure whether it is really needed to release the session, rather then rely on timeout. If we indeed need to provide a way to release the session then I agree this is the best alternative. But if we don't then it will make the API to the client more (but not very) complex in that manner. I would go for both - release mechanism (for proper handling) and timeout mechanism for garbage collection. (refer to: http://blog.synopse.info/post/2011/05/24/How-to-implement-RESTful-authentication) Agreed we need both. I think that for security purposes, it is important to have a log out function. That way, client applications can decide depending on their local security requirements whether or not it is acceptable to leave a session open. So (unless someone objects) let's go for option #2 (using the Prefer header on each and every request, and release the session once it is not there). Thank you, Oved Regards, Geert ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Releases/31/FeatureList - oVirtWiki
We need to remove that one. We thought at first to put a feature list there, but maintaining it is not so trivial. - Original Message - From: Yaniv Kaul yk...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, March 22, 2012 2:50:45 PM Subject: [Engine-devel] Releases/31/FeatureList - oVirtWiki Is anyone maintaining this page? Is it up-to-date, wrt feature list, completion percentage, etc.? http://www.ovirt.org/wiki/Releases/31/FeatureList ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk Permissions Feature
- Original Message - From: Einav Cohen eco...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, March 19, 2012 10:25:24 AM Subject: Re: [Engine-devel] Disk Permissions Feature - Original Message - From: Oved Ourfalli ov...@redhat.com Sent: Sunday, March 18, 2012 11:52:33 AM On 03/15/2012 05:34 PM, Omer Frenkel wrote: 1. Create disk - requires permissions on the Storage Domain, (can't assume Quota is sufficient to permit user creating the disk on the Storage Domain, as Quota might be disabled) I'd also specify create disk for regular disks is at storage domain level?, while direct lun disks require system level permission of add disk. so, if quota is disabled, how important is it to prevent creation of disks (other than direct lun ones, which would require a permission similar to storage domain creation)? if this is added, it has to be implicitly added / not needed if user has quota (i.e., having a quota should be similar to having a permission as far as the check goes). We should look into it, how complicate is it to validate if user has either quota or permission, and allow creating a disk on a SD if either exists. this might be confusing to the user as he can disable the quota, then stuff would stop working. we can't require both quota and permissions from user on storage domains - that's cumbersome. question is if we can limit the need for permissions to disks only to places where they are needed (shared, direct, floating)? +1 on that. I also think it is only relevant on attaching a disk to a VM, as the other use-cases are simpler: 1. Attach disk to VM - would require having permissions on the disk (whether it is shared, direct lun or floating) 2. Add disk to VM - would only require quota (if enforced). 3. Create disk (i.e., floating/shared disk) - would only require quota (if enforced). and if not enforced? anyone can create as much disks as he like? we thought of requiring permissions if quota is disabled, but i think its confusing to the user as he plays with You are right. Need to think this through... Also, we need to get a better understanding on the use-cases for floating/shared disk... who is supposed to create them, and who to attach... The convention today is that in order to create something, you need permissions on the ancestor entity. Therefore, I think it should be as follows: 1. In order to create a Disk in a VM context, you need permission on the VM (just like in 3.0, IIRC). 2. In order to create a Floating Disk within a storage domain, you need permission on the storage domain 1 is okay as long as we limit the user from detaching this disk later on, as detaching it will make it floating. Or, we can allow detaching only in case the user has permissions on the storage domain, but that will be hard to understand in a user's perspective. 3. In order to create an External LUN Disk, you need permission on System/DC/Whatever we decide the ancestor entity of External LUN is. 4? Not sure regarding creation of External LUN Disk in a VM context (if that scenario exists) - will probably need a permission on both VM and External-LUN-ancestor, since this is a special case. All of the above is regardless quota, meaning, if quota is enforced, quota restrictions will apply as relevant *in addition* to the permission limitations. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Bridgeless Networks api design
- Original Message - From: Itamar Heim ih...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, March 18, 2012 10:39:48 AM Subject: Re: [Engine-devel] Bridgeless Networks api design On 03/18/2012 10:43 AM, Michael Pasternak wrote: On 03/18/2012 10:21 AM, Itamar Heim wrote: On 03/18/2012 09:33 AM, Michael Pasternak wrote: the question is Management/Migration/Storage/Display can be non-bridged?, if so, bridgedtrue|false/bridged makes sense. bridge is an implementation detail at host level, hence the discussion is about abstracting it from users. a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV network designationManagement|Migration|Storage|Display|VM/designation /network what do you say about having it as another /designation/ type? it==VM? the above looks ok to me. (I really hope for a better element name than designation though) Consider using purpose instead of designation. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] VM disks
- Original Message - From: Livnat Peer lp...@redhat.com To: engine-devel@ovirt.org Sent: Saturday, February 18, 2012 7:07:01 PM Subject: [Engine-devel] VM disks Hi, These days we are working on various features around VM disks, in the different threads it was decided that we'll have the ability to attach a disk to a VM but it will be added as inactive, then the user can activate it for it to be accessible from within the guest. Flow of adding a new disk would be: - creating the disk - attaching the disk to the VM - activating it Flow of adding a shared disk (or any other existing disk): - attach the disk - activate it It seems to me a lot like adding a storage domain and I remember a lot of rejections on the storage domain flow (mostly about it being too cumbersome). After discussing the issue with various people we could not find a good reason for having a VM disk in attached but inactive mode. Of course we can wrap the above steps in one step for specific flows (add+attach within a VM context for example) but can anyone think on a good reason to support attached but inactive disk? I would suggest that when attaching a disk to a VM it becomes part of the VM (active) like in 'real' machines. +1 on that (regardless of whether the disk is shared or not). IMO - in the case of shared disk we should make it as clear as possible to the user/admin that the added disk is shared, but the flow should be exactly the same. Thank you, Livnat ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] bridgeless networks - update
- Original Message - From: Roy Golan rgo...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, February 16, 2012 10:48:08 AM Subject: Re: [Engine-devel] bridgeless networks - update - Original Message - From: Itamar Heim ih...@redhat.com To: Roy Golan rgo...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, February 16, 2012 12:21:49 AM Subject: Re: [Engine-devel] bridgeless networks - update On 02/15/2012 06:50 PM, Roy Golan wrote: following ovirt engine weekly here's a summary of the changes: 1. no validation during vmInterface creation 2. when attaching a network the default value is bridged (GUI responsibility) so what is the default if one didn't pass it in the API (i.e., backend should have a default value. UI may choose whatver). I generally dislike default values in API because client wont know what it is, default behavior might change in time etc... (and the UI/API name in the wiki is something around allow to run vms, not bridged - so maybe change the terminology used to discuss this to reduce risk of confusion/mistakes later). 3. monitoring - detect mixed configured cluster (network foo is bridged on one host and not on another) and issue an audit log warning with event interval of 1 day why does this matter if cluster is mixed? to inform a potential migration problem i.e., wouldn't this be interesting per host, that a network which could be bridgeless http://www.ovirt.org/Features/Design/Network/SetupNetworks/is bridged to warn about? I agree that an admin might like a notice that he can improve the host's performance. but currently how can we say a network can be bridgeless given that we don't have the nic type yet? detect if no vmInterfaces are connected to it maybe? Itamar - It was decided to remove the allow to run VMs attribute on the logical network level (to simplify things, not sure it is the right way, though). AFAIU the main reason for that is that we might want to use a network for VMs in one cluster, and for other uses on another cluster. Not sure how important this use-case is, but in AFAIU that was the main reason to leave this attribute aside for now, and add it only later on. If we indeed don't add this attribute then we can't really tell the admin this network can be bridgeless as we don't know that. Maybe the user wants to run VMs on it. So, we can just warn him in several scenarios that what he is doing is probably wrong, or we can monitor that and issue a warning event. If we do add this attribute then we can decide on a different logic: allowing only bridge for VM networks, allowing both but warn the user, monitoring for mixed configurations, and etc., according to what we think is a reasonable use-case. wiki will be updated accordingly. having fast read it, couldn't understand the backward compatibility section (Its compatibility version is 3.1 and enforced by the enclosed command as mentioned already) i'd make it clear this is a 3.1 DC feature, and not a cluster one(?) becuase iirc, setupNetworks is actually host level 3.1 compatibility level, not cluster/dc wide? yes its not clear enough that 3.0 cluster cannot have their network bridgeless. will fix this to be clearer. Thanks, Roy ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Spice-devel] SPICE related features
- Original Message - From: Dor Laor dl...@redhat.com To: spice-de...@lists.freedesktop.org, engine-devel@ovirt.org Cc: David Jaša dj...@redhat.com, Oved Ourfalli ov...@redhat.com, Hans de Goede hdego...@redhat.com Sent: Wednesday, February 15, 2012 12:52:46 PM Subject: Re: [Engine-devel] [Spice-devel] SPICE related features On 02/09/2012 02:50 PM, David Jaša wrote: Itamar Heim píše v Čt 09. 02. 2012 v 11:07 +0200: On 02/09/2012 11:05 AM, Hans de Goede wrote: Hi, On 02/09/2012 09:33 AM, Itamar Heim wrote: On 02/09/2012 10:31 AM, Hans de Goede wrote: snip so this means we need to ask the user for linux guests if they want single head or multiple heads when they choose multi monitor? We could ask the user, but I don't think that that is a good idea. this will cause their (single) head to spin... With which you seem to agree :) any better UX we can suggest users? Yes, no UI at all, the current solution using multiple single monitor pci cards means using Xinerama, which disables Xrandr, and thus allows no dynamic adjustment of the monitor settings of the guest, instead an xorg.conf file must be written (the linux agent can generate one based on the current client monitor info) and Xorg needs to be restarted. This is the result of the multiple pci cards which each 1 monitor model we've been using for windows guests being a poor match for Linux guests. So we are working on adding support to drive multiple monitors from a single qxl pci device. This requires changes on both the host and guest side, but if both sides support it this configuration is much better, so IMHO ovirt should just automatically enable it if both the host (the cluster) and the guest support it. On the guest side, this is the current status: RHEL= 6.1 no multi monitor support RHEL 6.2(*) - 6.? multi monitor support using Xinerama (so 1 monitor/card, multiple cards) RHEL= 6.? multi monitor support using a single card with multiple outputs Just like when exactly the new multi mon support will be available for guests, it is a similar question mark for when it will be available for the host. this is the ovirt mailing list, so upstream versions are more relevant here. in any case, I have the same issue with backward compatibilty. say you fix this in fedora 17. user started a guest VM when host was fedora 16. admin upgraded host and changed cluster level to utilize new features. suddenly on next boot guest will move from 4 heads to single head? I'm guessing it will break user configuration. i.e., user should be able to choose to move to utilize the new mode? I see this as something which gets decided at vm creation time, and then stored in the vm config. So if the vm gets created with a guest OS which does not support multiple monitors per qxl device, or when the cluster does not support it, it uses the old setup with 1 card / monitor. Even if the guest OS or the cluster gets upgraded later. so instead of letting user change this, we'd force this at vm creation time? I'm not sure this is friendlier. I think that some history-watching logic one UI bit could be the way to go. The UI bit would be yet another select button that would let user choose what graphic layout (all monitors on single graphic card, one graphic card per monitor (legacy)). The logic would be like this: * pre-existing guest that now supports new layout in 3.1 cluster * The guest uses 1 monitor, is swithed to 2+ -- new * The guest uses 2+ monitor layout -- old, big fat warning when changing to the new that user should wipe xinerama configuration in the guest * pre-existing guest in old or mixed cluster: * guest uses 2+ monitors -- old * guest is newly configured for 2+ monitors -- show warning that user either has co configure xinerama or use newer cluster -- old * new guest in new cluster: * -- new * if user switches to old, show warning * old guest in any type of cluster * -- old This kind of behavior should provide sensible defaults, all valid choices in all possible scenarios and it should not interfere too much when admin chooses to do anything. In short, the same rule of the thumb applies to all of our virtual hardware: - new vm creation should use the greatest and latest virtual hardware version (if the current cluster allows it) - For existing VMs we should preserve their current virtual hardware set (-M flag in qemu machine type vocabulary, cluster terminology for ovirt). - Changing
Re: [Engine-devel] SharedRawDisk feature detail
- Original Message - From: Livnat Peer lp...@redhat.com To: Maor mlipc...@redhat.com Cc: engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Monday, February 13, 2012 9:17:41 AM Subject: Re: [Engine-devel] SharedRawDisk feature detail On 13/02/12 00:06, Ayal Baron wrote: I started writing the changes in the email but got tired of it and just made a bunch of changes in the wiki (impossible to track in email, such things should be done using etherpad or something). A few questions though: plugged vs. enabled - I thought we converged on attached/detached and enabled/disabled and not plugged/unplugged? * Shared disks are attached with R/W permissions. - What about enabling R/O ? (esp. for stateless/pools) Do we have ack from libvirt that attaching disk in r/o mode actually works? (I know we opened a bug for testing this but i can't find the bug - Haim?) * Template disks should not be shared. - Why not? (read only) * When exporting a VM, only the disks which are not shared will be exported. - Why is the above not treated the same as a snapshot? the configuration will reference the shared disk as unplugged? (or will it and it's just not clear?) It is not the same case as snapshot. We don't have in the export domain the shared image. I didn't touch stateless/pools but should be fixed to reflect comments on this thread. Is Remove shared disk and Delete shared disk the same thing? if so, why the dual terminology? I don't quite follow the logic determining which section is under functionality and which under user experience. For example, why do you have a 'Delete shared disk' section in the Ux section but not a 'Move shared disk' section (there is no shared disk specific logic visible in the delete action UI). * Disk name should be generated automatically based on the vm name and disk number in the VM. Description will be empty. * New disk should enforce the user to enter a name for the disk. - Huh? the above 2 items seem like an oxymoron, but I may be missing something... The first line is referring to upgrade flow (it is under the upgrade section), the second line is the behavior going forward. I agree this is confusing, Maor I suggest you remove the general behavior from the upgrade section. * Attach/Detach of a shared disk can be performed only when the VM is in status 'down'. - Why? under the functionality section you clearly stated that attaching a disk will result in it being attached but disabled... I agree with Ayal on this. Attach/Detach a disk should be enabled regardless if the VM is running or not, this applies to all disks not only to shared disk. Maor, few more questions: * Regular disk can become a shared raw disk, by editing the existing disk and marking the 'share disk' property type. There are limitation to this, for example disk with snapshots can not be shared (we support only shared raw disks etc.) * When removing a VM with shared disks attached to it, the shared disks will not be deleted. If the shared disk is not attached to any other VM, why don't we delete it? I think we should behave with it as any other disk. Maybe going forward when deleting a VM we should ask if to remove the disks as well. This logic can apply to shared disk in the same way, I don't think we should have a special logic around this for shared disks. Do we plan to support deleting disks in the disks tab? (as part of supporting floating disks) If not then we should delete the disk (as we won't be able to delete it after the last VM using it is deleted). If we do, then I think we should indeed ask the user whether he would like to delete those disks or not (in case it is the last VM). Deleting it implicitly might be wrong, as these disks might contain data that the user would like to attach to a new VM. * The VDSM owner is missing from the doc, and vdsm is missing from the affected projects. Livnat - Original Message - On 02/02/12 17:15, Maor wrote: Hello all, The shared raw disk feature description can be found under the following links: http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk http://www.ovirt.org/wiki/Features/SharedRawDisk Please feel free, to share your comments. Regards, Maor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Hi Maor, - when taking a VM snapshot, a snapshot of the shared disk will not be taken. I think it is worth mentioning that the shared disk will be part of the VM snapshot configuration. The disk will appear as unplugged. - Move VM is deprecated in 3.1. - It seems from the wiki that shared disk is not supported for template but is supported for VM pool. I am not sure how can we do
Re: [Engine-devel] [Users] Autorecovery feature plan for review
Some comments: 1. I think the amount of time between tests should be configurable. 2. I guess some of the actions done by the autorecovery process should be monitored, so take a look at http://www.ovirt.org/wiki/Features/TaskManagerDetailed#Job_for_System_Monitors; in order to monitor this action. Oved - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org, us...@ovirt.org Sent: Monday, February 13, 2012 12:32:34 PM Subject: [Users] Autorecovery feature plan for review Hi, Please review the plan document for autorecovery. http://www.ovirt.org/wiki/Features/Autorecovery Thank you, Laszlo ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Spice-devel] SPICE related features
- Original Message - From: Hans de Goede hdego...@redhat.com To: dl...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, spice-de...@lists.freedesktop.org, engine-devel@ovirt.org Sent: Wednesday, February 8, 2012 4:36:06 PM Subject: Re: [Spice-devel] [Engine-devel] SPICE related features Hi all, Dor, thanks for the forward. On 02/08/2012 12:49 PM, Dor Laor wrote: On 02/08/2012 01:43 PM, Oved Ourfalli wrote: Hello all, The following feature page describes the engine adjustments needed for new SPICE features. http://www.ovirt.org/wiki/Features/SPICERelatedFeatures Al in all this looks good, some remarks: * WRT multi monitor support for RHEL, the latest RHEL xorg-x11-drv-qxl and spice-vdagent packages do support multi monitor support using multiple cards in Xinerama mode. We are waiting for a RHEL-6 z-stream update to fix an x11-xorg-server-Xorg bug which atm makes the mouse unusable in this mode wants this lands, multi-monitor support this way should be available for RHEL-6.2 (and later) guests. The same holds true for Fedora guests, although I don't expect the necessary Xorg changes to be available for versions older then Fedora 17. The driving multiple monitors from a single qxl device support OTOH is still a long time away, likely 6 months or so. The idea behind this support is to have it on a single PCI card, and not on multiple ones. * WRT the native USB support, the wiki page says: If the cluster level is 3.1 (which supports native USB support), but the client only has non-native USB support (old client), then we will use the old client. This means that we'll have to keep supporting the non-native USB support, side-by-side with the native one. Note that the new usb-support requires starting the guest with a number of extra emulated devices. These will just sit around and do nothing if unused, so I don't really expect any issues with this, but this still is something to be aware of. OTOH the old usb-support requires the installation of extra software inside the guest, if this is not installed falling back to the old client will not help wrt usb support. Of course. Added a note on that in the wiki page. Thank you, Oved Regards, Hans ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] bridgless networks
I think that in the UI we should automatically check the bridged for VM networks, and uncheck it for non-VM ones. In the future, when we'll support more network types that can run VMs without a bridge (VEPA/VNLink/SRIOV) then we would change this logic. As for the open issues: [1] if a network is checked with allowToRunVms and an underlying host will need an un-bridged(SRIOV...) network to fulfil that how do we treat that during monitoring? we should be able to distinguish on interfaces that can run vm with/without bridge and deduce that cluster compatibility didn't break [oved] We will be able to make this distinction. Less relevant for today, but will be relevant in the future. [2] if, for some reason an admin wants a non VM network to be bridged, should we allow it? [oved] I would allow it. - Original Message - From: Roy Golan rgo...@redhat.com To: engine-devel@ovirt.org Sent: Monday, February 6, 2012 4:47:11 PM Subject: [Engine-devel] bridgless networks Hi All Lately I've been working on a design of bridge-less network feature in the engine. You can see it in http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks#Bridge-less_Networks Please review the design. Note, there are some open issues, you can find in the relevant section. Reviews and comments are very welcome. Thanks, Roy ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SharedRawDisk feature detail
- Original Message - From: Maor mlipc...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, February 5, 2012 3:14:35 PM Subject: Re: [Engine-devel] SharedRawDisk feature detail On 02/03/2012 04:59 PM, Itamar Heim wrote: On 02/02/2012 05:15 PM, Maor wrote: Hello all, The shared raw disk feature description can be found under the following links: http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk http://www.ovirt.org/wiki/Features/SharedRawDisk Please feel free, to share your comments. 1. Affected oVirt projects i'm pretty sure the history data warehouse will need to adapt to this. 2. The shared raw disk feature should provide the ability to attach disk to many VMs with safe concurrent access, this could be read as if ovirt or vdsm somehow provides a mechanism for safe concurrent access. maybe something like to multiple VMs that can handle concurrent access to a shared disk without risk of corruption. and having just written this - sounds like setting this flag at UI level should include a prompt to the user to make sure they understand that flagging the disk as shared *will* lead to corruption if it is attached to virtual machines which do not support and expect it to be shared with other virtual or physical machines[1] I agree, I will change it. 3. The synchronization/clustering of shared raw disk between VMs will be managed in the file system. either i don't understand what this mean, or it could be read with a misleading meaning. Maybe the following rephrase will be more accurate: The synchronization/clustering of shared raw disk between VMs should be based on external independent application which will be synchronized with the guest application. 4. VM Pools VM Pools are always based (at least today) on templates, and templates have no shared disks. I'd just block attaching a shared disk to a VM which is part of a pool (unless there is a very interesting use case meriting this) If there is no reason to attach shared disk to a VM from pool, maybe its also not that relevant to attach shared disk to stateless VM. Miki? I think there is such a use-case in clustered environments (DB cluster, for example), in which you have several disks that are not shared (OS, applications, etc.), and several disks that are shared (DB disks). In this case, in order to create this clustered environment, it will be nice if you create a template with the regular disks, create a pool from it, and attach all the VMs in the pool the shared DB disks. (It would be even nicer if the shared disk will be a part of the template, and when creating VMs from it they will have have a link to this shared disk - but I agree that it may be complex so maybe we should leave it aside for now). Thoughts? 5. Quota has to be taken in consideration, for every new feature that will involve consumption of resources managed by it. I thought quota is not relevant in this feature. Why not? Quota should be taken in consideration when adding new shared raw disk, or moving a disk to other domains. We should also notice that shared raw disk should not consume more quota when sharing the disk with different VMs. 6. future work - Permissions should be added for disk entity so who can add a shared disk? Data Center Administrator or System Administrator will be initialized with permissions for creating shared raw disk, or changing shared disk to be unshared. Regarding attach/detach disks to/from VM, I was thinking that for phase one we will count on the user VM permissions. If user will have permissions to create new disks on the VM, he will also have permissions to attach new shared raw disk to it. same as for floating disks, i find it hard to imagine a flow in which if someone flagged a disk as shared, suddenly everyone can have access to it. same as my statement of floating disks - I'll spend some more time to reflect on this specific part. [1] an external LUN based disk could be shared with a physical server as well. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Using categories in the Feature pages
Hey all, When you write a feature page, please make sure you end it with: [[Category:Feature]] We will add a link to this category, so that features will be easier to track. In your detailed feature page, put: [[Category:DetailedFeature]] And in the design page put: [[Category:FeatureDesign]] If the feature is simple enough, and creating all the three pages is an overkill, then create the first one (with the correct category), and put all the details there. Thank you, Oved ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Failure to deploy (with JBoss 7.1)
I saw that error before, and running mvn clean install -Psetup,dep fixed this issue. But, I would like to examine it a bit before I tell you to do that. Can you send me the details to your environment offline, and I'll do some testing there? - Original Message - From: Yaniv Kaul yk...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, January 17, 2012 3:27:50 PM Subject: Re: [Engine-devel] Failure to deploy (with JBoss 7.1) On 01/17/2012 03:05 PM, Oved Ourfalli wrote: The question is what did you have in the previous environment (as5) in postgres-ds.xml file. I've had the 'password' field enabled there. I suspect it's because I did 'setup' in my deployment with Jboss 7. I've edited standalone.xml, and I'm now into my next issue: 2012-01-17 15:24:34,678 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment engine.ear 2012-01-17 15:24:34,747 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in deployment directory. To trigger deployment create a file called engine.ear.dodeploy 2012-01-17 15:24:34,758 ERROR [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014612: Operation (add) failed - address: ([(deployment = engine.ear)]): java.lang.IllegalStateException: JBAS014666: Duplicate resource [(deployment = engine.ear)] at org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:152) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:84) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:152) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.server.deployment.DeploymentDeployHandler.execute(DeploymentDeployHandler.java:68) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:152) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:183) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:152) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:84) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:152) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:84) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:322) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:216) [jboss-as-controller-7.1.0.Beta1b.jar
