This would also have to provide some info as to what constitutes a smaller disk offering (then, I suppose, the GUI would use that info to compare the current offering against the proposed offering).
On Thu, Aug 14, 2014 at 4:51 AM, John Dilley <john.dil...@citrix.com> wrote: > A common way to deal with this is to have a supported operations field, > that the UI can read – one such operation would be “shrink volume”, and if > this was not present, the UI could prevent you from choosing a smaller disk > offering. > > > > It would keep the business logic (e.g. “XenServer does not support > shrinking a volume”) in Cloudstack, but give a better experience to the > user. It perhaps isn’t worth putting such logic into cloudstack if that > doesn’t get passed up to the UI – all it would save you would be an API > call to XenServer, and perhaps give you a nicer error message. The real > benefit would be to put it in the UI to present the user only with valid > options – but without the UI needing to work out for itself whether a > volume can be shrunk. > > > > John > > > > > > *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > *Sent:* 14 August 2014 02:57 > *To:* dev@cloudstack.apache.org > *Cc:* John Dilley > > *Subject:* Re: Regarding Shrinking of Volume > > > > As an example, I will note that the GUI submits requests to the management > server that it could - in theory - validate locally. > > > > However, the GUI is (rightly) intended in CloudStack to be a thin layer on > top of the API. It purposefully avoids duplicating business logic that is > run on the backend (even though this design requires that more processing > be done). > > > > On Wed, Aug 13, 2014 at 7:54 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > > That's an interesting question you raise about failing fast. > > > > On the one hand, it's nice from a usability standpoint. > > > > On the other, it adds in additional business logic (the API layer would > then have business logic that is duplicated on the XenServer side). > > > > On Wed, Aug 13, 2014 at 6:40 PM, Nitin Mehta <nitin.me...@citrix.com> > wrote: > > I think there are 2 bugs here > Api level - If shrinking is not allowed say in XS it should fail fast and > say that strinking is not allowed in XS rather than going through the > resource layer and trying the operation and getting the error from XS. > Test case - I would modify the test case to expect success when shrinking > is supported and anticipate exception where ever not. > > Thanks, > -Nitin > > On 13/08/14 2:32 PM, "Chandan Purushothama" > > <chandan.purushoth...@citrix.com> wrote: > > >Thanks Marcus, John & Mike for all the information, > > > >FS at > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Resize+Data+Volumes > > claims that XenServer can shrink data volumes. Can I edit it and remove > >that claim from FS? Kindly let me know, > > > >Thank you, > >Chandan. > > > >-----Original Message----- > >From: Marcus [mailto:shadow...@gmail.com] > >Sent: Wednesday, August 13, 2014 1:12 PM > >To: John Dilley > >Cc: <dev@cloudstack.apache.org> > >Subject: Re: Regarding Shrinking of Volume > > > >If you're asking what I think, it would be RAW. The pool type would be > >CLVM, though. This is probably a better solution, as we likely want to > >grow the cases that the automated tests run. If we're testing KVM at all > >it is trivial to set up an LVM volume group as a storage pool to test > >against. > > > > > >On Wed, Aug 13, 2014 at 2:04 PM, John Dilley <john.dil...@citrix.com> > >wrote: > > > >> Hi, > >> > >> I'll put a condition around the block that does the shrinking only in > >> the case of CLVM. Would the disk image type be "CLVM" instead of > >>"qcow2"? > >> > >> Thanks, > >> > >> John > >> > >> > On 13 Aug 2014, at 20:39, "Mike Tutkowski" > >> > <mike.tutkow...@solidfire.com> > >> wrote: > >> > > >> > This is how Marcus responded: > >> > > >> > Yes, this is true. Ideally other storage maintainers/drivers would > >> > implement it as well, but we only committed a test for shrinking > >> > clvm > >> (over > >> > a year ago now). I'd like to keep the test itself to run regression > >> against > >> > clvm, but since this test is being used now for some continuous > >> integration > >> > or other automated testing. Perhaps it can be split out or only run > >> > in applicable situations, perhaps make a copy of the file that > >> > doesn't run during your automation, but can be run by others who > >> > want to test > >> shrinking > >> > on their storage type. > >> > > >> > > >> > On Wed, Aug 13, 2014 at 1:05 PM, Chandan Purushothama < > >> > chandan.purushoth...@citrix.com> wrote: > >> > > >> >> Marcus, > >> >> > >> >> May I know your response, > >> >> > >> >> Thank you, > >> >> Chandan. > >> >> > >> >> -----Original Message----- > >> >> From: Chandan Purushothama [mailto:chandan.purushoth...@citrix.com] > >> >> Sent: Tuesday, August 12, 2014 12:37 PM > >> >> To: Marcus > >> >> Cc: dev@cloudstack.apache.org > >> >> Subject: Regarding Shrinking of Volume > >> >> > >> >> Hello Marcus, > >> >> > >> >> I see that shrinking of volume is not supported by XenServer > >> >> (CLOUDSTACK-7228) . May I know whether KVM with CLVM Data Volumes > >> >> is the only configuration that supports shrinking of data volume? > >> >> If Yes, May I know if the corresponding test case that shrinks data > >> >> disks be removed > >> from > >> >> smoke/test_volumes.py (https://reviews.apache.org/r/24615/). Please > >> >> let me know, > >> >> > >> >> Thank you, > >> >> Chandan. > >> > > >> > > >> > > >> > -- > >> > *Mike Tutkowski* > >> > *Senior CloudStack Developer, SolidFire Inc.* > >> > e: mike.tutkow...@solidfire.com > >> > o: 303.746.7302 > >> > Advancing the way the world uses the cloud > >> > <http://solidfire.com/solution/overview/?video=play>* * > >> > > > > > > -- > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > > > > > > -- > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
