November 2012 - Devel - Ovirt List Archives

[Engine-devel] Design review summary for 3.2 - Host Power Management Multiple Agent Support

by Eli Mesika

http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents Regards Eli Mesika

12 years

1
0
0 / 0

[Engine-devel] Atlassian Crowd Support for Ovirt

by Justin Hammond

This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,=0D=0A=0D=0AI've just uploaded to Gerrit a patch that adds atlassi= an crowd authentication support to oVirt.(http://gerrit.ovirt.org/9324)=0D= =0A=0D=0A=C2=A0=0D=0AAll the nitty gritty details are in the commit messa= ge, but basically this adds a new authentication domain, and when selecte= d sends the authentication request off to a crowd server.=0D=0A=0D=0A=C2=A0= =0D=0AWe have been using this patch on 3.1 for a while, and I thought its= overdue to see if you guys are interested in taking this upstream=3F=0D=0A= =0D=0A=C2=A0=0D=0AThere are two areas that I know could use improvements:= =0D=0A=0D=0A1) caching the results from the crowd server, so we don't que= ry for every API request etc.=0D=0A=0D=0A2) adding proper memberOf suppor= t so groups work correctly.=0D=0A=0D=0A=C2=A0=0D=0APlease let me know if = you guys are interested in this, and please be gentle on your reviews - I= =E1=B8=BF not a Java Programmer by any means, and probably brought too ma= ny C++ traits over here... :)=0D=0A=0D=0A=C2=A0=0D=0AThanks=0D=0A=0D=0A=C2= =A0=0D=0AJustin=0D=0A=0D=0A --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww= w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A <meta name=3D"Generator"= content=3D"Zarafa WebAccess v7.0.3-30515">=0A <meta http-equiv=3D"Conte= nt-Type" content=3D"text/html; charset=3Dutf-8">=0A <title>Atlassian Cro= wd Support for Ovirt</title>=0A <style type=3D"text/css">=0A body=0D= =0A {=0D=0A font-family: Arial, Verdana, Sans-Serif ! importa= nt;=0D=0A font-size: 12px;=0D=0A padding: 5px 5px 5px 5px;=0D= =0A margin: 0px;=0D=0A border-style: none;=0D=0A bac= kground-color: #ffffff;=0D=0A }=0D=0A=0D=0A p, ul, li=0D=0A = {=0D=0A margin-top: 0px;=0D=0A margin-bottom: 0px;=0D=0A = }=0D=0A </style>=0A</head>=0A<body>=0AHi All,I've jus= t uploaded to Gerrit a patch that adds atlassian crowd authentication sup= port to oVirt.(http://gerrit.ovirt.org/9324) All the n= itty gritty details are in the commit message, but basically this adds a = new authentication domain, and when selected sends the authentication req= uest off to a crowd server. We have been using this pa= tch on 3.1 for a while, and I thought its overdue to see if you guys are = interested in taking this upstream=3F There are two ar= eas that I know could use improvements:1) caching the results from= the crowd server, so we don't query for every API request etc.<p= >2) adding proper memberOf support so groups work correctly. = Please let me know if you guys are interested in this, and please = be gentle on your reviews - I=E1=B8=BF not a Java Programmer by any means= , and probably brought too many C++ traits over here... :) </= p>Thanks Justin=0A</body>=0A</html> --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS--

12 years

2
1
0 / 0

[Engine-devel] [Design for 3.2 RFE] Host Power Management Multiple Agent Support

by Eli Mesika

Requirements: http://wiki.ovirt.org/wiki/Features/HostPMMultipleAgents DR : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMMultipleAgents

12 years

3
7
0 / 0

[Engine-devel] Registering an existing disk or VM through the REST API

by Morrissey, Christopher

--_000_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, As many of you know, we're working on adding a plugin to oVirt for NetApp s= torage controllers. The plugin will allow users to add a new storage domain= and rapidly clone VMs using the native ONTAP APIs. Our plan is to do this = outside of oVirt in a separate engine and then register the new storage dom= ain or cloned VMs through the REST API. I've been going through the oVirt code and I'm not able to find a way to re= gister an existing VM or disk through the REST API. Am I missing something = or is this functionality that needs to be added? As part of the cloning pro= cess we can generate new UUIDs for the cloned disks and images, but I don't= see a way to get them recognized by oVirt. This functionality is very important to moving forward on our plugin and I = can certainly help add this capability if needed. -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428 --_000_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi All,<o:p></o:p> <o:p> </o:p> As many of you know, we’re working on adding a= plugin to oVirt for NetApp storage controllers. The plugin will allow user= s to add a new storage domain and rapidly clone VMs using the native ONTAP = APIs. Our plan is to do this outside of oVirt in a separate engine and then register the new storage domain or clo= ned VMs through the REST API.<o:p></o:p> <o:p> </o:p> I’ve been going through the oVirt code and I&#= 8217;m not able to find a way to register an existing VM or disk through th= e REST API. Am I missing something or is this functionality that needs to b= e added? As part of the cloning process we can generate new UUIDs for the cloned disks and images, but I don’t see = a way to get them recognized by oVirt.<o:p></o:p> <o:p> </o:p> This functionality is very important to moving forwa= rd on our plugin and I can certainly help add this capability if needed.<o:= p></o:p> <o:p> </o:p> -Chris<o:p></o:p> <o:p> </o:p> Chris Morrissey<o:p></o:p> Software Engineer<o:p></o:p> NetApp Inc.<o:p></o:p> 919.476.4428<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_--

12 years

4
7
0 / 0

Re: [Engine-devel] network wiring DD questions/comments

by Alona Kaplan

> Hi, > > I"ve added my answers as inline comments. > > Thanks, > Alona. > > > Hi Alona, > > I reviewed the DD of wired/unwired and I have a few > > questions/comments - > > > > 1. update vnic while the VM is running should be limited to cluster > > 3.2 > > (except for plug/unplug) > I"ve updated the detailed wiki- > 1. On Add- there will be a canDoAction error if the user will try to > change the network to "none" on 3.1 or less. > I don't think the "none" should be removed from the combo. The user > won't understand why sometimes he has "none" and sometimes not. > 2. On Update- there are two problematic cases with 3.1 or less- > 2.1 The user changes the network to "none" - should behave as add. > 2.2 The vnic is plugged (before and after the update) and the only > change is the network. > In this case an "UpdateDevice" verb should be sent to vdsm, so > if it is 3.1 or less the backend should throw a canDoAction. (I > updated the wiki we this scenario) > But, if mac address, type or plug were updated- we are sending > plug/unplug to the vdsm. So the update can be done although for > 3.1. > We talked about disabling all the fields (except "plug/unplug") > in the dialog if the nic is plugged and rollback the ui if the > user change from plugged to unplugged and then to plugged > again. > I don't think it is right. Because if the user wants just to > update the mac for example, we should allow it even if the nic > is plugged. > I think the canDoAction is enough. > 2.3 I think for 3.0 or less, the update button should be disabled if > the vm is not down. (Updated the wiki). > > > > 2. RunVM - why do we need to pass the 'linkState' property to > > VDSM? > > I > > think that if the link is down we should pass none as the network > > and > > if > > the link is up we should pass the network name, like we did so far. > > the > > link-state is internal implementation detail in the engine. > > > I will talk to Simon. If he is ok with it, I will remove the link > state from the feature. > > > 3. looking on the VDSM API - > > * why do we need 'type' ? > Danken wanted UpdateDevice to be a common api for updating all the > devices. By the type the vdsm decides which device is updated. > > * why do we need 'device'? > You are right, it should be removed. (I updated the wiki) > > * why do we need 'alias'? > We don't send the mac. This is the "unique id" of the nic. > The libvirt sets a unique alias for each device(disk, interface...), > so it can be used as the identifier of the device. > > * As I wrote I think we don't need 'linkState' > > > > 4. I am missing the error handling description when the user > > performs > > - > > Update Vnic while changing the type for example. What is the > > behavior > > if > > we succeed to unplug but not plug after that, etc. > > > When changing the type we are internally using the plug/unplug > actions. > If the unplug succeeds and the plug fails- the backend/ui will get an > error from the plug action. > At the end of such situation the vnic will be unplugged. > I"m not sure what we should do with the type- store the new type or > rollback to the old value in the db? > > > 5. Updated APIs section -This section is based on the fact that we > > pass > > linkstate to vdsm which is not needed IMO, so if we change that > > this > > section should be updated accordingly. > > > > 6. The EVENT section is empty, what events should be issued to > > audit > > log? > > I think we should have an even for update vnic and if plug/unplug > > is > > required a second event should be issued. > We already have events for update_vnic failure- > NETWORK_UPDATE_VM_INTERFACE_FAILED and success- > NETWORK_UPDATE_VM_INTERFACE. > And as we use the old plug/unplug actions we don't have to add new > events to the audit log. > I don't think we have to add extra code to the events. > > > > > 7. why does link state is varchar in DB? you expect to support > > other > > option in addition to up/Down (which can be represented by 1 bit), > > maybe > > n/a status? > You are right, should be boolean. (Updated the wiki). > (If Simon will agree to remove the link state from the feature, will > be removed...) > > > > 8. About the open issues- > > > > * About deprecation of ActivateDeactivateVmNic command - I think > > that > > we should remove this command from the backend to avoid duplicate > > flows > > and bugs etc. for Backwards compatibility we should update the > > clients > > to use the new UpdateVmNetworkInterface. the down side for that is > > we > > have to make the can do action validation more complicated > > (according > > to > > cluster level etc.) > > > > * If we remove ActivateDeactivateVmNic there is no need to rename > > it > > ;) > We use it internally. > Also we have to keep it exposed for backward compatibility with Rest > API. > I"m not sure it should be renamed... > > > > > > Thanks, Livnat > > >

12 years

2
1
0 / 0

[Engine-devel] network wiring DD questions/comments

by Livnat Peer

Hi Alona, I reviewed the DD of wired/unwired and I have a few questions/comments - 1. update vnic while the VM is running should be limited to cluster 3.2 (except for plug/unplug) 2. RunVM - why do we need to pass the 'linkState' property to VDSM? I think that if the link is down we should pass none as the network and if the link is up we should pass the network name, like we did so far. the link-state is internal implementation detail in the engine. 3. looking on the VDSM API - * why do we need 'type' ? * why do we need 'device'? * why do we need 'alias'? * As I wrote I think we don't need 'linkState' 4. I am missing the error handling description when the user performs - Update Vnic while changing the type for example. What is the behavior if we succeed to unplug but not plug after that, etc. 5. Updated APIs section -This section is based on the fact that we pass linkstate to vdsm which is not needed IMO, so if we change that this section should be updated accordingly. 6. The EVENT section is empty, what events should be issued to audit log? I think we should have an even for update vnic and if plug/unplug is required a second event should be issued. 7. why does link state is varchar in DB? you expect to support other option in addition to up/Down (which can be represented by 1 bit), maybe n/a status? 8. About the open issues- * About deprecation of ActivateDeactivateVmNic command - I think that we should remove this command from the backend to avoid duplicate flows and bugs etc. for Backwards compatibility we should update the clients to use the new UpdateVmNetworkInterface. the down side for that is we have to make the can do action validation more complicated (according to cluster level etc.) * If we remove ActivateDeactivateVmNic there is no need to rename it ;) Thanks, Livnat

12 years

3
2
0 / 0

[Engine-devel] Network Wiring

by Alona Kaplan

Hi all, Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/NetworkWiring Thanks, Alona.

12 years

9
23
0 / 0

[Engine-devel] [Jenkins] outage

by Eyal Edri

fyi, due to an outage and network issues jenkins.ovirt.org was restarted. failing jobs should now return to normal state. Eyal Edri. oVirt Infra Team

12 years

1
0
0 / 0

[Engine-devel] [Engine-Devel] OvfDataUpdater

by Liron Aravot

starting a new discussion thread. ----- Original Message ----- > From: "Mike Kolesnik" <mkolesni(a)redhat.com> > To: "Liron Aravot" <laravot(a)redhat.com> > Sent: Monday, November 19, 2012 12:42:10 PM > Subject: Re: [Engine-devel] OvfAutoUpdater > > I think 'version' is a more standard term for the column names. > > Also in: 4. If succesfull - for each vm update the ovf_generation to > equal the db_generation. > I think you mean that the update should be to the entity version you > initially selected. > > Regards, > Mike > > ----- Original Message ----- > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater > > > > Hi all, i'll be glad if you could review the wiki page of > > OvfAutoUpdater, if you have any suggestions or ideas please let me > > know. > > > > http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater > > > > short preview from the wiki: > > vm/template configurations (including disks info) are stored on the > > master storage domain for backup purposes, import/export and also > > to > > provide the abillity to run VMs without having a running engine/db. > > Currently ovf update is done synchronously when performing various > > operations on vms/templates - update, save, adding/removing a disk, > > etc. What's more, currently updating the ovf (updateVM vdsm call) > > is > > usually done within a transcation. > > > > The idea behined OvfAutoUpdater is to perform batch ovf update > > operations that aggregate all outstanding updates per data center. > > These updates will be done in specifed time intervals which will > > reduce XML-RPC calls and will enable the removal of this syncronous > > vdsm call from all over the code. > > > > Thanks, > > Liron Aravot. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > >

12 years

4
15
0 / 0

[Engine-devel] Managing permissions on network

by Livnat Peer

Hi All, This is a proposal for handling network permissions in oVirt. In this proposal we took the more permissive approach as we find it simple and a good starting point, we also think a more restrict approach makes the configuration of a network cumbersome for ovirt administrators. Inputs are welcomed as always... Here is an overview of the approach, for more detailed description please read the wiki page: http://wiki.ovirt.org/wiki/Feature/NetworkPermissions --------------------------------------------------------------------------- Admin ====== -> For creating a network in a data center you need to be a Superuser or a DCAdmin or a networkAdmin on the DC. -> After creating the network you can manipulate the network if you are a DCAdmin or a networkAdmin on the relevant network (or the whole DC). -> For attaching the network to cluster you need to be a networkAdmin on the network (no requirement to have permission on the cluster) -> Cluster administrator can not attach/detach a network from the cluster, the motivation for this is that as long as the network is not attached to the cluster it is not part of the cluster resources thus can not be managed by the cluster administrator. In addition once a network is attached to a cluster the cluster administrator can change the network from required to non-required for controlling the impact of the network within the cluster. -> For setting a network on the host you need to be host administrator on the host and you don't need to be network administrator. This implies that if you are a host administrator you can add/remove all the cluster networks from your host without the need for network related permissions (this is the permissive approach). User ==== -> For attaching a network to a Vnic in the VM you need to have the role of VmNetworkUser on the network and vmAdmin on the VM. -> In user portal - the list of shown network for a user will include only the list of networks the user is allowed to attach to its vnics (instead of all cluster's networks). Port-mirroring =============== -> For configuring in the VM port mirroring you need to have the role of VmAdvancedNetworkUser on the network and vmAdmin on the VM. VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to port mirroring. For all DB upgrade information and new roles/action groups please review the wiki. Thanks, Livnat & Moti

12 years

7
32
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Devel November 2012