Re: [Engine-devel] [Users] Hey everyone how do we upgrade engine?
On 13/04/12 19:59, Itamar Heim wrote: > On 04/13/2012 06:42 PM, Dominic Kaiser wrote: >> I am running 3.0.0_0001-1.6.fc16 ovirt engine and has been great! I >> appreciate Red Hat and all the support from the community on this >> project you all are awesome! >> >> I have not thought about it yet but was looking on the wiki and did not >> see how to upgrade and reninstallengine. What have been your >> experiences doing this and is it worth it? And how to do it? Sorry if >> it was posted somewhere else just let me know if there is info on this >> already. > > by running the engine-upgrade utility, though i suspect it will have to > pass some testing/bug fixes for the second release before can be used > (doing a test upgrade at that phase on your environment would help > finding issues) > We have one issue that we know of and we'll fix soon - https://bugzilla.redhat.com/show_bug.cgi?id=790303 If you are interested you can track engine-devel@ovirt.org list for updates on this in the upcoming week (or keep track of the bug status). Livnat >> >> I have had the greatest experience moving from 2 esxiservers to ovirt. >> You guys and gals rock! > thanks - nice to hear. > ___ > 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] REST session management
On 04/16/2012 03:31 PM, Geert Jansen wrote: On 04/16/2012 01:03 PM, Yaniv Kaul wrote: 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). My only objection is that you implement a draft spec and implement a header without even bothering to register it - or asking if there is such an identical-purposed header with a different name which may get registered / is already in use somewhere. This is somewhat of a red herring though. HTTP Prefer was created exactly for the purpose of indicating a preference for a certain behavior of response. Have a look at section 9.1.1 of the draft RFC for the initial preferences and you'll see the preferences that are already registered. HTTP Prefer also defines a registration process for the possible values of this header. The process requires an email to preferen...@ietf.org with a 14 day response time. The alternative to HTTP Prefer would be creating a new header (as i am not aware of any other /approved/ header that fits the bill). This requires writing an RFC and get it approved, which would take much longer, and which would likely get the comment of "Why aren't you using Prefer". I'm more worried about "persistent-auth" than 'prefer'. We could always contact the draft author (jasn...@gmail.com) and ask for his opinion. Y. Even if HTTP Prefer, for whatever reason, unexpectedly does not become a standard, i think in practice this does not impact us in any way. Regards Geert ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST session management
On 04/16/2012 04:34 PM, Yaniv Kaul wrote: The alternative to HTTP Prefer would be creating a new header (as i am not aware of any other /approved/ header that fits the bill). This requires writing an RFC and get it approved, which would take much longer, and which would likely get the comment of "Why aren't you using Prefer". I'm more worried about "persistent-auth" than 'prefer'. We could always contact the draft author (jasn...@gmail.com) and ask for his opinion. I can do this. Regards, Geert ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Floating Disks implementation in REST-API
On 04/16/2012 02:39 PM, Andrew Cathrow wrote: Is there a 3rd option based on #1 where we just detach the disk rather than detaching and deleting? That could be further extended by adding an optional delete flag This was discussed and the problem with that is that it's not backwards compatible. Current clients and ISV software expects to be able to DELETE a disk, and after that it expects that the disk is gone. If we change behavior so that DELETE becomes detach by default, then old clients when they DELETE without any flags will instead create a floating disk. Regards, Geert ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Floating Disks implementation in REST-API
- Original Message -
> From: "Ori Liel"
> To: engine-devel@ovirt.org
> Cc: "Eoghan Glynn"
> Sent: Monday, April 16, 2012 8:33:27 AM
> Subject: Re: [Engine-devel] Floating Disks implementation in REST-API
>
> I'd like us to move forward with this.
>
> The option of using 'attach' action does not exist, because, as
> Eoghan observed, we would be executing an action on an entity which
> doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no
> entity-???/attach)
>
> There are two options left on the table; let's see if we can agree on
> one of them:
>
> 1)
> POST/api/vms/{vm:id}/disks
>=>
> attach disk
>
> DELETE .../api/vms/{vm:id}/disks/{disk:id}
> true=>
> detach disk
>
> Pros: symmetrical
> Cons: risky (if user wants to detach but forgot to give parameter,
> disk will be deleted).
>
> 2)
>
> POST/api/vms/{vm:id}/disks
>=>
> attach disk
>
> DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach=>
> detach disk
>
> Pros: not dangerous
> Cons: asymmetrical, attach done like add, but detach done using
> action.
>
Is there a 3rd option based on #1 where we just detach the disk rather than
detaching and deleting?
That could be further extended by adding an optional delete flag
>
> No solution is perfect but we need to decide.
>
> 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
Re: [Engine-devel] Floating Disks implementation in REST-API
On 04/16/2012 02:33 PM, Ori Liel wrote:
I'd like us to move forward with this.
The option of using 'attach' action does not exist, because, as Eoghan
observed, we would be executing an action on an entity which doesn't exist in
the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach)
There are two options left on the table; let's see if we can agree on one of
them:
1)
POST/api/vms/{vm:id}/disks
=> attach disk
DELETE .../api/vms/{vm:id}/disks/{disk:id}
true => detach disk
Pros: symmetrical
Cons: risky (if user wants to detach but forgot to give parameter, disk will be
deleted).
My idea for that was to introduce true|false as well.
Without force=true, we won't delete a disk if it's currently floating.
I think it makes it less risky. And it is still backwards compatible, as
3.0 clients do not know how to create a floating disk, and therefore
there is no risk that they are deleting one.
Regards,
Geert
2)
POST/api/vms/{vm:id}/disks
=> attach disk
DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach=> detach disk
Pros: not dangerous
Cons: asymmetrical, attach done like add, but detach done using action.
No solution is perfect but we need to decide.
Thanks,
Ori.
--
Geert Jansen
Sr. Product Marketing Manager, Red Hat Enterprise Virtualization
Red Hat S.r.L. O: +39 095 916287
Via G. Fara 26 C: +39 348 1980079 (when in US: 415-623-0542)
Milan 20124, Italy E: gjan...@redhat.com
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Floating Disks implementation in REST-API
I'd like us to move forward with this.
The option of using 'attach' action does not exist, because, as Eoghan
observed, we would be executing an action on an entity which doesn't exist in
the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach)
There are two options left on the table; let's see if we can agree on one of
them:
1)
POST/api/vms/{vm:id}/disks
=> attach disk
DELETE .../api/vms/{vm:id}/disks/{disk:id}
true=> detach disk
Pros: symmetrical
Cons: risky (if user wants to detach but forgot to give parameter, disk will be
deleted).
2)
POST/api/vms/{vm:id}/disks
=> attach disk
DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach=> detach disk
Pros: not dangerous
Cons: asymmetrical, attach done like add, but detach done using action.
No solution is perfect but we need to decide.
Thanks,
Ori.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST session management
On 04/16/2012 01:03 PM, Yaniv Kaul wrote: 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). My only objection is that you implement a draft spec and implement a header without even bothering to register it - or asking if there is such an identical-purposed header with a different name which may get registered / is already in use somewhere. This is somewhat of a red herring though. HTTP Prefer was created exactly for the purpose of indicating a preference for a certain behavior of response. Have a look at section 9.1.1 of the draft RFC for the initial preferences and you'll see the preferences that are already registered. HTTP Prefer also defines a registration process for the possible values of this header. The process requires an email to preferen...@ietf.org with a 14 day response time. The alternative to HTTP Prefer would be creating a new header (as i am not aware of any other /approved/ header that fits the bill). This requires writing an RFC and get it approved, which would take much longer, and which would likely get the comment of "Why aren't you using Prefer". Even if HTTP Prefer, for whatever reason, unexpectedly does not become a standard, i think in practice this does not impact us in any way. Regards Geert ___ 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: "Yaniv Kaul" > To: "Oved Ourfalli" > Cc: "engine-devel" , "Eoghan Glynn" > > Sent: Monday, April 16, 2012 2:03:26 PM > Subject: Re: [Engine-devel] REST session management > > On 04/16/2012 11:44 AM, Oved Ourfalli wrote: > > > > - Original Message - > >> From: "Geert Jansen" > >> To: "Miki Kenneth" > >> Cc: "Oved Ourfalli", > >> "engine-devel", "Eoghan > >> Glynn" > >> 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). > > My only objection is that you implement a draft spec and implement a > header without even bothering to register it - or asking if there is > such an identical-purposed header with a different name which may get > registered / is already in use somewhere. > Y. > One of the reasons of posting to this mailing list is to try and get information on alternatives. I already looked for similar headers, but I'll take another look to see if others exist. Any idea where I can get an official answer for that? Looked in http://www.iana.org/assignments/message-headers/perm-headers.html, but it was hard to find a more suitable header there. We can have a dedicated header of our own in that matter, but better being standard. BTW, from what I read the acceptance process is in its final stages, but I'm not too familiar with the process, so hard to say how much time will it take for it to be complete. > > > > Thank you, > > Oved > >> Regards, > >> Geert > >> > > ___ > > 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] REST session management
On 04/16/2012 11:44 AM, Oved Ourfalli wrote: - Original Message - From: "Geert Jansen" To: "Miki Kenneth" Cc: "Oved Ourfalli", "engine-devel", "Eoghan Glynn" 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). My only objection is that you implement a draft spec and implement a header without even bothering to register it - or asking if there is such an identical-purposed header with a different name which may get registered / is already in use somewhere. Y. Thank you, Oved Regards, Geert ___ 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" > To: "Miki Kenneth" > Cc: "Oved Ourfalli" , "engine-devel" > , "Eoghan Glynn" > 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] 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. Regards, Geert ___ 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: "Oved Ourfalli" > To: "Geert Jansen" > Cc: "engine-devel" , "Eoghan Glynn" > > Sent: Monday, April 16, 2012 10:44:31 AM > Subject: Re: [Engine-devel] REST session management > > > > - Original Message - > > From: "Geert Jansen" > > To: "Oved Ourfalli" > > Cc: "engine-devel" , "Eoghan Glynn" > > > > Sent: Monday, April 16, 2012 10:26:18 AM > > Subject: Re: [Engine-devel] REST session management > > > > Hi Oved, > > > > +1 for this feature. > > > > [[As a background to the others on the list, this feature is > > absolutely > > essential for certain types of ISV integration. Many ISVs need to > > mirror > > the RHEV inventory (i.e. all VMs, clusters, basically any object > > managed > > by RHEV) in realtime to their own database. The way they do this > > currently is by polling /api/events and look for changes. In order > > to > > be > > able to react to changes fast, they typically poll every 5 seconds. > > The > > query itself is very efficient, so it doesn't cause a whole lot of > > load > > on RHEV-M. But it floods the log with login/logout events. This > > persistent session feature is a solution for that.]] > > > Thank you for the background. I'll add it to the wiki page. > > > Actually my vote would go for your variation #2: > > > > The client passes the "Prefer" header field on every request, > > besides the last one. When the server gets a request with a > > JSESSIONID, and without the "Prefer" header, it logs out the > > session. > > > > It's mostly my gut feeling, but i would say it has these > > advantages: > > > > 1. It is more explicit, as on every request you confirm that you > > still > > want the authenticated session to be maintained. > > 2. It is also consistent with the default we have chosen of no > > persistent authentication. > > 3. It does not need a second header, so it is somewhat simpler. > > > > 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) > The only doubt I have about that is that from reading on the new > "Prefer" header, I got the feeling that it is more relevant on > session negotiation, and less something you would pass on every > request in the session, but I'm not sure about that. > > > Regards, > > Geert > > > > On 04/15/2012 01:06 PM, Oved Ourfalli wrote: > > > Hey, > > > > > > The following wiki page describes a new feature - supporting > > > session management via the REST API: > > > http://www.ovirt.org/wiki/Features/RESTSessionManagement > > > > > > Please review and comment. > > > > > > Thank you, > > > Oved > > > > -- > > Geert Jansen > > Sr. Product Marketing Manager, Red Hat Enterprise Virtualization > > > > Red Hat S.r.L. O: +39 095 916287 > > Via G. Fara 26 C: +39 348 1980079 (when in US: > > 415-623-0542) > > Milan 20124, Italy E: gjan...@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] REST session management
- Original Message - > From: "Geert Jansen" > To: "Oved Ourfalli" > Cc: "engine-devel" , "Eoghan Glynn" > > Sent: Monday, April 16, 2012 10:26:18 AM > Subject: Re: [Engine-devel] REST session management > > Hi Oved, > > +1 for this feature. > > [[As a background to the others on the list, this feature is > absolutely > essential for certain types of ISV integration. Many ISVs need to > mirror > the RHEV inventory (i.e. all VMs, clusters, basically any object > managed > by RHEV) in realtime to their own database. The way they do this > currently is by polling /api/events and look for changes. In order to > be > able to react to changes fast, they typically poll every 5 seconds. > The > query itself is very efficient, so it doesn't cause a whole lot of > load > on RHEV-M. But it floods the log with login/logout events. This > persistent session feature is a solution for that.]] > Thank you for the background. I'll add it to the wiki page. > Actually my vote would go for your variation #2: > > The client passes the "Prefer" header field on every request, > besides the last one. When the server gets a request with a > JSESSIONID, and without the "Prefer" header, it logs out the > session. > > It's mostly my gut feeling, but i would say it has these advantages: > > 1. It is more explicit, as on every request you confirm that you > still > want the authenticated session to be maintained. > 2. It is also consistent with the default we have chosen of no > persistent authentication. > 3. It does not need a second header, so it is somewhat simpler. > 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. The only doubt I have about that is that from reading on the new "Prefer" header, I got the feeling that it is more relevant on session negotiation, and less something you would pass on every request in the session, but I'm not sure about that. > Regards, > Geert > > On 04/15/2012 01:06 PM, Oved Ourfalli wrote: > > Hey, > > > > The following wiki page describes a new feature - supporting > > session management via the REST API: > > http://www.ovirt.org/wiki/Features/RESTSessionManagement > > > > Please review and comment. > > > > Thank you, > > Oved > > -- > Geert Jansen > Sr. Product Marketing Manager, Red Hat Enterprise Virtualization > > Red Hat S.r.L. O: +39 095 916287 > Via G. Fara 26 C: +39 348 1980079 (when in US: > 415-623-0542) > Milan 20124, Italy E: gjan...@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] REST session management
Hi Oved, +1 for this feature. [[As a background to the others on the list, this feature is absolutely essential for certain types of ISV integration. Many ISVs need to mirror the RHEV inventory (i.e. all VMs, clusters, basically any object managed by RHEV) in realtime to their own database. The way they do this currently is by polling /api/events and look for changes. In order to be able to react to changes fast, they typically poll every 5 seconds. The query itself is very efficient, so it doesn't cause a whole lot of load on RHEV-M. But it floods the log with login/logout events. This persistent session feature is a solution for that.]] Actually my vote would go for your variation #2: The client passes the "Prefer" header field on every request, besides the last one. When the server gets a request with a JSESSIONID, and without the "Prefer" header, it logs out the session. It's mostly my gut feeling, but i would say it has these advantages: 1. It is more explicit, as on every request you confirm that you still want the authenticated session to be maintained. 2. It is also consistent with the default we have chosen of no persistent authentication. 3. It does not need a second header, so it is somewhat simpler. Regards, Geert On 04/15/2012 01:06 PM, Oved Ourfalli wrote: Hey, The following wiki page describes a new feature - supporting session management via the REST API: http://www.ovirt.org/wiki/Features/RESTSessionManagement Please review and comment. Thank you, Oved -- Geert Jansen Sr. Product Marketing Manager, Red Hat Enterprise Virtualization Red Hat S.r.L. O: +39 095 916287 Via G. Fara 26 C: +39 348 1980079 (when in US: 415-623-0542) Milan 20124, Italy E: gjan...@redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
