Open Stack

+1 to y'all :)

We already have a blueprint to enable building Fuel packages with
Perestroika:
https://blueprints.launchpad.net/fuel/+spec/build-fuel-packages-using-perestroika

Between that and packaging Perestroika itself as a self-sufficient tool
that a developer can easily set up and run locally (which we also need a
blueprint for), I think we'd have enough tools to distribute
fuel-library to target node as packages both in production, and, without
too much additional effort, as part of development workflow.

-DmitryB

On Fri, Sep 11, 2015 at 10:59:40PM +0300, Andrey Danin wrote:
> 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

> __________________________________________________________________________
> 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