Howdy, Just wanted to give you a heads up of where I''m blocked right now. I''ve made the changes Ewan requested but am not able to regress because of a large amount of failures in xm-test. All of the block attach/detach tests are failing (in normal unstable). I was hoping the problems would just go away but they haven''t in tip. I''m going to look into those problems tomorrow and see if I can figure out where we broke. When I brought this up last week these failures were confirmed by others so I don''t think it''s just me. Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Mar 20, 2006 at 10:39:13AM -0600, Anthony Liguori wrote:> Howdy, > > Just wanted to give you a heads up of where I''m blocked right now. I''ve > made the changes Ewan requested but am not able to regress because of a > large amount of failures in xm-test. All of the block attach/detach > tests are failing (in normal unstable). I was hoping the problems would > just go away but they haven''t in tip. > > I''m going to look into those problems tomorrow and see if I can figure > out where we broke. When I brought this up last week these failures > were confirmed by others so I don''t think it''s just me.Could you send your patches through anyway? I''ll start some tests at this end too. If you don''t want to send them through the list until you''ve got a clean regression test result, that''s fine, but I can get a regression test running here too, either way. Did you give any more thought to error handling? The version you sent out didn''t do any rerouting of exceptions, so if VmError or XendError was raised, that turned into ProtocolError, which gives a revolting splat at the client. I think that the best thing to do is to catch those exceptions at the server and turn them into generic Faults, and then after 3.0.2 is out we can shuffle through turning the VmError or XendErrors into more specific Faults with proper error codes etc. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor wrote:> On Mon, Mar 20, 2006 at 10:39:13AM -0600, Anthony Liguori wrote: > > Could you send your patches through anyway? I''ll start some tests at this end > too. If you don''t want to send them through the list until you''ve got a > clean regression test result, that''s fine, but I can get a regression test > running here too, either way. >Yeah, I''ll submit it this afternoon once I head into the office. Once I saw 2.6.16, I realized we''re out of time :-) I hope we can fix the xm-test regressions though before 3.0.2...> Did you give any more thought to error handling? The version you sent out > didn''t do any rerouting of exceptions, so if VmError or XendError was raised, > that turned into ProtocolError, which gives a revolting splat at the client. > I think that the best thing to do is to catch those exceptions at the server > and turn them into generic Faults, and then after 3.0.2 is out we can shuffle > through turning the VmError or XendErrors into more specific Faults with > proper error codes etc. >Yeah, I just allocated a faultcode for VmError and XendError and handled those specifically. In general, we could probably an exception to faultcode mapping and pick up the common exceptions (OSError etc.) but for now I just special case it. Regards, Anthony Liguori> Cheers, > > Ewan. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
First off, xm-test is not passing 100%. The failures are all block related and I''ve looked at each one and it appears to die for the same reason the control runs are dying for (unable to very partition is mounted with /proc/partitions). Every time I run xm-test, I get different results (in the control) so it''s hard to know for sure if this introduces additional block regressions but I don''t think it does. Everything else passes consistently. I actually went ahead and made VmError and XendError inherit from xmlrpc.Fault which means they show up for the client as you''d expect. I''m submitting this so that others can pound on it. I''ll keep looking at the block failures to see if we can''t fix that too. It''s all one big patch since with the changes Ewan requested, it''s not so easy to separate anymore. Regards, Anthony Liguori Ewan Mellor wrote:> On Mon, Mar 20, 2006 at 10:39:13AM -0600, Anthony Liguori wrote: > > >> Howdy, >> >> Just wanted to give you a heads up of where I''m blocked right now. I''ve >> made the changes Ewan requested but am not able to regress because of a >> large amount of failures in xm-test. All of the block attach/detach >> tests are failing (in normal unstable). I was hoping the problems would >> just go away but they haven''t in tip. >> >> I''m going to look into those problems tomorrow and see if I can figure >> out where we broke. When I brought this up last week these failures >> were confirmed by others so I don''t think it''s just me. >> > > Could you send your patches through anyway? I''ll start some tests at this end > too. If you don''t want to send them through the list until you''ve got a > clean regression test result, that''s fine, but I can get a regression test > running here too, either way. > > Did you give any more thought to error handling? The version you sent out > didn''t do any rerouting of exceptions, so if VmError or XendError was raised, > that turned into ProtocolError, which gives a revolting splat at the client. > I think that the best thing to do is to catch those exceptions at the server > and turn them into generic Faults, and then after 3.0.2 is out we can shuffle > through turning the VmError or XendErrors into more specific Faults with > proper error codes etc. > > Cheers, > > Ewan. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Mar 21, 2006 at 05:40:05PM -0600, Anthony Liguori wrote:> First off, xm-test is not passing 100%. The failures are all block > related and I''ve looked at each one and it appears to die for the same > reason the control runs are dying for (unable to very partition is > mounted with /proc/partitions). Every time I run xm-test, I get > different results (in the control) so it''s hard to know for sure if this > introduces additional block regressions but I don''t think it does. > > Everything else passes consistently. I actually went ahead and made > VmError and XendError inherit from xmlrpc.Fault which means they show up > for the client as you''d expect. > > I''m submitting this so that others can pound on it. I''ll keep looking at > the block failures to see if we can''t fix that too. It''s all one big > patch since with the changes Ewan requested, it''s not so easy to > separate anymore.Neither of the new files (XMLRPCServer.py and xmlrpclib2.py) have made it into this patch. Could you resubmit? Thanks, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor wrote:> On Tue, Mar 21, 2006 at 05:40:05PM -0600, Anthony Liguori wrote: > > >> First off, xm-test is not passing 100%. The failures are all block >> related and I''ve looked at each one and it appears to die for the same >> reason the control runs are dying for (unable to very partition is >> mounted with /proc/partitions). Every time I run xm-test, I get >> different results (in the control) so it''s hard to know for sure if this >> introduces additional block regressions but I don''t think it does. >> >> Everything else passes consistently. I actually went ahead and made >> VmError and XendError inherit from xmlrpc.Fault which means they show up >> for the client as you''d expect. >> >> I''m submitting this so that others can pound on it. I''ll keep looking at >> the block failures to see if we can''t fix that too. It''s all one big >> patch since with the changes Ewan requested, it''s not so easy to >> separate anymore. >> > > Neither of the new files (XMLRPCServer.py and xmlrpclib2.py) have made it into > this patch. Could you resubmit? Thanks, >Sorry, when I was collapsing to a single changeset I forgot to hg addremove. New patch attached. Regards, Anthony Liguori> Ewan. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Mar 21, 2006 at 06:08:47PM -0600, Anthony Liguori wrote:> Ewan Mellor wrote: > >On Tue, Mar 21, 2006 at 05:40:05PM -0600, Anthony Liguori wrote: > > > > > >>First off, xm-test is not passing 100%. The failures are all block > >>related and I''ve looked at each one and it appears to die for the same > >>reason the control runs are dying for (unable to very partition is > >>mounted with /proc/partitions). Every time I run xm-test, I get > >>different results (in the control) so it''s hard to know for sure if this > >>introduces additional block regressions but I don''t think it does. > >> > >>Everything else passes consistently. I actually went ahead and made > >>VmError and XendError inherit from xmlrpc.Fault which means they show up > >>for the client as you''d expect. > >> > >>I''m submitting this so that others can pound on it. I''ll keep looking at > >>the block failures to see if we can''t fix that too. It''s all one big > >>patch since with the changes Ewan requested, it''s not so easy to > >>separate anymore. > >> > > > >Neither of the new files (XMLRPCServer.py and xmlrpclib2.py) have made it > >into > >this patch. Could you resubmit? Thanks, > > > > Sorry, when I was collapsing to a single changeset I forgot to hg > addremove. New patch attached.Applied, as you''ve no doubt seen by now. Thanks for all your hard work, Anthony, and thanks to IBM too. For 3.0.2, we now need to find that bug that''s affecting your block devices (I''m not seeing that regression here, so if it''s still affecting you, then some aggressive debugging is in order!). Then, we just need to get everyone to hit the new XML-RPC layer, shake out any remaining bugs, and we''re good to go, I think. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel