fuel-dev team mailing list archive

[Andrew Woodward <xarses@xxxxxxxxx>]

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