On Fri, Mar 22, 2013 at 10:14 AM, 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. Chip, good point. There is a bug to track the release notes effort. I added this as a comment in that bug. https://issues.apache.org/jira/browse/CLOUDSTACK-1102 Jessica T. > 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? >
