[openstack-dev] [Fuel] Mitaka SCF is coming. Here is bugs status for python and library

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

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

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

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

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

[openstack-dev] [Fuel] Stop deployment can break production cluster. How we should avoid it?

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

[openstack-dev] [Fuel] Please pay attention to bugs with 'swarm-blocker' tag

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

Re: [openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

t; sgolovat...@mirantis.com> wrote: >>> >>>> +1 >>>> >>>> -- >>>> Best regards, >>>> Sergii Golovatiuk, >>>> Skype #golserge >>>> IRC #holser >>>> >>>> On Tue, Dec 1, 2015

[openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

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

Re: [openstack-dev] [Fuel] shotgun code freeze

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

[openstack-dev] [Fuel] Bugs status

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

[openstack-dev] [Fuel] Every bug in 8.0 milestone should be marked with area tag

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

[openstack-dev] [Fuel] Bugs status

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

Re: [openstack-dev] [Fuel] Bugs status for ui, python and library. And 'area-*' tags.

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

[openstack-dev] [Fuel] Bugs status for ui, python and library. And 'area-*' tags.

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.

[openstack-dev] [Fuel] Changes in bugs workflow on Launchpad

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

Re: [openstack-dev] [Fuel] backporting before merging to master

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

[openstack-dev] [Fuel] Bugfixing status. 12 weeks before SCF.

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

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

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’

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

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

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

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

Re: [openstack-dev] [Fuel] Nominate Evgeniy Konstantinov for fuel-docs core

+1 On Thu, Sep 3, 2015 at 10:14 PM, Sergey Vasilenko wrote: > +1 > > > /sv > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe:

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

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

[openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

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

Re: [openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift

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

Re: [openstack-dev] [Fuel] Nominate Julia Aranovich for fuel-web core

+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.

Re: [openstack-dev] [Fuel] Several nominations for fuel project cores

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

Re: [openstack-dev] [Fuel] Several nominations for fuel project cores

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

[openstack-dev] [Fuel] Upgrade tarball retirement path

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

Re: [openstack-dev] [Fuel] removing single mode

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

Re: [openstack-dev] [Fuel] Nominate Sebastian Kalinowski for fuel-web/python-fuelclient core

+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,

[openstack-dev] [Fuel] Several nominations for fuel project cores

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

Re: [openstack-dev] [Fuel] Bug tagging practice

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

[openstack-dev] [Fuel] Bug tagging practice

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:

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

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

Re: [openstack-dev] [Fuel] Logs format on UI (High/6.0)

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

[openstack-dev] [Fuel] Image based provisioning

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?

[openstack-dev] [Fuel] Feature delivery rules and automated tests

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

[openstack-dev] [Fuel] Logs format on UI (High/6.0)

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

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

, 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

[openstack-dev] [Fuel] rpm packages versions

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

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

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,

[openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

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

Re: [openstack-dev] [Fuel][Fuel-dev] Detailed Fuel release version definition

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

Re: [openstack-dev] [Fuel] Documentation Process changed

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.

Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download

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,

Re: [openstack-dev] [Fuel] Goals for 5.1.1 6.0

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

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

-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

[openstack-dev] [Fuel] Maintenance mode for patching

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

Re: [openstack-dev] [Fuel] Issues with hardcoded versions of requirements in specs of packages

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

[openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

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

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

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

[openstack-dev] [Fuel] 6.0 blueprints cleanup

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

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

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

Re: [openstack-dev] [Fuel] Blueprints process

. 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

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

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

[openstack-dev] [Fuel] Changes in iso build because of feature groups

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

Re: [openstack-dev] [Fuel] Bug squashing day on Tu, 24th of June

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

[openstack-dev] [Fuel] Blueprints process

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

[openstack-dev] [Fuel] RIP linux as a boot option for PXE nodes

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?

[openstack-dev] [Fuel] Review blueprint specs on gerrit

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

[openstack-dev] [Fuel] How to install openstack into containers using FUEL?

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

Re: [openstack-dev] [Fuel] Migrate to Postrgresql 9

. 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

Re: [openstack-dev] [Fuel] Migration to packages, step 2/2

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

Re: [openstack-dev] [Fuel] Migration to packages, step 1/2

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

[openstack-dev] [Fuel] Migrate to Postrgresql 9

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

[openstack-dev] [Fuel] Migration to packages, step 1/2

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

[openstack-dev] [Fuel] Code merge policy

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.

Re: [openstack-dev] [Fuel] Code merge policy

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

Re: [openstack-dev] [Fuel] Problem with kombu version.

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