I agree with Andrew. A good documentation is better than DB constraints.
On Fri, Apr 25, 2014 at 11:15 PM, Andrew Woodward <[email protected]> wrote: > I can see the reasoning for adding the enum to the DB since we can't > serialize the data if it's not something we recognize anyway, however > this won't fix the underlying issue here. The real issue here is that > we don't have a guide that identifies what can be easily extended, and > how to go about doing it. With out it, some one might see the > constraint, and then edit the enum, and not know that the > provisioning, and possibly deployment serializers as well as cobbler > and the fuel-library in general will need updates. > > On Fri, Apr 25, 2014 at 12:32 AM, Nikolay Markov <[email protected]> > wrote: > > I'm not speaking for the denial of the opportunity to add custom OS. This > > will still be available, but it should be done in a right way, with > adding > > some OS-related code into Nailgun/Fuel and in case of DB ENUM it will > also > > include creating a migration which means adding this system into the > list of > > supported ones. As for me, that's a proper way of doing contribution, but > > adding OS into release by hand and an obvious fail only when you start > the > > deployment itself on "your new OS" isn't. > > > > > > On Fri, Apr 25, 2014 at 2:04 AM, David Easter <[email protected]> > wrote: > >> > >> As an open source project that can be used for deployments outside of > >> Mirantis, it would be good for the community if someone could use Fuel > to > >> deploy onto other operating systems if the appropriate deployment logic > were > >> added. In other words, the project should not explicitly deny the > ability > >> to extend the control plane to other operating systems. However, it’s > very > >> reasonable for any company, like Mirantis, that provides a product to > >> include the list of supported operating systems in a config file or > >> parameter. The Fuel project would then error out if the OS name was > not in > >> that list. I’d even be ok with that file containing the Mirantis > supported > >> operating systems by default, but that could be changed by a community > >> member for their own distribution. > >> > >> It would obviously fall to the community to add in the additional > >> code/logic to deploy on other operating systems – but the Fuel project > >> shouldn’t deny that opportunity. > >> > >> Thanks, > >> > >> - David J. Easter > >> Director of Product Management, Mirantis > >> > >> From: Nikolay Markov <[email protected]> > >> Date: Thursday, April 24, 2014 at 9:19 AM > >> To: Evgeniy L <[email protected]> > >> Cc: "[email protected]" <[email protected]> > >> Subject: Re: [Fuel-dev] Custom OSes in release > >> > >> >> What kind of issue it will help to avoid? > >> > >> To avoid getting our customers in trouble. > >> > >> >> in my case user can just add it > >> > >> No, he can't. It won't work. The sooner he will know it the better. > >> > >> >> there will be a lot of failed deployments during development and > >> >> debugging anyway > >> > >> Why? No, it won't. We don't have cases where we need to modify it by > hands > >> and see what happens, because we already have strict list of OSes we > >> support. And if someone of our clients or deployment engineers does > that - > >> it will be better for him to know this won't work from the beginning, > isn't > >> it? > >> > >> > >> > >> > >> On Thu, Apr 24, 2014 at 5:26 PM, Evgeniy L <[email protected]> wrote: > >>> > >>> >> to avoid all possible issues > >>> > >>> What kind of issue it will help to avoid? > >>> > >>> I want to avoid constraints where they are not required, in your case > >>> user have to add new migration file and then migrate database to add > new > >>> field in enum, in my case user can just add it. In your and mine cases > user > >>> have to add additional logic in our serializers and there will be a > lot of > >>> failed deployments during development and debugging anyway. > >>> > >>> > >>> On Thu, Apr 24, 2014 at 4:30 PM, Nikolay Markov <[email protected]> > >>> wrote: > >>>> > >>>> Hello colleagues, > >>>> > >>>> What is our policy regarding specifying custom OS names in releases in > >>>> openstack.yaml or via API? I mean, we only support two OSes, which are > >>>> CentOS and Ubuntu, and already have some OS-based logic in our code, > which > >>>> will just not execute if OS name is 'Suse', for example. > >>>> > >>>> Evgeny Li says we should allow specifying custom names, currently it > >>>> causes no errors until you try to deploy an environment with this > release. > >>>> > >>>> I think in this case we may implement this as a ENUM in DB and forbid > >>>> creating releases with different OS names at all, to avoid all > possible > >>>> issues. > >>>> > >>>> What do you think? > >>>> > >>>> -- > >>>> Best regards, > >>>> Nick Markov > >>>> > >>>> -- > >>>> Mailing list: https://launchpad.net/~fuel-dev > >>>> Post to : [email protected] > >>>> Unsubscribe : https://launchpad.net/~fuel-dev > >>>> More help : https://help.launchpad.net/ListHelp > >>>> > >>> > >> > >> > >> > >> -- > >> Best regards, > >> Nick Markov > >> -- Mailing list: https://launchpad.net/~fuel-dev Post to : > >> [email protected] Unsubscribe : > https://launchpad.net/~fuel-dev > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > > > -- > > Best regards, > > Nick Markov > > > > -- > > Mailing list: https://launchpad.net/~fuel-dev > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~fuel-dev > > More help : https://help.launchpad.net/ListHelp > > > > > > -- > Andrew > Mirantis > Ceph community > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Andrey Danin [email protected] skype: gcon.monolake
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
