← Back to team overview

fuel-dev team mailing list archive

Re: Fuel master node upgrade - bugs statuses

 

+1 on updating bug descriptions (not comments) about probability of
failure, and using paste.openstack.org more often.


On Wed, Aug 27, 2014 at 3:41 AM, Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx
> wrote:

> On Tue, Aug 26, 2014 at 12:11 AM, Mike Scherbakov
> <mscherbakov@xxxxxxxxxxxx> wrote:
> > "confusing versioning in OpenStack patching" - if we didn't change puppet
> > manifests and Fuel/OpenStack reference architecture in next Fuel
> versions,
> > then it would be as simple as patching from 5.0 to 5.1. But it appeared
> to
> > be more complicated system than you would initially think of, so in
> general
> > 5.0.2 may not be equal to 5.1, that's where all things come up. If we had
> > OpenStack upgrades, then we could just say 5.0 -> 6.0 - easy.
>
> We may have had technical reasons to make this decision, but it still
> is confusing and negatively impacts UX. I agree that having an
> incomplete feature early is better than not having it at all until
> much later, as long as we don't stop working on it until it's complete
> and these small but annoying deficiencies are addressed. Our
> experience with technical debt so far is not very reassuring.
>
> > "issues with containers" - we have same issues with everything. Let's
> take
> > Galera, for example. It's just issues. We can question maturity of tools
> we
> > use, and here I'd agree - we spent too much fixing issues around Docker.
> At
> > the same time, if we were about taking our own journey with LXC, we would
> > likely spend even more time inventing our own bicycle.
>
> You're assuming that it was just Docker as a piece of software that is
> the primary cause of all our troubles with Fuel upgrades. Docker is
> only a small part of the a much large and much more intrusive design
> decision to use containers for upgrading Fuel (and also the design
> decision to use a different mechanism based on Puppet for patching
> OpenStack). I think we should question high-level design decisions
> like these more often, even after they are implemented.
>
> > Also, I'd like to ask everyone to provide
> > such information in every bug you report if possible (or if get this info
> > later, put comments): in many bug reports it is unclear to understand how
> > severe issue is.
>
> I think we should start updating bug description more often, so that
> you can find a summary of current state of the bug and of all relevant
> information from the description, without having to scroll through
> dozens of comments. We should also use paste.openstack.org more
> heavily and avoid pasting more than 1-2 lines of logs into bug
> description and comments, also to make it easier to find important
> bits in bugs history.
>



-- 
Mike Scherbakov
#mihgen

Follow ups

References