Re: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?
I like, thanks for starting this discussion. Please ignore the rest of this mail as it is not of any consequence. As a folowup, I would like ti propose to move any peace of code to branches if it meets the qualifications you mention; not (full) functional, not production ready. And i would like to add not fully tested an not fully tested. Ofcourse we can only migrate in that dirrection, unfortunately. As a newbee on this codebase it would help a lot knowing that any code on master is actually functional. Meaning that coveragetests could help. This is me@devchair talking, i will probably be countered by collegues having real user issues. This is also an incentive to document and test, for those rhat want to guard their niche functionality and an incentive to isolate code for easy cherrypicking whilst not done. Hi all, So we've run into a couple of features that have turned out to have never really been "production grade", perhaps due to their creation as prototypes during the cloud.com startup period. Swift, Bare metal provisioning and OVM are examples. Bare metal is obviously resolved now, but Swift is an open discussion and OVM remains open for someone to decide to fix it. I'd like to propose that those devs that have been around this code-base from before it's entry into Apache take some time to review things from the past. What else is lurking in the repo that some of us might *think* are functional, but that haven't been tested in years? What code was a prototype that never got fully implemented / supported? If we can get all this out in the open, perhaps we can have a solid foundation to move forward. On the other hand, if nobody has any examples beyond the ones listed below, then I think that those of us that are relatively new to the code will have to work under the assumption that everything is expected to be functional. After we establish our foundation, we will need to be very consistent about our support of the features. We'll need to be clear about intentions to deprecate something, and perhaps even provide a full feature release cycle worth of warning about a pending deprecation. As a user, I not been stung by a feature that was yanked... but I was certainly surprised when I found out that OVM and Bare Metal weren't being kept up to date (again, bare metal is resolved now). Those features were part of our evaluation of the software, and me $dayjob has plans to at least use bare metal. So why did I share that little story? Well, it's because features coming and going are actually significant events to users of the software. Just because we don't know of someone using a feature doesn't mean that it isn't in use. I'd like us to have that solid foundation as a start, and then be very clear when we need/want to make a decision that removes a feature from the software. -chip
RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?
Thanks Chip for starting this thread. I can at least think of the netapp plugin integration as something that was tried before ASF but no longer tested and used. I'm all for coming up with this list but I don't see how this list can be conclusive. The problem that Edison dealt with in swift support is very real. I'm not trying to make an excuse for making a unilateral decision to drop support without getting community feedback first. That is wrong and I'm glad it's being resolved. However, without automated testing backing functionality, we can have different set of these problems pop up every release. Should we start with only functionalities tested in automated testing to be the supported feature set and add features back in as more testing is added back in? To that end, how much of 4.0/4.1/4.2 features are actually added to automated testing? Or else we can face the same problem with those features too. I still support gathering this list, even if it might be inconclusive. --Alex > -Original Message- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Wednesday, July 10, 2013 6:23 AM > To: dev@cloudstack.apache.org > Subject: [DISCUSS] What other "features" or code is sitting around that might > be suffering from bit rot? > > Hi all, > > So we've run into a couple of features that have turned out to have never > really been "production grade", perhaps due to their creation as prototypes > during the cloud.com startup period. Swift, Bare metal provisioning and > OVM are examples. Bare metal is obviously resolved now, but Swift is an > open discussion and OVM remains open for someone to decide to fix it. > > I'd like to propose that those devs that have been around this code-base > from before it's entry into Apache take some time to review things from the > past. What else is lurking in the repo that some of us might > *think* are functional, but that haven't been tested in years? What code > was a prototype that never got fully implemented / supported? > > If we can get all this out in the open, perhaps we can have a solid foundation > to move forward. > > On the other hand, if nobody has any examples beyond the ones listed > below, then I think that those of us that are relatively new to the code will > have to work under the assumption that everything is expected to be > functional. > > After we establish our foundation, we will need to be very consistent about > our support of the features. We'll need to be clear about intentions to > deprecate something, and perhaps even provide a full feature release cycle > worth of warning about a pending deprecation. > > As a user, I not been stung by a feature that was yanked... but I was > certainly > surprised when I found out that OVM and Bare Metal weren't being kept up > to date (again, bare metal is resolved now). Those features were part of our > evaluation of the software, and me $dayjob has plans to at least use bare > metal. > > So why did I share that little story? Well, it's because features coming and > going are actually significant events to users of the software. Just because > we don't know of someone using a feature doesn't mean that it isn't in use. > I'd like us to have that solid foundation as a start, and then be very clear > when we need/want to make a decision that removes a feature from the > software. > > -chip
Re: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?
On Wed, Jul 10, 2013 at 08:44:24PM +, Alex Huang wrote: > Thanks Chip for starting this thread. > > I can at least think of the netapp plugin integration as something that was > tried before ASF but no longer tested and used. > Awesome, that's one. Any others? > I'm all for coming up with this list but I don't see how this list can be > conclusive. The problem that Edison dealt with in swift support is very > real. I'm not trying to make an excuse for making a unilateral decision to > drop support without getting community feedback first. That is wrong and I'm > glad it's being resolved. However, without automated testing backing > functionality, we can have different set of these problems pop up every > release. Should we start with only functionalities tested in automated > testing to be the supported feature set and add features back in as more > testing is added back in? > > To that end, how much of 4.0/4.1/4.2 features are actually added to automated > testing? Or else we can face the same problem with those features too. > > I still support gathering this list, even if it might be inconclusive. I agree with your points above, but think that we need to take this step by step. Let's figure out what code isn't actually in shape, based on historical understanding first. We then at least have a target to ask the next question: what's covered by testing (automated or manual) for each feature release? Then we have a list of areas to focus on for automated testing. > > --Alex
Re: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?
On Jul 10, 2013, at 5:06 PM, Chip Childers wrote: > On Wed, Jul 10, 2013 at 08:44:24PM +, Alex Huang wrote: >> Thanks Chip for starting this thread. >> >> I can at least think of the netapp plugin integration as something that was >> tried before ASF but no longer tested and used. >> > > Awesome, that's one. Any others? The S3 interface in awsapi ? > >> I'm all for coming up with this list but I don't see how this list can be >> conclusive. The problem that Edison dealt with in swift support is very >> real. I'm not trying to make an excuse for making a unilateral decision to >> drop support without getting community feedback first. That is wrong and >> I'm glad it's being resolved. However, without automated testing backing >> functionality, we can have different set of these problems pop up every >> release. Should we start with only functionalities tested in automated >> testing to be the supported feature set and add features back in as more >> testing is added back in? >> >> To that end, how much of 4.0/4.1/4.2 features are actually added to >> automated testing? Or else we can face the same problem with those features >> too. >> >> I still support gathering this list, even if it might be inconclusive. > > I agree with your points above, but think that we need to take this step > by step. Let's figure out what code isn't actually in shape, based on > historical understanding first. We then at least have a target to ask > the next question: what's covered by testing (automated or manual) for > each feature release? Then we have a list of areas to focus on for > automated testing. > >> >> --Alex
RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?
> -Original Message- > From: Sebastien Goasguen [mailto:run...@gmail.com] > Sent: Wednesday, July 10, 2013 3:38 PM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] What other "features" or code is sitting around that > might be suffering from bit rot? > > > On Jul 10, 2013, at 5:06 PM, Chip Childers > wrote: > > > On Wed, Jul 10, 2013 at 08:44:24PM +, Alex Huang wrote: > >> Thanks Chip for starting this thread. > >> > >> I can at least think of the netapp plugin integration as something that was > tried before ASF but no longer tested and used. > >> > > > > Awesome, that's one. Any others? > > The S3 interface in awsapi ? > AFAIK, awsapi was EC2 only. Prachi? --Alex
RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?
Code for S3 API is lying under awsapi project. Only EC2 API under awsapi is functionally tested. -Original Message- From: Alex Huang Sent: Wednesday, July 10, 2013 3:40 PM To: dev@cloudstack.apache.org Cc: Prachi Damle Subject: RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot? > -Original Message- > From: Sebastien Goasguen [mailto:run...@gmail.com] > Sent: Wednesday, July 10, 2013 3:38 PM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] What other "features" or code is sitting around > that might be suffering from bit rot? > > > On Jul 10, 2013, at 5:06 PM, Chip Childers > wrote: > > > On Wed, Jul 10, 2013 at 08:44:24PM +, Alex Huang wrote: > >> Thanks Chip for starting this thread. > >> > >> I can at least think of the netapp plugin integration as something > >> that was > tried before ASF but no longer tested and used. > >> > > > > Awesome, that's one. Any others? > > The S3 interface in awsapi ? > AFAIK, awsapi was EC2 only. Prachi? --Alex
RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?
> > I agree with your points above, but think that we need to take this step by > step. Let's figure out what code isn't actually in shape, based on historical > understanding first. We then at least have a target to ask the next question: > what's covered by testing (automated or manual) for each feature release? > Then we have a list of areas to focus on for automated testing. > Agreed. I guess I'm just thinking ahead given that this thread is already started. Here's some more I can think of: CloudZones implementation which allows someone to deploy a zone in their own data center but uses a hosted management server to manage it. Local Storage based secondary storage which uses available local storage in the hypervisor host for secondary storage. HyperV prototype (Not the new one that Donal is working on) Cifs based secondary storage as part of the HyperV work --Alex
RE: [DISCUSS] What other "features" or code is sitting around that might be suffering from bit rot?
Hyper-V cruft: 4.0 code claiming to support Hyper-V in the SystemVM, database, server code, and agent code predates Apache. That said, these files and snippets are being swapped out for working versions in Master. Moreover, a user cannot the code I'm referring to. DL > -Original Message- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: 11 July 2013 12:13 AM > To: dev@cloudstack.apache.org > Subject: RE: [DISCUSS] What other "features" or code is sitting around that > might be suffering from bit rot? > > > > > I agree with your points above, but think that we need to take this > > step by step. Let's figure out what code isn't actually in shape, > > based on historical understanding first. We then at least have a target to > ask the next question: > > what's covered by testing (automated or manual) for each feature release? > > Then we have a list of areas to focus on for automated testing. > > > > Agreed. I guess I'm just thinking ahead given that this thread is already > started. > > Here's some more I can think of: > > CloudZones implementation which allows someone to deploy a zone in their > own data center but uses a hosted management server to manage it. > Local Storage based secondary storage which uses available local storage in > the hypervisor host for secondary storage. > HyperV prototype (Not the new one that Donal is working on) Cifs based > secondary storage as part of the HyperV work > > --Alex
