Re: [openstack-dev] [Fuel] PTL non candidacy
Vladimir, fuelers, very impressive list of achievements for 1 release cycle. Good work, folks! Regards, Igor Marnat On Tue, Sep 13, 2016 at 1:02 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > Newton cycle is getting to its end and it is time to look at what we've > managed to achieve by the moment. > > * Improved task based deployment engine (memory efficiency, code > structure, graph sequences, noop run). > * Re-implemented OS provisioning as a graph. Now it is one of the graphs in > the default deployment graph sequence. > * Improved graph API and UX. Now it is possible to upload/download > custom graphs, run particular graphs, see per-task deployment > progress. > * Aligned the functionality of the new version of fuelclient with the > old one. Now all subcommands are available in `fuel2` and we are ready > to deprecate old `fuel` command. > * We are on our way to get rid of ISO. (ISOless BVT is ready, review > jobs are in progress). > * Improved LCM UX including IaC (using git repository as a source for > cluster configuration). > * We begun implementing cluster upgrade procedure as a graph. In the > future in-place OpenStack cluster upgrades will be a native part Fuel > functionality. > * We also put some efforts to research container based deployment > possibilities (K8s and Docker). We introduced a bunch of > experimental repositories (fuel-ccp-*) where the team is now working > on CI/CD like UX for containerized OpenStack deployment. > > There are also many things that we were planning but didn't manage > to do. I'm not going to nominate myself as a PTL for Ocata cycle, but I'll > continue to contribute to Fuel to make it a perfect deployment > tool and I'm looking forward for other Fuel team members to run for PTL > role. > > Thanks. > > > Vladimir Kozhukalov > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] [heat] [murano] [app-catalog] OpenStack Apps Community, several suggestions how to improve collaboration
to switch CIs from third-party CIs to OpenStack Infra CIs. Regards, Igor Marnat On Wed, May 25, 2016 at 2:37 PM, Igor Marnat <imar...@mirantis.com> wrote: > Colleagues, > having attended many sessions and talked to many customers, partners > and contributors in Austin I’d like to suggest several improvements to how > we develop OpenStack apps and work with the Community App Catalog ( > https://apps.openstack.org/). > > Key goals to achieve are: > - Provide contributors with an ability to collaborate on OpenStack > apps development > - Provide contributors and consumers with transparent workflow to > manage their apps > - Provide consumers with information about apps - how it was developed > and tested > - To summarize - introduce the way to build community working on > OpenStack apps > > *What is OpenStack application* > OpenStack is about 6 years young and all these years discussions about > it are in progress. Variety of applications is huge, from LAMP stacks > and legacy Java apps to telco workloads and VNF apps. There is working > group which works on a definition of "What is OpenStack application", > hopefully community will agree on definition soon. > > For the sake of our discussion below let us agree on a simple approach: > an OpenStack application is any software asset which 1. can be executed on > an OpenStack cloud, 2. lives in apps.openstack.org. So far there are > Murano applications, Heat templates, Glance images and TOSCA templates. > > There are many good OpenStack applications in the world which don't live > in OpenStack App Catalog. However, let us for now concentrate on those > which do, just for the sake of this discussion. > > *Introduction to OpenStack development ecosystem* > OpenStack was introduced about 6 years ago. Over these years > community grown significantly. There were 8 companies contributing to > OpenStack in Austin (1-st release). In Mitaka (13-th release) there were 64 > companies contributing. > > One of the reasons for this growth is the set of sophisticated tools > the OpenStack contributor ecosystem has chosen to use or build to > enable collaboration: > - software repositories: http://git.openstack.org/cgit/openstack/nova, > http://git.openstack.org/cgit/openstack/neutron, .. > - bug trackers: https://launchpad.net/nova, https://launchpad.net/neutron > , ... > - same instance of gerrit for all the projects for code review: > https://review.openstack.org/ > - gating test infrastructure http://zuul.openstack.org/ > - common approach to release management, repositories management, > naming, tons of other things managed by review in > https://review.openstack.org/#/q/status:open+project:openstack/governance > - IRC channels, etherpads, meetings and mailing lists > - governance to manage all of the above > > All of the above is what we can call OpenStack collaboration ecosystem > and it is a key factor for OpenStack community success. > > *Introduction to OpenStack apps development ecosystem* > Now when OpenStack is mature and have it up and running is not a big > deal, focus of community and customers shifts from "how do I get a running > cloud" to "what do I do with running cloud". > > Use cases of different cloud users are very different, however one > can identify and develop standard building blocks which can be reused by > cloud users (service providers, DevTest teams, ...). Many cloud users want > to contribute their homegrown apps upstream because: > - it allows to other people to use it and improve it > - community can implement missing parts > - community can help with testing and maintaining an app > > Year ago we introduced Community App Catalog for OpenStack > http://apps.openstack.org as an integration/distribution point of > customer experience/apps. This initiative is successful, there are about > 100 software assets of various kinds which can be run on OpenStack. For > further growth we need to make several changes in a way we approach > collaboration around OpenStack Apps. Namely, we need to provide an ability > to apps developers to collaborate on application development. > > *OpenStack Community App Catalog is there, what else?* > Community App Catalog http://apps.openstack.org allows to > publish/consume apps to/from it. > > "The OpenStack Community App Catalog is designed to use the same tools > for submission and review as other OpenStack projects. As such we follow > the OpenStack development workflow" [0]. > > To follow OpenStack development workflow, apps developers need to have: > - dedicated repositories & code review system to collaborate on code > - mailing lists, IRC channels, core reviewers teams > - common approach to QA &
[openstack-dev] [tc] [heat] [murano] [app-catalog] OpenStack Apps Community, several suggestions how to improve collaboration
[0] https://wiki.openstack.org/wiki/App-Catalog#How_to_contribute *All right, we need to change something. What exactly?* 1. We need to introduce a team which manages content of Community App Catalog, decides which new assets can be added, decides on a workflow for apps publishing, maintaining, consuming. This team could be a complimentary team working alongside the Community App Catalog implementation team (engine, backend, frontend); or within the team itself 2. There should be separated repositories for source code of apps from Community App Catalog. These repositories should not be stored under openstack label as they do not relate to core OpenStack projects. Core project teams are not responsible for maintaining apps. 3. Bug tracking for apps should be separated from bug tracking for core projects. 4. There should be teams working on apps with core reviewers, IRC channels and mailing lists. These teams should differ from core projects teams. 5. Given #1 - #4 it seems reasonable to develop governance model specific for OpenStack Apps Community, which differs (when it’s necessary) from governance model of OpenStack Community. Let us develop such a governance model, implement changes described above and build community of OpenStack apps developers. PS. There is representative discussion in comments to https://review.openstack.org/#/c/309383/. Some team wants to add new repository for CI/CD Murano app. Should it be part of Murano core project? Rather not. Should it be part of BigTent? Well, rather not as BigTent is for core OpenStack services, not for workloads on top of it. At the same time team wants to use some OpenStack infra resources (at least gerrit for now) as this project is obviously beneficial for OpenStack. We need to have an ability to resolve similar requests in a centralized manner - there are more teams who want to publish source code of their OpenStack apps and there is no established workflow for that. *Agree. What’s next?* Suggested plan: - Introduce label openstack-apps, put repositories with source code of OpenStack Apps under it, i.e.: * http://git.openstack.org/cgit/openstack-apps/murano-apps * http://git.openstack.org/cgit/openstack-apps/heat-templates * http://git.openstack.org/cgit/openstack-apps/tosca-workflows - Agree with OpenStack Community App Catalog team on how content of App Catalog is managed and by whom - Describe workflow of how to add source code of new application to repositories, who approves its addition - Introduce simplified workflow of publishing new Application to the catalog: * register/login * push/update * done - Introduce teams (core reviewers) contributing to/maintaining Murano apps, Heat templates, ... - Establish channels of communications with potential contributors (mailing list, meetings, IRC/slack channel, ... ) - Agree with contributors on QA process for applications and how we track it in Community App Catalog To simplify commenting and tracking of the plan above I put last two sections with suggested steps to the etherpad https://etherpad.openstack.org/p/OpenStackAppsCommunity We're also discussing this topic with OpenStack Application Ecosystem Working Group and several members of OpenStack App Catalog team support this idea: http://lists.openstack.org/pipermail/user-committee/2016-May/000854.html Please share your thoughts and comments. Regards, Igor Marnat __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem: Inside VM "fuel-master"
Samer, great it works for you! :) Please don't hesitate to get in touch with the team in #fuel-dev if needed. Regards, Igor Marnat On Wed, Mar 9, 2016 at 4:38 PM, Samer Machara < samer.mach...@telecom-sudparis.eu> wrote: > Hi, > I already have VirtualBox 5.0; I run the script again, and now everything > is working well. > I finish the setup. Hurrah! finally, I'm going to work. > > Thanks > > -- > > Message: 15 > Date: Wed, 9 Mar 2016 11:16:33 +0100 (CET) > From: Samer Machara <samer.mach...@telecom-sudparis.eu> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [Fuel] [Openstack] Instalation Problem: > Inside VM "fuel-master" > Message-ID: > < > 56040978.58779783.1457518593738.javamail.zim...@telecom-sudparis.eu> > Content-Type: text/plain; charset="utf-8" > > Hello, > Someone can tell me what is this problem about? And how to solve it? > Thanks. > Samer Machara > > > > > Some information about my system: > OS: ubuntu 14.04 LTS > Memory: 3,8GiB > Processor: Intel? Core?2 Quad CPU Q9550 @ 2.83GHz ? 4 > OS type: 64-bit > Disk 140,2GB > VirtualBox Version: 4.3.36_Ubuntu > Checking for 'expect'... OK > Checking for 'xxd'... OK > Checking for "VBoxManage"... OK > Checking for VirtualBox Extension Pack... OK > Checking if SSH client installed... OK > Checking if ipconfig or ifconfig installed... OK > config.sh > # Section for custom configuration > vm_slave_memory_default=512 > vm_slave_memory_mb[1]=512 > vm_slave_memory_mb[2]=512 > vm_slave_memory_mb[3]=512 > > > - Original Message - > > From: "Igor Marnat" <imar...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Sent: Friday, March 4, 2016 3:12:21 PM > Subject: Re: [openstack-dev] [Fuel] [Openstack] Instalation > Problem:VBoxManage: error: Guest not running [ubuntu14.04] > > Samer, Maksim, > I'd rather say that script started fuel-master already (VM "fuel-master" > has been successfully started.), didn't find running guests, (VBoxManage: > error: Guest not running) but it can try to start them afterwards. > > Samer, > - how many VMs are there running besides fuel-master? > - is it still showing "Waiting for product VM to download files. Please do > NOT abort the script..." ? > - for how long did you wait since the message above? > > > Regards, > Igor Marnat > > On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk < mmalc...@mirantis.com > > wrote: > > > > Hi Sames, > > VBoxManage: error: Guest not running > > looks line the problem with VirtualBox itself or settings for the > 'fuel-master' VM, it can't boot it. > Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it > manually - it should show you what is exactly happens. > > > On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara < > samer.mach...@telecom-sudparis.eu > wrote: > > > > > > Hello, everyone. > I'm new with Fuel. I'm trying to follow the QuickStart Guide ( > https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html > ), but I have the following Error: > > > Waiting for VM "fuel-master" to power on... > VM "fuel-master" has been successfully started. > VBoxManage: error: Guest not running > VBoxManage: error: Guest not running > ... > VBoxManage: error: Guest not running > Waiting for product VM to download files. Please do NOT abort the script... > > > I hope you can help me. > > Thanks in advance > > > > > Some information about my system: > OS: ubuntu 14.04 LTS > Memory: 3,8GiB > Processor: Intel? Core?2 Quad CPU Q9550 @ 2.83GHz ? 4 > OS type: 64-bit > Disk 140,2GB > VirtualBox Version: 4.3.36_Ubuntu > Checking for 'expect'... OK > Checking for 'xxd'... OK > Checking for "VBoxManage"... OK > Checking for VirtualBox Extension Pack... OK > Checking if SSH client installed... OK > Checking if ipconfig or ifconfig installed... OK > > > > > > I modify the config.sh to adapt my hardware configuration > ... > # Master node settings > if [ "$CONFIG_FOR" = "4GB" ]; then > vm_master_memory_mb=1024 > vm_master_disk_mb=2 > ... > # The number of nodes for installing OpenStack on > elif [ "$CONFIG_FOR" = "4GB" ]; then > cluster_size=3 > ... > # Slave node settings. This section allows
Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]
Samer, did you make any progress? If not yet, I have couple of questions: - Did you download MOS image and VBox scripts from https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html#downloading-the-mirantis-openstack-image ? - Can you login to your just deployed master node? If you can, could you please send last 50-70 strings of the file /var/log/puppet/bootstrap_admin_node.log from your master node? Regards, Igor Marnat On Fri, Mar 4, 2016 at 11:20 PM, Maksim Malchuk <mmalc...@mirantis.com> wrote: > Samer, please address my recommendations. > > > On Fri, Mar 4, 2016 at 7:49 PM, Samer Machara < > samer.mach...@telecom-sudparis.eu> wrote: > >> Hi, Igor >> Thanks for answer so quickly. >> >> I wait until the following message appears >> Installation timed out! (3000 seconds) >> I don't have any virtual machines created. >> >> I update to 5.0 VirtualBox version, Now I got the following message >> >> VBoxManage: error: Machine 'fuel-master' is not currently running >> Waiting for product VM to download files. Please do NOT abort the >> script... >> >> I'm still waiting >> >> -- >> *De: *"Maksim Malchuk" <mmalc...@mirantis.com> >> *À: *"OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> *Envoyé: *Vendredi 4 Mars 2016 15:19:54 >> *Objet: *Re: [openstack-dev] [Fuel] [Openstack] Instalation >> Problem:VBoxManage: error: Guest not running [ubuntu14.04] >> >> >> Igor, >> >> Some information about my system: >> OS: ubuntu 14.04 LTS >> Memory: 3,8GiB >> >> Samer can't run many guests I think. >> >> >> On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat <imar...@mirantis.com> wrote: >> >>> Samer, Maksim, >>> I'd rather say that script started fuel-master already (VM "fuel-master" >>> has been successfully started.), didn't find running guests, (VBoxManage: >>> error: Guest not running) but it can try to start them afterwards. >>> >>> Samer, >>> - how many VMs are there running besides fuel-master? >>> - is it still showing "Waiting for product VM to download files. Please >>> do NOT abort the script..." ? >>> - for how long did you wait since the message above? >>> >>> >>> Regards, >>> Igor Marnat >>> >>> On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk <mmalc...@mirantis.com> >>> wrote: >>> >>>> Hi Sames, >>>> >>>> *VBoxManage: error: Guest not running* >>>> >>>> looks line the problem with VirtualBox itself or settings for the >>>> 'fuel-master' VM, it can't boot it. >>>> Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start >>>> it manually - it should show you what is exactly happens. >>>> >>>> >>>> On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara < >>>> samer.mach...@telecom-sudparis.eu> wrote: >>>> >>>>> Hello, everyone. >>>>> I'm new with Fuel. I'm trying to follow the QuickStart Guide ( >>>>> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html), >>>>> but I have the following Error: >>>>> >>>>> >>>>> *Waiting for VM "fuel-master" to power on...* >>>>> *VM "fuel-master" has been successfully started.* >>>>> *VBoxManage: error: Guest not running* >>>>> *VBoxManage: error: Guest not running* >>>>> ... >>>>> *VBoxManage: error: Guest not running* >>>>> *Waiting for product VM to download files. Please do NOT abort the >>>>> script...* >>>>> >>>>> >>>>> >>>>> I hope you can help me. >>>>> >>>>> Thanks in advance >>>>> >>>>> >>>>> Some information about my system: >>>>> OS: ubuntu 14.04 LTS >>>>> Memory: 3,8GiB >>>>> Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4 >>>>> OS type: 64-bit >>>>> Disk 140,2GB >>>>> VirtualBox Version: 4.3.36_Ubuntu >>>>> Checking for 'expect'... OK >>>>> Checking for 'xxd'... OK >>>>> Checking for "VBoxManage"... OK >>>>> Checking for VirtualBox Extension Pack... OK >>>>> Checking if SS
Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]
Samer, Maksim, I'd rather say that script started fuel-master already (VM "fuel-master" has been successfully started.), didn't find running guests, (VBoxManage: error: Guest not running) but it can try to start them afterwards. Samer, - how many VMs are there running besides fuel-master? - is it still showing "Waiting for product VM to download files. Please do NOT abort the script..." ? - for how long did you wait since the message above? Regards, Igor Marnat On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk <mmalc...@mirantis.com> wrote: > Hi Sames, > > *VBoxManage: error: Guest not running* > > looks line the problem with VirtualBox itself or settings for the > 'fuel-master' VM, it can't boot it. > Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it > manually - it should show you what is exactly happens. > > > On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara < > samer.mach...@telecom-sudparis.eu> wrote: > >> Hello, everyone. >> I'm new with Fuel. I'm trying to follow the QuickStart Guide ( >> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html), >> but I have the following Error: >> >> >> *Waiting for VM "fuel-master" to power on...* >> *VM "fuel-master" has been successfully started.* >> *VBoxManage: error: Guest not running* >> *VBoxManage: error: Guest not running* >> ... >> *VBoxManage: error: Guest not running* >> *Waiting for product VM to download files. Please do NOT abort the >> script...* >> >> >> >> I hope you can help me. >> >> Thanks in advance >> >> >> Some information about my system: >> OS: ubuntu 14.04 LTS >> Memory: 3,8GiB >> Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4 >> OS type: 64-bit >> Disk 140,2GB >> VirtualBox Version: 4.3.36_Ubuntu >> Checking for 'expect'... OK >> Checking for 'xxd'... OK >> Checking for "VBoxManage"... OK >> Checking for VirtualBox Extension Pack... OK >> Checking if SSH client installed... OK >> Checking if ipconfig or ifconfig installed... OK >> >> >> I modify the config.sh to adapt my hardware configuration >> ... >> # Master node settings >> if [ "$CONFIG_FOR" = "4GB" ]; then >> vm_master_memory_mb=1024 >> vm_master_disk_mb=2 >> ... >> # The number of nodes for installing OpenStack on >> elif [ "$CONFIG_FOR" = "4GB" ]; then >> cluster_size=3 >> ... >> # Slave node settings. This section allows you to define CPU count for >> each slave node. >> elif [ "$CONFIG_FOR" = "4GB" ]; then >> vm_slave_cpu_default=1 >> vm_slave_cpu[1]=1 >> vm_slave_cpu[2]=1 >> vm_slave_cpu[3]=1 >> ... >> # This section allows you to define RAM size in MB for each slave node. >> elif [ "$CONFIG_FOR" = "4GB" ]; then >> vm_slave_memory_default=1024 >> >> vm_slave_memory_mb[1]=512 >> vm_slave_memory_mb[2]=512 >> vm_slave_memory_mb[3]=512 >> ... >> # Nodes with combined roles may require more disk space. >> if [ "$CONFIG_FOR" = "4GB" ]; then >> vm_slave_first_disk_mb=2 >> vm_slave_second_disk_mb=2 >> vm_slave_third_disk_mb=2 >> ... >> >> I found someone that had a similar problem ( >> https://www.mail-archive.com/fuel-dev@lists.launchpad.net/msg01084.html), >> he had a corrupted iso file, he solved the problem downloaded it again. I >> downloaded the .iso file from >> http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent >> . I chek the size 3,1 GB. How ever I still with the problem. >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Best Regards, > Maksim Malchuk, > Senior DevOps Engineer, > MOS: Product Engineering, > Mirantis, Inc > <vgor...@mirantis.com> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2
Dmitry, Aleksandra, thank you for help and support! Regards, Igor Marnat On Fri, Mar 4, 2016 at 1:20 AM, Aleksandra Fedorova <afedor...@mirantis.com> wrote: > As we agreed, we have switched ISO builds to latest CentOS 7.2 snapshots. > > You can see now that each ISO build (see for ex. [1]) produces several > *_id.txt artifacts. > Note that centos_mirror_id.txt points to CentOS snapshot at > http://mirror.fuel-infra.org/pkgs/ > > BVT test is stable, see [2], and nightly system tests results are > basically the same as they were before. > > > [1] https://ci.fuel-infra.org/job/9.0-community.all/3868/ > [2] > https://ci.fuel-infra.org/view/ISO/job/9.0.fuel_community.ubuntu.bvt_2/ > > On Thu, Mar 3, 2016 at 3:46 AM, Dmitry Borodaenko > <dborodae...@mirantis.com> wrote: > > Thanks for the detailed explanation, very helpful! > > > > Considering that this change is atomic and easily revertable, lets > > proceed with the change, the sooner we do that the more time we'll have > > to confirm that there is no impact and revert if necessary. > > > > -- > > Dmitry Borodaenko > > > > On Thu, Mar 03, 2016 at 03:40:22AM +0300, Aleksandra Fedorova wrote: > >> Hi, > >> > >> let me add some details about the change: > >> > >> 1) There are two repositories used to build Fuel ISO: base OS > >> repository [1], and mos repository [2], where we put Fuel dependencies > >> and packages we rebuild due to certain version requirements. > >> > >> The CentOS 7.2 feature is related to the upstream repo only. Packages > >> like RabbitMQ, MCollective, Puppet, MySQL and PostgreSQL live in mos > >> repository, which has higher priority then upstream. > >> > >> I think we need to setup a separate discussion about our policy > >> regarding these packages, but for now they are fixed and won't be > >> updated by CentOS 7.2 switch. > >> > >> 2) This change doesn't affect Fuel codebase. > >> > >> The upstream mirror we use for ISO build is controlled by environment > >> variable which is set via Jenkins [3] and can be changed anytime. > >> > >> As we have daily snapshots of CentOS repository available at [4], in > >> case of regression in upstream we can pin our builds to stable > >> snapshot and work on the issue without blocking the main development > >> flow. > > > > Please make sure that the current snapshot of CentOS 7.1 is not rotated > > away so that we don't loose the point we can revert to. > > > >> 3) The "improve snapshotting" work item which is at the moment in > >> progress, will prevent any possibility to "accidentally" migrate to > >> CentOS 7.3, when it becomes available. > >> Thus the only changes which we can fetch from upstream are changes > >> which are published to updates/ component of CentOS 7.2 repo. > >> > >> > >> As latest BVT on master is green > >>https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/69/ > >> I think we should proceed with Jenkins reconfiguration [5] and switch > >> to latest snapshots by default. > >> > >> [1] currently http://vault.centos.org/7.1.1503/ > >> [2] > http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7-fuel/os/x86_64/ > >> [3] > https://github.com/fuel-infra/jenkins-jobs/blob/76b5cdf1828b7db1957f7967180d20be099b0c63/common/scripts/all.sh#L84 > >> [4] http://mirror.fuel-infra.org/pkgs/ > >> [5] https://review.fuel-infra.org/#/c/17712/ > >> > >> On Wed, Mar 2, 2016 at 9:22 PM, Mike Scherbakov > >> <mscherba...@mirantis.com> wrote: > >> > It is not just about BVT. I'd suggest to monitor situation overall, > >> > including failures of system tests [1]. If we see regressions there, > or some > >> > test cases will start flapping (what is even worse), then we'd have to > >> > revert back to CentOS 7.1. > >> > > >> > [1] https://github.com/openstack/fuel-qa > >> > > >> > On Wed, Mar 2, 2016 at 10:16 AM Dmitry Borodaenko < > dborodae...@mirantis.com> > >> > wrote: > >> >> > >> >> I agree with Mike's concerns, and propose to make these limitations > (4 > >> >> weeks before FF for OS upgrades, 2 weeks for upgrades of key > >> >> dependencies -- RabbitMQ, MCollective, Puppet, MySQL, PostgreSQL, > >> >> anything else?) official for 10.0/Newton. > >> >> > >> >> For 9.0/Mitaka, it
Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2
Igor, couple of points from my side. CentOS 7.2 will be getting updates for several more months, and we have snapshots and all the mechanics in place to switch to the next version when needed. Speaking of getting this update into 9.0, we actually don't need FFE, we can merge remaining staff today. It has enough reviews, so if you add your +1 today, we don't need FFE. https://review.openstack.org/#/c/280338/ https://review.fuel-infra.org/#/c/17400/ Regards, Igor Marnat On Wed, Mar 2, 2016 at 6:23 PM, Dmitry Teselkin <dtesel...@mirantis.com> wrote: > Igor, > > Your statement about updates for 7.2 isn't correct - it will receive > updates, because it's the latest release ATM. There is *no* pinning inside > ISO, and the only place where it was 8.0 were docker containers just > because we had to workaround some issues. But there are no docker > containers in 9.0, so that's not the case. > The proposed solution to switch to CentOS-7.2 in fact is based on > selecting the right snapshot with packages. There is no pinning in ISO (it > was in earlier versions of the spec but was removed). > > On Wed, Mar 2, 2016 at 6:11 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: > >> Dmitry, Igor, >> >> > Very important thing is that CentOS 7.1 which master node is based now >> > don't get updates any longer. >> >> If you are using "fixed" release you must be ready that you won't get >> any updates. So with CentOS 7.2 the problem still the same. >> >> However, let's wait for Fuel PTL decision. I only shared my POV: >> that's not a critical feature, and taking into account the risks of >> regression - I'd prefer to do not accept it in 9.0. >> >> Regards, >> Igor >> >> On Wed, Mar 2, 2016 at 4:42 PM, Igor Marnat <imar...@mirantis.com> wrote: >> > Igor, >> > please note that this is pretty much not like update of master node >> which we >> > had in 8.0. This is minor _update_ of CentOS from 7.1 to 7.2 which team >> > tested for more than 2 months already. >> > >> > We don't expect it to require any additional efforts from core or qa >> team. >> > >> > Very important thing is that CentOS 7.1 which master node is based now >> don't >> > get updates any longer. Updates are only provided for CentOS 7.2. >> > >> > So we'll have to switch CentOS 7.1 to CentOS 7.2 anyways. >> > >> > We can do it now for more or less free, later in release cycle for >> higher >> > risk and QA efforts and after the release for 2x price because of >> additional >> > QA cycle we'll need to pass through. >> > >> > >> > >> > Regards, >> > Igor Marnat >> > >> > On Wed, Mar 2, 2016 at 2:57 PM, Dmitry Teselkin <dtesel...@mirantis.com >> > >> > wrote: >> >> >> >> Hi Igor, >> >> >> >> Postponing this till Fuel 10 means we have to elaborate a plan to do >> such >> >> upgrade for Fuel 9 after the release - the underlying system will not >> get >> >> updated on it's own, and the security issues will not close >> themselves. The >> >> problem here is that such upgrade of deployed master node requires a >> lot of >> >> QA work also. >> >> >> >> Since we are not going to update package we build on our own (they >> still >> >> targeted 7.1) switching master node base to CentOS-72 is not that >> dangerous >> >> as it seems. >> >> >> >> On Wed, Mar 2, 2016 at 1:54 PM, Igor Kalnitsky < >> ikalnit...@mirantis.com> >> >> wrote: >> >>> >> >>> Hey Dmitry, >> >>> >> >>> No offence, but I rather against that exception. We have too many >> >>> things to do in Mitaka, and moving to CentOS 7.2 means >> >>> >> >>> * extra effort from core team >> >>> * extra effort from qa team >> >>> >> >>> Moreover, it might block development by introducing unpredictable >> >>> regressions. Remember 8.0? So I think it'd be better to reduce risk of >> >>> regressions that affects so many developers by postponing CentOS 7.2 >> >>> till Fuel 10. >> >>> >> >>> Thanks, >> >>> Igor >> >>> >> >>> >> >>> On Mon, Feb 29, 2016 at 7:13 PM, Dmitry Teselkin < >> dtesel...@mirantis.com> >> >>> wrote: >> >>> > I'd like to ask for a fe
Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2
Igor, please note that this is pretty much not like update of master node which we had in 8.0. This is minor _update_ of CentOS from 7.1 to 7.2 which team tested for more than 2 months already. We don't expect it to require any additional efforts from core or qa team. Very important thing is that CentOS 7.1 which master node is based now don't get updates any longer. Updates are only provided for CentOS 7.2. So we'll have to switch CentOS 7.1 to CentOS 7.2 anyways. We can do it now for more or less free, later in release cycle for higher risk and QA efforts and after the release for 2x price because of additional QA cycle we'll need to pass through. Regards, Igor Marnat On Wed, Mar 2, 2016 at 2:57 PM, Dmitry Teselkin <dtesel...@mirantis.com> wrote: > Hi Igor, > > Postponing this till Fuel 10 means we have to elaborate a plan to do such > upgrade for Fuel 9 after the release - the underlying system will not get > updated on it's own, and the security issues will not close themselves. The > problem here is that such upgrade of deployed master node requires a lot of > QA work also. > > Since we are not going to update package we build on our own (they still > targeted 7.1) switching master node base to CentOS-72 is not that dangerous > as it seems. > > On Wed, Mar 2, 2016 at 1:54 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: > >> Hey Dmitry, >> >> No offence, but I rather against that exception. We have too many >> things to do in Mitaka, and moving to CentOS 7.2 means >> >> * extra effort from core team >> * extra effort from qa team >> >> Moreover, it might block development by introducing unpredictable >> regressions. Remember 8.0? So I think it'd be better to reduce risk of >> regressions that affects so many developers by postponing CentOS 7.2 >> till Fuel 10. >> >> Thanks, >> Igor >> >> >> On Mon, Feb 29, 2016 at 7:13 PM, Dmitry Teselkin <dtesel...@mirantis.com> >> wrote: >> > I'd like to ask for a feature freeze exception for switching to >> CentOS-7.2 >> > feature [0]. >> > >> > CentOS-7.2 ISO's have been tested periodically since the beginning of >> the >> > year, and all major issues were addressed / fixed at the moment. During >> the >> > last weekend I've made 70 BVT runs to verify that the solution [2] for >> the >> > last issue - e1000 transmit unit hangs works. And it works, 0 tests of >> 35 >> > failed [3]. >> > >> > Benefits of switching to CentOS-7.2 are quite obvious - we will return >> to >> > latest supported CentOS release, will fix a lot of bugs / security >> issues >> > [4] and will make further updates easier. >> > >> > Risk of regression still exists, but it's quite low, 35 successful BVTs >> > can't be wrong. >> > >> > To finish that feature the following should be done: >> > * review and merge e1000 workaround [2] >> > * review and merge spec [0] >> > * review and merge request that switches build CI to CentOS-7.2 [5] >> > >> > I expect the last day it could be done is March, 4. >> > >> > [0] https://review.openstack.org/#/c/280338/ >> > [1] https://bugs.launchpad.net/fuel/+bug/1526544 >> > [2] https://review.openstack.org/#/c/285306/ >> > [3] https://etherpad.openstack.org/p/r.1c4cfee8185326d6922d6c9321404350 >> > [4] https://etherpad.openstack.org/p/r.a7fe0b575d891ed81206765fa5be6630 >> > [5] https://review.fuel-infra.org/#/c/17400/ >> > >> > >> > -- >> > Thanks, >> > Dmitry Teselkin >> > Mirantis >> > http://www.mirantis.com >> > >> > >> __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Thanks, > Dmitry Teselkin > Mirantis > http://www.mirantis.com > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core reviewers
Folks, I'm not a core reviewer, but if I was, I'd definitely vote with +1. Good job, Anastasia! Keep going! Regards, Igor Marnat On Fri, Jan 29, 2016 at 10:23 AM, Elisha, Moshe (Nokia - IL) < moshe.eli...@nokia.com> wrote: > A very big +1 > > From: Renat Akhmerov [rakhme...@mirantis.com] > Sent: Friday, January 29, 2016 8:13 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core > reviewers > > Team, > > I’d like to promote Anastasia Kuznetsova to the core team. What she’s been > doing for 2 years is hard to overestimate. She’s done a huge amount of work > reviewing code, bugfixing and participating in public discussions including > our IRC channel #openstack-mistral. She is very reliable, diligent and > consistent about her work. > > Please vote. > > Renat Akhmerov > @ Mirantis Inc. > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nominate Artem Panchenko for fuel-qa core
Folks, I'm not a fuel-qa core, but if I was, I'd vote with +1:) I'm really impressed with quality of analysis which Artem provides in bug reports and his overall help with bugs resolving. Keep going! Regards, Igor Marnat On Wed, Dec 23, 2015 at 8:05 PM, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Artem is doing a great job! Definitely +1. > > On Wed, Dec 23, 2015 at 4:33 PM, Bulat Gaifullin > <bgaiful...@mirantis.com> wrote: > > +1 > > > > Regards, > > Bulat Gaifullin > > Mirantis Inc. > > > > > > > > On 23 Dec 2015, at 17:29, Aleksey Kasatkin <akasat...@mirantis.com> > wrote: > > > > +1 > > > > Aleksey Kasatkin > > > > > > On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko < > adide...@mirantis.com> > > wrote: > >> > >> +1 > >> > >> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich > >> <tleontov...@mirantis.com> wrote: > >>> > >>> Absolutely agree > >>> > >>> +1 > >>> > >>> > >>> > >>> > >>> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy > >>> <asledzins...@mirantis.com> wrote: > >>>> > >>>> Hi guys, > >>>> I'd like to nominate Artem Panchenko [0] for fuel-qa core. > >>>> > >>>> Artem has great technical expertise in fuel-qa and he developed a lot > of > >>>> vital parts of framework. His first place in a number of commits is a > good > >>>> proof of that. > >>>> His reviews are always thorough and consistent. > >>>> Please, vote for Artem! > >>>> > >>>> [0] > >>>> > http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa > >>>> > >>>> -- > >>>> Thanks, > >>>> Andrey Sledzinskiy > >>>> QA Engineer, > >>>> Mirantis, Kharkiv > >>>> > >>>> > >>>> > __ > >>>> OpenStack Development Mailing List (not for usage questions) > >>>> Unsubscribe: > >>>> openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] CentOS7 Merging Plan
Dmitry, thank you! I confirm that the plan looks good for our team, we'll follow it. Regards, Igor Marnat On Wed, Dec 2, 2015 at 9:39 PM, Andrew Maksimov <amaksi...@mirantis.com> wrote: > Thank you Dmitry for very detailed plan and risks assessment. > Do we want to run swarm against custom iso with centos7 on Thu evening to > measure level of regression? I remember that we were considering this > approach. > > Regards, > Andrey Maximov > > > On Wed, Dec 2, 2015 at 12:48 AM, Dmitry Borodaenko < > dborodae...@mirantis.com> wrote: > >> With bit more details, I hope this covers all the risks and decision >> points now. >> >> First of all, current list of outstanding commits: >> https://etherpad.openstack.org/p/fuel_on_centos7 >> >> The above list has two sections: backwards compatible changes that can >> be merged one at a time even if the rest of CentOS7 support isn't >> merged, and backwards incompatible changes that break support for >> CentOS6 and must be merged (and, if needed, reverted) all at once. >> >> Decision point 1: FFE for CentOS7 >> >> CentOS7 support cannot be fully merged on Dec 2, so it misses FF. Can it >> be allowed a Feature Freeze Exception? So far, the disruption of the >> Fuel development process implied by the proposed merge plan is >> acceptable, if anything goes wrong and we become unable to have a stable >> ISO with merged CentOS7 support on Monday, December 7, the FFE will be >> revoked. >> >> Wed, Dec 2: Merge party >> >> Merge party before 8.0 FF, we should do our best to merge all remaining >> feature commits before end of day (including backwards compatible >> CentOS7 support commits), without breaking the build too much. >> >> At the end of the day we'll start a swarm test over the result of the >> merge party, and we expect QA to analyze and summarize the results by >> 17:00 MSK (6:00 PST) on Thu Dec 3. >> >> Risk 1: Merge party breaks the build >> >> If there is a large regression in swarm pass percentage, we won't be >> able to afford a merge freeze which is necessary to merge CentOS7 >> support, we'll have to be merging bugfixes until swarm test pass rate is >> back around 70%. >> >> Risk 2: More features get FFE >> >> If some essential 8.0 features are not completely merged by end of day >> Wed Dec 2 and are granted FFE, merging the remaining commits can >> interfere with merging CentOS7 support, not just from merge conflicts >> perspective, but also invalidating swarm results and making it >> practically impossible to bisect and attribute potential regressions. >> >> Thu, Dec 3: Start merge freeze for CentOS7 >> >> Decision point 2: Other FFEs >> >> In the morning MSK time, we will assess Risk 2 and decide what to do >> with the other FFEs. The options are: integrate remaining commits into >> CentOS7 merge plan, block remaining commits until Monday, revoke CentOS7 >> FFE. >> >> If the decision is to go ahead with CentOS7 merge, we announce merge >> freeze for all git repositories that go into Fuel ISO, and spend the >> rest of the day rebasing and cleaning up the rest of the CentOS7 commits >> to make sure they're all in mergeable state by the end of the day. The >> outcome of this work must be a custom ISO image with all remaining >> commits, with additional requirement that it must not use Jenkins job >> parameters (only patches to fuel-main that change default repository >> paths) to specify all required package repositories. This will validate >> the proposed fuel-main patches and ensure that no unmerged package >> changes are used to produce the ISO. >> >> Decision point 3: Swarm pass rate >> >> After swarm results from Wed are available, we will assess the Risk 1. >> If the pass rate regression is significant, CentOS7 FFE is revoked and >> merge freeze is lifted. If regression is acceptable, we proceed with >> merging remaining CentOS7 commmits through Thu Dec 3 and Fri Dec 4. >> >> Fri, Dec 4: Merge and test CentOS7 >> >> The team will have until 17:00 MSK to produce a non-custom ISO that >> passes BVT and can be run through swarm. >> >> Sat, Dec 5: Assess CentOS7 swarm and bugfix >> >> First of all, someone from CI and QA teams should commit to monitoring >> the CentOS7 swarm run and report the results as soon as possible. Based >> on the results (which once again must be available by 17:00 MSK), we can >> decide on the final step of the plan. >> >> Decision point 4: Keep or revert >> >> I
Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues
Mike, speaking of automation, AFAIK Boris Pavlovic introduced some scripts in Rally which do basic preliminary check of review message, checking that it's formally correct. It should make life of reviewers a bit easier, you might want to introduce them in Fuel as well, if not yet. Regards, Igor Marnat On Thu, Aug 27, 2015 at 5:37 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I'm all in for any formalization and automation of review process. The only concern that I see here is about core reviewers involvement metrics. If we succeed in reducing the load on core reviewers, it will mean that core reviewers will do less code reviews. This could lead to core reviewer demotion. - Contributor finds SME to review the code. Ideally, contributor can have his/her peers to help with code review first. Contributor doesn’t bother SME, if CI has -1 on a patch proposed I like the idea with adding reviewers automatically based on MAINTAINERS file. In such case we can drop this ^^ part of instruction. It would be nice if Jenkins could add reviewers after CI +1, or we can use gerrit dashboard for SMEs to not waste their time on review that has not yet passed CI and does not have +1 from other reviewers. Regards, Alex On Wed, Aug 19, 2015 at 11:31 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi all, let's discuss code review process in Fuel and what we can improve. For those who want to just have a quick context of this email, please check out presentation slides [5]. ** Issues ** Depending on a Fuel subproject, I'm aware of two buckets of issues with code review in Fuel: a) It is hard to get code reviewed and merged b) Quality of code review itself could be better First bucket: 1) It is hard to find subject matter experts who can help and core reviewers for the area of code, especially if you are new to the project 2) Contributor sometimes receives contradicting opinions from other reviewers, including cores 3) Assigned / responsible core reviewer is needed for a feature in order to help in architectural negotiations, guiding through, landing the code into master 4) Long wait time for getting code reviewed Quality-related items: 5) Not thorough enough, full review in one shot. For example, reviewer can put -1 due to missed comma, but do not notice major gap in the code. It leads to many patch sets, and demotivation of contributors 6) Some of the core reviewers decreased their involvement, and so number of reviews has dropped dramatically. However, they still occasionally merge code. I propose to remove these cores, and get them back if their involvement is increased back again (I very rarely merge code, but I'm one of those to be removed from cores). This is standard practice in OpenStack community as well, see Neutron as example [4, line 270]. 7) As a legacy of the past, we still have old core reviewers being able to merge code in all Fuel repos. All new cores have core rights only for single repo, which is their primary area of expertise. For example, core team size for fuel-library is adidenko + whole fuel-core group [7]. In fact, there are just 4 trusted or real core reviewers in fuel-library, not the whole fuel-core group. These problems are not new to OpenStack and open source in general. You can find discussions about same and similar issues in [1], [2], [3]. ** Analysis of data ** In order to understand what can be improved, I mined the data at first. Main source of information was stackalytics.com. Please take a look at few graphs on slides 4-7 [5], built based on data from stackalytics. Major conclusions from these graphs: 1) Rather small number of core reviewers (in comparison with overall number of contributors) reviewing 40-60% of patch sets, depending on repo (40% fuel-library, 60% fuel-web). See slide #4. 2) Load on core reviewers in Fuel team is higher in average, if you compare it with some other OpenStack projects. Average load on core reviewer across Nova, Keystone, Neutron and Cinder is 2.5 reviews a day. In Fuel though it is 3.6 for fuel-web and 4.6 for fuel-library. See slide #6. 3) Statistics on how fast feedback on code proposed is provided: - fuel-library: 2095 total reviews in 30 days [13], 80 open reviews, average wait time for reviewer - 1d 1h [12] - fuel-web: 1789 total reviews in 30 days [14], 52 open reviews, average wait time for reviewer - 1d 17h [15] There is no need to have deep analysis on whether we have well defined areas of ownership in Fuel components or not: we don’t have it formally defined, and it’s not documented anywhere. So, finding a right core reviewer can be challenging task for a new contributor to Fuel, and this issue has to be addressed. ** Proposed solution ** According to stackalytics, for the whole fuel-group we had 262 reviewers with 24 core reviewers for the past 180 days [19]. I think that these numbers can be considered as high enough in order to think
Re: [openstack-dev] [fuel] Branching strategy vs feature freeze
Thierry, Dmitry, key point is that we in Fuel need to follow as much community adopted process as we can, and not to introduce something Fuel specific. We need not only to avoid forking code, but also to avoid forking processes and approaches for Fuel. Both #2 and #3 allow it, making it easier for contributors to participate in the Fuel. #3 (having internal repos for pre-release preparation, bug fixing and small custom features) from community perspective is the same as #2, provided that all the code from these internal repos always ends up being committed upstream. Purely internal logistics. The only one additional note from my side is that we might want to consider an approach slightly adopted similar to what's there in Puppet modules. AFAIK, they are typically released several weeks later than Openstack code. This is natural for Fuel as it depends on these modules and packaging of Openstack. Regards, Igor Marnat On Wed, Aug 26, 2015 at 1:04 PM, Thierry Carrez thie...@openstack.org wrote: Dmitry Borodaenko wrote: TL;DR was actually hidden in the middle of the email, here's an even shorter version: 0) we're suffering from closing master for feature work for too long 1) continuously rebased future branch is most likely a no-go 2) short FF (SCF and stable branch after 2 weeks) is an option for 8.0 3) short FF with stable in a separate internal gerrit was also proposed 4) merits and cost of enabling CI setup for private forks should be carefully considered independently from other options Should come as no surprise that I encourage you to follow (2), especially as we work to further align Fuel with OpenStack ways so that it can be added as an official project team. Note that the two weeks is not really a hard requirement (could be more, or less). In this model you need to come up with a release candidate, which is where we create the release branch, which becomes a stable branch at the end of the cycle. It usually takes 2 to 4 weeks for OpenStack projects to get to that stage, but you could get there in 2 days or 5 weeks and it would still work (the key is to publish at least one release candidate before the end of the cycle). It's a balance between the pain of backporting fixes and the pain of freezing master. At one point the flow of fixes slows down enough and/or the pressure to unfreeze master becomes too strong: that's when you should create the release branch. Hope this helps, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Working on 6.0 and new releases in general
Mike, just to clarify - do we want consider this as an exception, which is not going to be repeated next release? If not, we might want to consider updating the statement It is the time when master opens for next release changes, including features. in [1]. If I got you correct, we are going to open master for development of new features now. [1] https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze Regards, Igor Marnat On Tue, Sep 9, 2014 at 12:07 PM, Mike Scherbakov mscherba...@mirantis.com wrote: +1 to DmitryB, I think in this particular time and case we should open stable/5.1. But not to call it HCF [1]. Though I think we should retrospect our approaches here. Sometimes we can squash 30 bugs a day, and formally reach HCF. Though the day after we will get 30 New bugs from QA. We might want to reconsider the whole approach on criteria, and come up with flow instead. Like if we have =5 High bugs at the moment, and over last 3 days we were seeing 10 confirmed High/Critical bugs, then we can call for HCF (if 60 bugs in 3 last days, then no way for HCF) Consumption of new OpenStack release is hard and will be as such unless we will be using Fuel in gating process for every patch being pushed to OpenStack upstream. We want to deploy Juno now for 6.0, and the only way to do it now - is to build all packages, try to run it, observe issues, fix, run again, observe other issues... - and this process continues for many iterations before we get stable ISO which passes BVTs. It is obvious, that if we drop the Juno packages in, then our master is going to be broken. If we do any other feature development, then we don't know whether it's because Juno or that another feature. What should we do then? My suggestion on #2 is that we could keep backward compatibility with Icehouse code (on puppet side), and can continue to use BVT's, other testing against master branch using both Icehouse packages and Juno. Thus we can keep using gating process for fuel library, relying on stable Icehouse version. As for immediate action, again, I'm in favor of creating stable/5.1 in order to unblock feature development in master, while we are fixing last issues with OpenStack patching. [1] https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze On Tue, Sep 9, 2014 at 5:55 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: TL;DR: Yes, our work on 6.0 features is currently blocked and it is becoming a major problem. No, I don't think we should create pre-release or feature branches. Instead, we should create stable/5.1 branches and open master for 6.0 work. We have reached a point in 5.1 release cycle where the scope of issues we are willing to address in this release is narrow enough to not require full attention of the whole team. We have engineers working on 6.0 features, and their work is essentially blocked until they have somewhere to commit their changes. Simply creating new branches is not even close to solving this problem: we have a whole CI infrastructure around every active release series (currently 5.1, 5.0, 4.1), including test jobs for gerrit commits, package repository mirrors updates, ISO image builds, smoke, build verification, and swarm tests for ISO images, documentation builds, etc. A branch without all that infrastructure isn't any better than current status quo: every developer tracking their own 6.0 work locally. Unrelated to all that, we also had a lot of very negative experience with feature branches in the past [0] [1], which is why we have decided to follow the OpenStack branching strategy: commit all feature changes directly to master and track bugfixes for stable releases in stable/* branches. [0] https://lists.launchpad.net/fuel-dev/msg00127.html [1] https://lists.launchpad.net/fuel-dev/msg00028.html I'm also against declaring a hard code freeze with exceptions, HCF should remain tied to our ability to declare a release candidate. If we can't release with the bugs we already know about, declaring HCF before fixing these bugs would be an empty gesture. Creating stable/5.1 now instead of waiting for hard code freeze for 5.1 will cost us two things: 1) DevOps team will have to update our CI infrastructure for one more release series. It's something we have to do for 6.0 sooner or later, so this may be a disruption, but not an additional effort. 2) All commits targeted for 5.1 will have to be proposed for two branches (master and stable/5.1) instead of just one (master). This will require additional effort, but I think that it is significantly smaller than the cost of spinning our wheels on 6.0 efforts. -DmitryB On Mon, Sep 8, 2014 at 10:10 AM, Dmitry Mescheryakov dmescherya...@mirantis.com wrote: Hello Fuelers, Right now we have the following policy in place: the branches for a release are opened only after its 'parent' release have reached hard code freeze (HCF). Say, 5.1 release is parent releases for 5.1.1
Re: [openstack-dev] [Trove][Savanna][Murano] Unified Agent proposal discussion at Summit
Ilya, that's cool! Mind if Murano and Savanna teams join the same etherpad? Regards, Igor Marnat On Tue, Nov 12, 2013 at 6:58 PM, Ilya Sviridov isviri...@mirantis.comwrote: Thinking in that direction, the Trove team had a design session about current status of agent in project. Just take a look https://etherpad.openstack.org/p/TroveGuestAgents With best regards, Ilya Sviridov http://www.mirantis.ru/ On Tue, Nov 12, 2013 at 4:29 PM, Igor Marnat imar...@mirantis.com wrote: Just to summarize, there was an interest expressed from Murano, Trove, Savanna and Heat teams in regards with implementation of this unified agent. Nothing specific was decided expect suggestion to keep pushing. I'd suggest to keep pushing this way: - create an etherpad - each team interested in having unified agent writes there detailed use cases for an agent to this etherpad - based on these use-cases we can generate very specific and detailed requirements to the agent - based on these requirements we can agree on architecture and approach to implementation. Teams? Regards, Igor Marnat On Tue, Nov 5, 2013 at 6:10 AM, Alexander Tivelkov ativel...@mirantis.com wrote: Hi guys, Recently we had several discussions about the guest VM agents: lot's of projects have the similar needs to run some special logic on the side of guest virtual machines. As far as I know, there are such agents in Savanna, Trove, Murano and may be some other projects as well. The obvious idea is to unite the efforts and have the unified solution which may satisfy everybody's needs. We've discussed this topic before with some of the teams, and got the promising-looking idea to create kind of unified agent library and put it in Oslo or some other shared project. We've scheduled an unconference session on the Summit, this Friday at 3:10 pm. Let's continue discussing the idea there: we may gather the common requirements, discuss the basic design concepts etc. See you there! -- Kind Regards, Alexander Tivelkov Principal Software Engineer OpenStack Platform Product division Mirantis, Inc +7(495) 640 4904, ext 0236 +7-926-267-37-97(cell) Vorontsovskaya street 35 B, building 3, Moscow, Russia. ativel...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
