fuel-dev team mailing list archive

[Andrey Danin <adanin@xxxxxxxxxxxx>]

I agree with Andrew. A good documentation is better than DB constraints.


On Fri, Apr 25, 2014 at 11:15 PM, Andrew Woodward <xarses@xxxxxxxxx> 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 <nmarkov@xxxxxxxxxxxx>
> 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 <deaster@xxxxxxxxxxxx>
> 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 <nmarkov@xxxxxxxxxxxx>
> >> Date: Thursday, April 24, 2014 at 9:19 AM
> >> To: Evgeniy L <eli@xxxxxxxxxxxx>
> >> Cc: "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >> 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 <eli@xxxxxxxxxxxx> 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 <nmarkov@xxxxxxxxxxxx>
> >>> 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>>> 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 :
> >> fuel-dev@xxxxxxxxxxxxxxxxxxx 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> > 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Andrey Danin
adanin@xxxxxxxxxxxx
skype: gcon.monolake