Open Stack

I support this proposal but I just wanted to mention that we'll lose an
easy way to develop manifests. I agree that manifests in this case have no
difference with Neutron code, for instance. But anyway I +1 this,
especially with Vova Kuklin's additions.

On Thu, Sep 10, 2015 at 12:25 PM, Vladimir Kuklin <vkuklin at mirantis.com>
wrote:

> Folks
>
> I have a strong +1 for the proposal to decouple master node and slave
> nodes.
> Here are the stregnths of this approach
> 1) We can always decide which particular node runs which particular set of
> manifests. This will allow us to do be able to apply/roll back changes
> node-by-node. This is very important from operations perspective.
> 2) We can decouple master and slave nodes manifests and not drag new
> library version onto the master node when it is not needed. This allows us
> to decrease probability of regressions
> 3) This makes life easier for the user - you just run 'apt-get/yum
> install' instead of some difficult to digest `mco` command.
>
> The only weakness that I see here is on mentioned by Andrey. I think we
> can fix it by providing developers with clean and simple way of building
> library package on the fly. This will make developers life easier enough to
> work with proposed approach.
>
> Also, we need to provide ways for better UX, like provide one button/api
> call for:
>
> 1) update all manifests on particular nodes (e.g. all or only a part of
> nodes of the cluster) to particular version
> 2)  revert all manifests back to the version which is provided by the
> particular GA release
> 3) <more things we need to think of>
>
> So far I would mark need for simple package-building system for developer
> as a dependency for the proposed change, but I do not see any other way
> than proceeding with it.
>
>
>
> On Thu, Sep 10, 2015 at 11:50 AM, Sergii Golovatiuk <
> sgolovatiuk at mirantis.com> wrote:
>
>> Oleg,
>>
>> Alex gave a perfect example regarding support folks when they need to fix
>> something really quick. It's client's choice what to patch or not. You may
>> like it or not, but it's client's choice.
>>
>> On 10 Sep 2015, at 09:33, Oleg Gelbukh <ogelbukh at mirantis.com> wrote:
>>
>> Alex,
>>
>> I absolutely understand the point you are making about need for
>> deployment engineers to modify things 'on the fly' in customer environment.
>> It's makes things really flexible and lowers the entry barrier for sure.
>>
>> However, I would like to note that in my opinion this kind on 'monkey
>> patching' is actually a bad practice for any environments other than dev
>> ones. It immediately leads to emergence of unsupportable frankenclouds. I
>> would greet any modification to the workflow that will discourage people
>> from doing that.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Wed, Sep 9, 2015 at 5:56 PM, Alex Schultz <aschultz at mirantis.com>
>> wrote:
>>
>>> Hey Vladimir,
>>>
>>>
>>>
>>>> Regarding plugins: plugins are welcome to install specific additional
>>>> DEB/RPM repos on the master node, or just configure cluster to use
>>>> additional onl?ne repos, where all necessary packages (including plugin
>>>> specific puppet manifests) are to be available. Current granular deployment
>>>> approach makes it easy to append specific pre-deployment tasks
>>>> (master/slave does not matter). Correct me if I am wrong.
>>>>
>>>>
>>> Don't get me wrong, I think it would be good to move to a fuel-library
>>> distributed via package only.  I'm bringing these points up to indicate
>>> that there is many other things that live in the fuel library puppet path
>>> than just the fuel-library package.  The plugin example is just one place
>>> that we will need to invest in further design and work to move to the
>>> package only distribution.  What I don't want is some partially executed
>>> work that only works for one type of deployment and creates headaches for
>>> the people actually having to use fuel.  The deployment engineers and
>>> customers who actually perform these actions should be asked about
>>> packaging and their comfort level with this type of requirements.  I don't
>>> have a complete understanding of the all the things supported today by the
>>> fuel plugin system so it would be nice to get someone who is more familiar
>>> to weigh in on this idea. Currently plugins are only rpms (no debs) and I
>>> don't think we are building fuel-library debs at this time either.  So
>>> without some work on both sides, we cannot move to just packages.
>>>
>>>
>>>> Regarding flexibility: having several versioned directories with puppet
>>>> modules on the master node, having several fuel-libraryX.Y packages
>>>> installed on the master node makes things "exquisitely convoluted" rather
>>>> than flexible. Like I said, it is flexible enough to use mcollective, plain
>>>> rsync, etc. if you really need to do things manually. But we have
>>>> convenient service (Perestroika) which builds packages in minutes if you
>>>> need. Moreover, In the nearest future (by 8.0) Perestroika will be
>>>> available as an application independent from CI. So, what is wrong with
>>>> building fuel-library package? What if you want to troubleshoot nova (we
>>>> install it using packages)? Should we also use rsync for everything else
>>>> like nova, mysql, etc.?
>>>>
>>>>
>>> Yes, we do have a service like Perestroika to build packages for us.
>>> That doesn't mean everyone else does or has access to do that today.
>>> Setting up a build system is a major undertaking and making that a hard
>>> requirement to interact with our product may be a bit much for some
>>> customers.  In speaking with some support folks, there are times when files
>>> have to be munged to get around issues because there is no package or
>>> things are on fire so they can't wait for a package to become available for
>>> a fix.  We need to be careful not to impose limits without proper
>>> justification and due diligence.  We already build the fuel-library
>>> package, so there's no reason you couldn't try switching the rsync to
>>> install the package if it's available on a mirror.  I just think you're
>>> going to run into the issues I mentioned which need to be solved before we
>>> could just mark it done.
>>>
>>> -Alex
>>>
>>>
>>>
>>>> Vladimir Kozhukalov
>>>>
>>>> On Wed, Sep 9, 2015 at 4:39 PM, Alex Schultz <aschultz at mirantis.com>
>>>> wrote:
>>>>
>>>>> I agree that we shouldn't need to sync as we should be able to just
>>>>> update the fuel-library package. That being said, I think there might be a
>>>>> few issues with this method. The first issue is with plugins and how to
>>>>> properly handle the distribution of the plugins as they may also include
>>>>> puppet code that needs to be installed on the other nodes for a deployment.
>>>>> Currently I do not believe we install the plugin packages anywhere except
>>>>> the master and when they do get installed there may be some post-install
>>>>> actions that are only valid for the master.  Another issue is being
>>>>> flexible enough to allow for deployment engineers to make custom changes
>>>>> for a given environment.  Unless we can provide an improved process to
>>>>> allow for people to provide in place modifications for an environment, we
>>>>> can't do away with the rsync.
>>>>>
>>>>> If we want to go completely down the package route (and we probably
>>>>> should), we need to make sure that all of the other pieces that currently
>>>>> go together to make a complete fuel deployment can be updated in the same
>>>>> way.
>>>>>
>>>>> -Alex
>>>>>
>>>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuklin at mirantis.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Andrey Danin
adanin at mirantis.com
skype: gcon.monolake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150911/dae2946c/attachment.html>