On Fri, Mar 22, 2013 at 1:14 PM, Chip Childers <chip.child...@sungard.com> wrote: > On Fri, Mar 22, 2013 at 10:06:26AM -0700, Animesh Chaturvedi wrote: >> >> >> On Mar 22, 2013, at 9:57 AM, "Chip Childers" <chip.child...@sungard.com> >> wrote: >> >> > On Fri, Mar 22, 2013 at 09:50:38AM -0700, Animesh Chaturvedi wrote: >> >> >> >> >> >> Thanks >> >> Animesh >> >> >> >> On Mar 22, 2013, at 9:27 AM, "Chip Childers" <chip.child...@sungard.com> >> >> wrote: >> >> >> >>> On Thu, Mar 21, 2013 at 06:03:49PM -0700, Animesh Chaturvedi wrote: >> >>>> 2. Add Cluster >> >>>> - Baremetal show up in list of hypervisors. This is coming from >> >>>> listHypervisors command >> >>>> >> >>>> How to fix: This comes from the file >> >>>> server/src/com/cloud/configuration/ Config.java in property " >> >>>> hypervisor.list" and is pulled from Database table "Configuration". >> >>>> >> >>>> How to fix. : removing the BareMetal from hypervisors.list property in >> >>>> Config.java will fix it for fresh installs. This will fix the fresh >> >>>> install but to fix it for upgrade we need to fix the upgrade sql data >> >>>> files. I am not sure if we should fix this I am not clear on upgrade >> >>>> concerns? Alex/Chip any comments. >> >>> >> >>> Help me understand this one. Is there data in a table somewhere for >> >>> pre-4.1 released versions? >> >> >> >> Yes the Configuration database table has an attribute hypervisors.list >> >> and the value for that attribute is comma separated list of supported >> >> hypervisors, and includes 'BareMetal'. No Schema change is needed. Fix is >> >> to remove 'BareMetal' from attribute value. >> >> >> >> I do not have enough history to make a call how important is to fix it. >> >> The fix is trivial. >> > >> > OK, so it was in that table as part of the previous baremetal >> > "experimental" feature? >> Yes >> > >> > In that case, can I also assume that there's no impact to the data being >> > in the table? >> >> If we let 'BareMetal' in the table it will be returned in listHypervisors >> API call and UI will show it in Add Cluster screen for upgrade from 4.0 -4.1 > > So what we are *REALLY* talking about here, is that an experimental > feature from past releases was modified for 4.1 but is broken completely > now. > > IMO we need to do 2 things. First, we *must* document that the > experimental feature from past releases is not in 4.1 in the release > notes. Second, yes, we should remove it from the DB. > > Basically, nobody is going to be able to use it if they install the > code, right? So if they do use bare metal from a prior version, I > certainly hope that they don't upgrade to 4.1 (given the state of the > feature). > > Anyone else have a thought?
So here are my raw thoughts. Take them for what you will. We have a feature that IMO is a pretty big deal, akin to hypervisor support. We've had similar issues with OVM in the past. Perhaps we need to be looking at whether such massive features are sustainable. In this case (as with OVM) no one cared enough to fix the problems and it fell into disrepair, and rather than the community making an informed decision to discontinue support for a feature and phase support out over time, our hand is forced when QA finds issues. Writing the software initially is easier than the long term maintenance, and given that we've dropped a 'hypervisor' every release, I am wondering if we don't need to reject some of these efforts outright if there is doubt as to sustainability.
