Guys, we have a soft code freeze it two days. Here is our status for bugs
with medium, low and wishlist priorities. 29 bugs are already moved
wrote:
> Dima,
> if we want to deprecate UI logs in 10.0, it doesn't mean that we shouldn't
> fix issues in 9.0.
>
> Thank you!
>
>
> Nastya.
>
> On Fri, Mar 25, 2016 at 3:31 PM, Dmitry Pyzhov <dpyz...@mirantis.com>
> wrote:
>
>> As we are going to
As we are going to deprecate logs on UI I'm going to mark following bugs as
"won't fix". Any objections?
High priority bug:
https://bugs.launchpad.net/fuel/+bug/1553170
Medium priority:
https://bugs.launchpad.net/fuel/+bug/1554546
https://bugs.launchpad.net/fuel/+bug/1539508
On Mon, Mar 14, 2016
Guys,
There is a tricky bug with our 'stop deployment' feature:
https://bugs.launchpad.net/fuel/+bug/1529691
It cannot be fixed easily because it is a design flaw. By design we cannot
leave a node in unpredictable state. So we move all nodes that are not in
ready state back to bootstrap.
But
We’ve agreed with QA to get rid of ‘swarm-fail-driver’ tag and limit
‘swarm-blocker’ tag usage. From now on ‘swarm-blocker’ tag is used only for
bugs blocking at least 3 test cases of swarm. Please pay close attention to
this kind of bugs. We need to fix them as a first priority in order to
t; sgolovat...@mirantis.com> wrote:
>>>
>>>> +1
>>>>
>>>> --
>>>> Best regards,
>>>> Sergii Golovatiuk,
>>>> Skype #golserge
>>>> IRC #holser
>>>>
>>>> On Tue, Dec 1, 2015
Guys,
I propose to promote Roman Prykhodchenko to python-fuelclient cores. He is the
main contributor and maintainer of this repo. And he did a great job making
changes toward OpenStack recommendations. Cores, please reply with your +1/-1.
signature.asc
Description: Message signed with
Great job! We are much closer to removal of fuel-web repo.
On Tue, Oct 27, 2015 at 7:35 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Dear colleagues,
>
> I am glad to announce that since now shotgun is a separate project.
> fuel-web/shotgun directory has been deprecated. There is
Hi guys,
new report is based on 'area' tags. I'm sorry for hardly readable heap of
numbers. Here are values for current numbers of open bugs, number of bugs
opened since last Thursday and number of closed bug for the same period.
Bugs in python, library and UI areas. Format: Total open(UI
Guys,
our assignee-based method of guessing bug area has failed. From now on
every bug should has one and only one area tag. You can find explicit list
of tags here: https://wiki.openstack.org/wiki/Fuel/Bug_tags#Area_tags
Here is full list of bugs without area tags
Here is our current stats. Overall situation looks ok. We have manageable
number of high priority bugs. Number of medium bugs is going down. It
doesn't look like we will fix all medium bugs by end of release but it
seems to be acceptable. High priority technical debt is under control.
Features
created a wiki page for tags explanation. Feel free to add tags that
are in use in your teams: https://wiki.openstack.org/wiki/Fuel/Bug_tags
On Fri, Oct 23, 2015 at 12:44 PM, Vitaly Kramskikh <vkramsk...@mirantis.com>
wrote:
> Dmitry,
>
> 2015-10-22 21:42 GMT+07:00 Dmit
Guys,
1) Bugs status
Here is our current stats. Again I’ll show it in format “total (UI / python
/ library)"
Critical and high bugs: 52 (6/28/18). Last week it was 46 (1/23/22)
Medium, low and wishlist bugs: 196 (41/112/43). Last week it was 193
(47/104/42)
Features tracked as bug reports: 143.
Guys,
I propose several changes in bugs workflow on Launchpad.
1) Let's stop using component based team groups as assignees for bugs
2) Let's create separate Launchpad projects for qa, docs and infra teams
It will affect everyone who tracks any list of bugs. So I want to be sure
that everyone
I'm not sure if core reviewers should be so harsh. But the guideline seems
to be very useful. Guys, please don't create backports too early.
On Fri, Oct 2, 2015 at 2:00 PM, Matthew Mosesohn
wrote:
> Hi Fuelers,
>
> I would like to address a concern I have with
Guys,
I was not able to participate in our weekly IRC meeting. So I'd like to
share our bug status for 8.0 release with offline e-mail.
We have 494 Fuel bugs on Launchpad. This number can be splitted into
several piles.
1) Critical and High priority bugs. We have 48 of them now. 2 in UI, 31 in
Guys,
looks like you’ve started to talk about different things. As I see, original
proposal was: stop treat MOS DEB repo as a special case and use the same flow
for all repos. Your use case does not contradict it.
Moreover, it requires standard flow for all repos. ‘Put everything on the ISO’
Vladimir,
thanks for bringing this up. It greatly correlates with the idea of
modularity. Everything related to an openstack release should be put in one
place and should be managed as a solid bundle on the master node. Package
repository is the first solution that comes to the mind and it looks
Andrey, you have highlighted important case. I hope you agree that this
case is not a blocker for the proposal. From the developer's point of view
packages are awful and we should use raw git repos on every node. It could
make developer's life way easier. But from architecture perspective it
would
+1
On Thu, Sep 3, 2015 at 10:14 PM, Sergey Vasilenko
wrote:
> +1
>
>
> /sv
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
If there will be no objections Vladimir will became core reviewer for
fuel-main from Monday, 27th
On Fri, Jul 24, 2015 at 4:10 PM, Vladimir Sharshov vshars...@mirantis.com
wrote:
+1
On Fri, Jul 24, 2015 at 2:58 PM, Andrey Danin ada...@mirantis.com wrote:
+1
On Fri, Jul 24, 2015 at 2:00
At the moment we have several core reviewers for the fuel-main project.
Roman Vyalov is responsible for merging of infrastructure-related variables
and for the lists of packages.
I am responsible for merges in make system. And I have not so much time for
digging into makefiles.
Vladimir
Vladimir,
We do break developer's workflow in stable branches if we force them to use
our local mirrors. Yes, we can hardcode mirror url in tox.ini or something
like that. But it looks like a hack for me.
Packaging systems were created in order to add ability to set up
predictable environment
+1
On Tue, May 5, 2015 at 1:06 PM, Evgeniy L e...@mirantis.com wrote:
+1
On Tue, May 5, 2015 at 12:55 PM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:
+1
2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski pkamin...@mirantis.com:
+1, indeed Julia's reviews are very thorough.
P.
Dmitry, Vladimir, Alexander,
welcome to the core reviewers family =)
Use your power wisely and accept code only if it reviewed by people from
several locations.
On Fri, Apr 17, 2015 at 2:54 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
Thanks for your responses. I'm sorry for combined request
Kalnitsky
ikalnit...@mirantis.com wrote:
Dmitry,
1/ +1
2/ +1
3/ +1
P.S: Dmitry, please send one mail per nomination next time. It's much
easier to vote for each candidate in separate threads. =)
Thanks,
Igor
On Mon, Apr 13, 2015 at 4:24 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote
Guys,
TL;DR: There will be upgrade tarball in 6.1. But it will not require any
data from 6.0.x branch. And there will be no upgrade tarball starting from
7.0.
Looks like we don't need upgrade tarball any more. It is a big relief for
our build team. Because GNU make is not intended to be used for
FYI. We are going to disable Multi-node mode on UI even in experimental
mode. And we will remove related code from nailgun in 7.0.
https://bugs.launchpad.net/fuel/+bug/1428054
On Fri, Jan 30, 2015 at 1:39 PM, Aleksandr Didenko adide...@mirantis.com
wrote:
What do you guys think about switching
+1
On Mon, Apr 13, 2015 at 2:07 PM, Evgeniy L e...@mirantis.com wrote:
+1
On Fri, Apr 10, 2015 at 1:35 PM, Roman Prykhodchenko m...@romcheg.me
wrote:
+1. Sebastian does great job in reviews!
10 квіт. 2015 о 12:05 Igor Kalnitsky ikalnit...@mirantis.com
написав(ла):
Hi Fuelers,
Hi,
1) I want to nominate Vladimir Sharshov to fuel-astute core. We hardly need
more core reviewers here. At the moment Vladimir is one of the main
contributors and reviewers in astute.
2) I want to nominate Alexander Kislitsky to fuel-stats core. He is the
lead of this feature and one of the
Clarification: numbers include only open bugs on 6.1. We have about 15
module-volumes bugs on 7.0, many bugs on the 'next' milestone and some
number of bugs in progress.
On Fri, Mar 27, 2015 at 9:40 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
Guys,
I've tried to sort more than 200 bugs
Guys,
I've tried to sort more than 200 bugs on my team. I've tried several
approaches to this issue and here the solution.
First of all, assigning bugs to teams is great. Totally. Awesome. Let's
keep using it.
Second. I have my own one-more-launchpad-parser:
Actually, we have some improvements with snapshots size and we are going to
rethink our snapshots in upcoming releases. Miroslav, could you clarify the
importance of this change in 6.1?
On Thu, Jan 29, 2015 at 2:30 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:
Guys,
We have requests for
solution
On 12 Dec 2014, at 23:17, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
+1 to stop parsing logs on UI and show them as is. I think it's more
than enough for all users.
On Fri, Dec 12, 2014 at 8:35 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
We have a high priority bug
Guys,
we are about to enable image based provisioning in our master by default.
I'm trying to figure out requirement for this change. As far as I know, it
was not tested on scale lab. Is it true? Have we ever run full system tests
cycle with this option?
Do we have any other pre-requirements?
Guys,
we've done a good job in 6.0. Most of the features were merged before
feature freeze. Our QA were involved in testing even earlier. It was much
better than before.
We had a discussion with Anastasia. There were several bug reports for
features yesterday, far beyond HCF. So we still have a
We have a high priority bug in 6.0:
https://bugs.launchpad.net/fuel/+bug/1401852. Here is the story.
Our openstack services use to send logs in strange format with extra copy
of timestamp and loglevel:
== ./neutron-metadata-agent.log ==
2014-12-12T11:00:30.098105+00:00 info: 2014-12-12
, November 25, 2014, Dmitry Pyzhov dpyz...@mirantis.com wrote:
Thank you all for your feedback. Request postponed to the next release.
We will compare available solutions.
On Mon, Nov 24, 2014 at 2:36 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
guys, there is already pxz utility in ubuntu repos
Just FYI. We have updated versions of nailgun-related packages in 6.0:
https://review.openstack.org/#/c/137886/
https://review.openstack.org/#/c/137887/
https://review.openstack.org/#/c/137888/
https://review.openstack.org/#/c/137889/
We need it in order to support packages updates both in
Thank you all for your feedback. Request postponed to the next release. We
will compare available solutions.
On Mon, Nov 24, 2014 at 2:36 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
guys, there is already pxz utility in ubuntu repos. let's test it
On Mon, Nov 24, 2014 at 2:32 PM,
We have a request https://bugs.launchpad.net/fuel/+bug/1394487 for change
compression from gz to xz. This simple change halfs our snapshots. Does
anyone has any objections? Otherwise we will include this change in 6.0
release.
___
OpenStack-dev mailing
I'm agree with Dmitry. We can change version text. Use '2014.2-6.0-pre' in
openstack.yaml and '6.0-pre' in PRODUCT_VERSION. Yep, we need to test it
first. Also think about sorting on ui and other places where we can compare
versions.
On Mon, Oct 20, 2014 at 2:36 PM, Aleksandra Fedorova
We definitely need to assign these bugs to the fuel-docs team. And there is
a good point from Alexandra Fedorova that commit message needs to have
enough information for tech writer. And reviewers should not merge fixes
that do not apply this rule. Otherwise we will end up with new bottlenecks.
Dmitry,
I totally agree that we should support nightly builds in upgrades. I've
created a blueprint for this:
https://blueprints.launchpad.net/fuel/+spec/upgrade-nightly
On Tue, Sep 2, 2014 at 3:24 AM, Dmitry Borodaenko dborodae...@mirantis.com
wrote:
We should not confuse beta and rc builds,
Feature blockers:
Versioning https://blueprints.launchpad.net/fuel/+spec/nailgun-versioning
for REST API
https://blueprints.launchpad.net/fuel/+spec/nailgun-versioning-api, UI,
serialization
https://blueprints.launchpad.net/fuel/+spec/nailgun-versioning-rpc
Ongoing activities:
Nailgun plugins
-specs with
detailed feature description.
According to this feature, we are going to switch our CI system to
lrzipped tarballs.
[1] https://review.openstack.org/#/c/116874/
On Thu, Aug 21, 2014 at 5:50 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
Fuelers,
Our upgrade tarball for 5.1
All,
I'm not sure if it deserves to be mentioned in our documentation, this
seems to be a common practice. If an administrator wants to patch his
environment, he should be prepared for a temporary downtime of OpenStack
services. And he should plan to perform patching in advance: choose a time
It is not enough, you need to review requirements in the code of nailgun,
ostf and astute.
I'll be happy to have our requirements files and specs as close to
global-requirements as possible. It will ruin our current solid structure,
where we have same versions of dependencies on production, on
Fuelers,
Our upgrade tarball for 5.1 is more than 4.5Gb. We can reduce it size by
2Gb with lrzip tool (ticket
https://bugs.launchpad.net/fuel/+bug/1356813, change
in build system https://review.openstack.org/#/c/114201/, change in docs
https://review.openstack.org/#/c/115331/), but it will
possible solutions to this issue?
On Thu, Aug 21, 2014 at 5:50 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
Fuelers,
Our upgrade tarball for 5.1 is more than 4.5Gb. We can reduce it size by
2Gb with lrzip tool (ticket
https://bugs.launchpad.net/fuel/+bug/1356813, change in build system
We've moved all blueprints from 6.0 to 'next' milestone. It has been done
in order to better view of stuff that we really want to implement in 6.0.
Feature freeze for 6.0 release is planned to 18th of September. If you are
going to merge your blueprint before that date, you can move it to 6.0
environments of the same version. So we should check and warn user about
it, or simply not allow to delete releases if there are live envs with the
same version.
On Thu, Jul 3, 2014 at 3:45 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
So, our releases will have following versions
.
On Tue, Jun 24, 2014 at 5:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
Guys,
We have a beautiful contribution guide:
https://wiki.openstack.org/wiki/Fuel/How_to_contribute
However, I would like to address several issues in our blueprints/bugs
processes. Let's discuss and vote on my
So, our releases will have following versions of releases on UI:
5.0) 2014.1
5.0.1) 2014.1.1-5.0.1
5.1) 2014.1.1-5.1
And if someone install 5.0, upgrade it to 5.0.1 and then upgrade to 5.1, he
will have three releases for each OS. I think we should allow user to
delete unneeded releases. It also
Guys,
We are going to merge feature groups
https://blueprints.launchpad.net/fuel/+spec/feature-groups, it will cause
small changes in iso build parameters.
MIRANTIS parameter is deprecated, please use FEATURE_GROUPS=mirantis
instead.
Another available feature group is 'experimental'. Without it
Fuelers,
Ok, today is bug squash day. No activities except bugs triage
https://wiki.openstack.org/wiki/BugTriage/fix/review/merge.
Current count:
17 new bugs
http://fuel-launchpad.mirantis.com/project/fuel/bug_table_for_status/New/None
25 incomplete bugs
Guys,
We have a beautiful contribution guide:
https://wiki.openstack.org/wiki/Fuel/How_to_contribute
However, I would like to address several issues in our blueprints/bugs
processes. Let's discuss and vote on my proposals.
1) First of all, the bug counter is an excellent metric for quality. So
Vladimir has a proposal to add rescue livecd image as a boot option for PXE
nodes. I think it is a great idea. If anyone has other opinions, please
reply.
Miroslav, could you be a reviewer for this blueprint?
Anastasia, could you propose someone for QA?
Guys,
from now on we should keep all our 5.1 blueprint specs in one place: fuel-specs
repo https://github.com/stackforge/fuel-specs. We do it same way as nova,
so you can use their
instructionhttps://wiki.openstack.org/wiki/Blueprints#Novaas a
guideline.
Once again. All specifications for 5.1
Nobody tried to use docker for slave nodes, I guess.
Actually, you will face several issues. First, you need to install basic
system into docker, install packages and run our postinstall script from
our kickstart
. that it will cost us more to
postpone it and make that upgrade a part of Fuel upgrade.
-DmitryB
On Mon, Apr 21, 2014 at 1:58 PM, Jay Pipes jaypi...@gmail.com wrote:
On Tue, 2014-04-22 at 00:55 +0400, Dmitry Pyzhov wrote:
We use postgresql 8 on master node right now. At some point we will
have
Mirrors cleanup is done. No more gems, no more source files for third-party
tools. Only centos and ubuntu packages.
Next and the last action item - create astute package during iso build.
On Mon, Apr 21, 2014 at 2:10 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
How does it impact development
numbers?
4. We still have puppet modules not packaged, right? Do we have plans
for packaging it too?
I assume we will document the usage of this somewhere in dev docs too.
Thanks,
On Fri, Apr 18, 2014 at 6:06 PM, Dmitry Pyzhov dpyz...@mirantis.comwrote:
Guys,
I've removed ability
We use postgresql 8 on master node right now. At some point we will have to
migrate to 9th version. And database migration can became painful part of
master node upgrade at that point.
At the moment part of our developers use psql9 in their environments and
see no issues. Should we enforce
Guys,
I've removed ability to use eggs packages on master node:
https://review.openstack.org/#/c/88012/
Next step is to remove gems mirror: https://review.openstack.org/#/c/88278/
It will be merged when osci team fix rubygem-yajl-ruby package. Hopefully
on Monday.
From that moment all our code
Guys,
We have big and complicated structure of the project. And part of our
patchsets require additional actions before merge. Sometimes we need
approve from testers, sometimes we need merge requests in several repos at
the same time, sometimes we need updates of rpm repositories before merge.
smoke test which would check that master node builds, and
simplest deploy passes? This needs to be run only if there are changes
discovered in ISO build script (including mirror changes), and puppet
manifests which deploy master node
On Tue, Apr 15, 2014 at 3:49 PM, Dmitry Pyzhov dpyz
tested before update.
On Wed, Apr 9, 2014 at 3:38 PM, Matthew Mosesohn mmoses...@mirantis.comwrote:
Dmitry, I don't think you should drop kombu.five so soon.
We haven't heard directly from Fuel python team, such as Dmitry
Pyzhov, what reason we have to lock kombu at version 2.5.14.
I wrote
.
On Tue, Nov 5, 2013 at 7:55 AM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2013-10-31 20:16:39 +0400 (+0400), Dmitry Pyzhov wrote:
Currently we have only one fuel-core group. Could you grant this
permission to this group. It is rather small team. Looks like
we'll create another group 'fuel
Hooray, it works!
Thank you!
On Tue, Oct 8, 2013 at 8:37 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2013-10-08 19:48:55 +0400 (+0400), Dmitry Pyzhov wrote:
Right now we have the last issue. Looks like our fuel-ci user
have no permissions to verify our repos:
[...]
What is required
, Dmitry Pyzhov dpyz...@mirantis.com wrote:
Hi Jeremy,
I am sorry, but we need to do repos re-clone in two steps. Now as a first
step we need to re-clone https://github.com/Mirantis/fuel-main. All other
repos will be moved after creation of
https://github.com/Mirantis/fuel-ostf repo
Jeremy,
Is it enough? https://review.openstack.org/#/c/49407
On Wed, Oct 2, 2013 at 8:29 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2013-10-02 18:32:50 +0400 (+0400), Dmitry Pyzhov wrote:
[...]
we need change the names of repositories
[...]
Project renames are more complicated
72 matches
Mail list logo