You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Hugo Trippaers <HT...@schubergphilis.com> on 2012/09/06 19:01:37 UTC
[DISCUSS] how about components.xml
Hey,
While testing the my fresh RPMs I ran into some trouble starting the management server. The components.xml.in file references the elements and classes for components that we put on the nonoss list. So they might not be available after installation and should not be used by default I think.
I would propose to strip them from the components.xml. However I have no easy solution on how an end-user would add them later other than editing the file by hand.
Any ideas?
Cheers,
Hugo
RE: [DISCUSS] how about components.xml
Posted by Edison Su <Ed...@citrix.com>.
I just did on the master branch(7a588b0bdcfef5e125aecdcfbded72af5735f954) yesterday.
> -----Original Message-----
> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
> Sent: Thursday, September 06, 2012 10:02 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: [DISCUSS] how about components.xml
>
> Hey,
>
> While testing the my fresh RPMs I ran into some trouble starting the
> management server. The components.xml.in file references the elements
> and classes for components that we put on the nonoss list. So they
> might not be available after installation and should not be used by
> default I think.
>
> I would propose to strip them from the components.xml. However I have
> no easy solution on how an end-user would add them later other than
> editing the file by hand.
>
> Any ideas?
>
> Cheers,
>
> Hugo
Re: [DISCUSS] how about components.xml
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Sep 6, 2012 at 1:11 PM, Alex Huang <Al...@citrix.com> wrote:
> CloudStack automatically looks for components.xml in the classpath if the property is not defined. So we can put out the OSS version, it will be the default.
>
> We just need a way for people to download the full (non compliant) version and give instructions on how to set the property.
There's no reason to not distribute it with the release, we would just
need instructions (like you said) for how to swap it in.
> --Alex
>
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Thursday, September 06, 2012 10:08 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DISCUSS] how about components.xml
>>
>> On Thu, Sep 6, 2012 at 1:05 PM, Alex Huang <Al...@citrix.com> wrote:
>> > We can always put out a OSS components.xml and a full components.xml.
>> components.xmls can inherit from each other so the full componetns.xml
>> won't have to redefine everything just the things that changed.
>> >
>> > The user can specify which one to use via an environment variable, "cloud-
>> stack-components-specification". Put this in the properties file and set the
>> value to the path to components.xml cloudstack should use.
>>
>> And could we default to the OSS version?
>>
>> > --Alex
>> >
>> >> -----Original Message-----
>> >> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
>> >> Sent: Thursday, September 06, 2012 10:02 AM
>> >> To: cloudstack-dev@incubator.apache.org
>> >> Subject: [DISCUSS] how about components.xml
>> >>
>> >> Hey,
>> >>
>> >> While testing the my fresh RPMs I ran into some trouble starting the
>> >> management server. The components.xml.in file references the
>> elements
>> >> and classes for components that we put on the nonoss list. So they
>> >> might not be available after installation and should not be used by default
>> I think.
>> >>
>> >> I would propose to strip them from the components.xml. However I have
>> >> no easy solution on how an end-user would add them later other than
>> >> editing the file by hand.
>> >>
>> >> Any ideas?
>> >>
>> >> Cheers,
>> >>
>> >> Hugo
>> >
>
RE: [DISCUSS] how about components.xml
Posted by Alex Huang <Al...@citrix.com>.
CloudStack automatically looks for components.xml in the classpath if the property is not defined. So we can put out the OSS version, it will be the default.
We just need a way for people to download the full (non compliant) version and give instructions on how to set the property.
--Alex
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Thursday, September 06, 2012 10:08 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] how about components.xml
>
> On Thu, Sep 6, 2012 at 1:05 PM, Alex Huang <Al...@citrix.com> wrote:
> > We can always put out a OSS components.xml and a full components.xml.
> components.xmls can inherit from each other so the full componetns.xml
> won't have to redefine everything just the things that changed.
> >
> > The user can specify which one to use via an environment variable, "cloud-
> stack-components-specification". Put this in the properties file and set the
> value to the path to components.xml cloudstack should use.
>
> And could we default to the OSS version?
>
> > --Alex
> >
> >> -----Original Message-----
> >> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
> >> Sent: Thursday, September 06, 2012 10:02 AM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: [DISCUSS] how about components.xml
> >>
> >> Hey,
> >>
> >> While testing the my fresh RPMs I ran into some trouble starting the
> >> management server. The components.xml.in file references the
> elements
> >> and classes for components that we put on the nonoss list. So they
> >> might not be available after installation and should not be used by default
> I think.
> >>
> >> I would propose to strip them from the components.xml. However I have
> >> no easy solution on how an end-user would add them later other than
> >> editing the file by hand.
> >>
> >> Any ideas?
> >>
> >> Cheers,
> >>
> >> Hugo
> >
Re: [DISCUSS] how about components.xml
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Sep 6, 2012 at 1:05 PM, Alex Huang <Al...@citrix.com> wrote:
> We can always put out a OSS components.xml and a full components.xml. components.xmls can inherit from each other so the full componetns.xml won't have to redefine everything just the things that changed.
>
> The user can specify which one to use via an environment variable, "cloud-stack-components-specification". Put this in the properties file and set the value to the path to components.xml cloudstack should use.
And could we default to the OSS version?
> --Alex
>
>> -----Original Message-----
>> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
>> Sent: Thursday, September 06, 2012 10:02 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: [DISCUSS] how about components.xml
>>
>> Hey,
>>
>> While testing the my fresh RPMs I ran into some trouble starting the
>> management server. The components.xml.in file references the elements
>> and classes for components that we put on the nonoss list. So they might not
>> be available after installation and should not be used by default I think.
>>
>> I would propose to strip them from the components.xml. However I have no
>> easy solution on how an end-user would add them later other than editing
>> the file by hand.
>>
>> Any ideas?
>>
>> Cheers,
>>
>> Hugo
>
RE: [DISCUSS] how about components.xml
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Thursday, September 06, 2012 7:20 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] how about components.xml
>
>
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> > Sent: Thursday, September 06, 2012 10:14 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: [DISCUSS] how about components.xml
> >
> > On Thu, Sep 6, 2012 at 1:05 PM, Alex Huang <Al...@citrix.com>
> wrote:
> > > We can always put out a OSS components.xml and a full components.xml.
> > components.xmls can inherit from each other so the full componetns.xml
> > won't have to redefine everything just the things that changed.
> > >
> > > The user can specify which one to use via an environment variable,
> > > "cloud-
> > stack-components-specification". Put this in the properties file and
> > set the value to the path to components.xml cloudstack should use.
> > >
> > > --Alex
> > >
> >
> > Doesn't this assume that people want to build all of the non-ASF
> > friendly pieces? What if I just want to build the default CloudStack build +
> F5 support.
> > Some of the dependencies for non-ASF friendly pieces require hardware
> > purchases (NetApp) or support contracts (NetScaler). I don't think
> > there can be only two choices, even if that is how we might build it.
>
> You are correct. Another way to do it is to only give instructions and the
> plugins give xml fragments to add themselves in. But I think for simplicity, it's
> easier for now to just build all non-ASF friendly pieces together. Just
> because the plugin is in the code doesn't mean people need to use it.
> Actually we can do both of these: release a full that includes everything and
> each plugin includes xml fragments. Then users have a choice.
>
> --Alex
This is more or less in line with the rpm build I'm working on. There is a server rpm with the oss stuff and a server-nonoss rpm with the other stuff. Components.xml can have all lines for extra stuff commented out. We can put bits of text in explaining what jars should be on the classpath and how to enable.
RE: [DISCUSS] how about components.xml
Posted by Alex Huang <Al...@citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Thursday, September 06, 2012 10:14 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] how about components.xml
>
> On Thu, Sep 6, 2012 at 1:05 PM, Alex Huang <Al...@citrix.com> wrote:
> > We can always put out a OSS components.xml and a full components.xml.
> components.xmls can inherit from each other so the full componetns.xml
> won't have to redefine everything just the things that changed.
> >
> > The user can specify which one to use via an environment variable, "cloud-
> stack-components-specification". Put this in the properties file and set the
> value to the path to components.xml cloudstack should use.
> >
> > --Alex
> >
>
> Doesn't this assume that people want to build all of the non-ASF friendly
> pieces? What if I just want to build the default CloudStack build + F5 support.
> Some of the dependencies for non-ASF friendly pieces require hardware
> purchases (NetApp) or support contracts (NetScaler). I don't think there can
> be only two choices, even if that is how we might build it.
You are correct. Another way to do it is to only give instructions and the plugins give xml fragments to add themselves in. But I think for simplicity, it's easier for now to just build all non-ASF friendly pieces together. Just because the plugin is in the code doesn't mean people need to use it. Actually we can do both of these: release a full that includes everything and each plugin includes xml fragments. Then users have a choice.
--Alex
Re: [DISCUSS] how about components.xml
Posted by David Nalley <da...@gnsa.us>.
On Thu, Sep 6, 2012 at 1:05 PM, Alex Huang <Al...@citrix.com> wrote:
> We can always put out a OSS components.xml and a full components.xml. components.xmls can inherit from each other so the full componetns.xml won't have to redefine everything just the things that changed.
>
> The user can specify which one to use via an environment variable, "cloud-stack-components-specification". Put this in the properties file and set the value to the path to components.xml cloudstack should use.
>
> --Alex
>
Doesn't this assume that people want to build all of the non-ASF
friendly pieces? What if I just want to build the default CloudStack
build + F5 support. Some of the dependencies for non-ASF friendly
pieces require hardware purchases (NetApp) or support contracts
(NetScaler). I don't think there can be only two choices, even if that
is how we might build it.
--David
RE: [DISCUSS] how about components.xml
Posted by Alex Huang <Al...@citrix.com>.
We can always put out a OSS components.xml and a full components.xml. components.xmls can inherit from each other so the full componetns.xml won't have to redefine everything just the things that changed.
The user can specify which one to use via an environment variable, "cloud-stack-components-specification". Put this in the properties file and set the value to the path to components.xml cloudstack should use.
--Alex
> -----Original Message-----
> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
> Sent: Thursday, September 06, 2012 10:02 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: [DISCUSS] how about components.xml
>
> Hey,
>
> While testing the my fresh RPMs I ran into some trouble starting the
> management server. The components.xml.in file references the elements
> and classes for components that we put on the nonoss list. So they might not
> be available after installation and should not be used by default I think.
>
> I would propose to strip them from the components.xml. However I have no
> easy solution on how an end-user would add them later other than editing
> the file by hand.
>
> Any ideas?
>
> Cheers,
>
> Hugo