[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] Unrelated changes in patches

Dmitry Guryanov wrote: > It's often not so easy to decide, if you should include some unrelated > changes to your patch, like fixing spaces, renaming variables or > something else, which don't change logic. I'd say it depends. If, for example, variable name is used inside one function - it's ok to

[openstack-dev] [fuel] API changes for Nailgun openstack config

Hi all, Please be informed that in accordance to bug [1] openstack config API will support bulk operations for 9.0 release. 'node_id' integer parameter is replaced by 'node_ids' list in all related handlers. * URL query parameter in GET /openstack-config/ * POST /openstack-config/ * PUT /openstac

Re: [openstack-dev] [fuel] Unrelated changes in patches

On 04/04/2016 07:05 AM, Matthew Mosesohn wrote: > Hi Dmitry, > > I've seen several cases where core reviewers bully contributors into > refactoring a particular piece of logic because it contains common > lines relating to some non-ideal code, even if the change doesn't > relate to this logic. > In

Re: [openstack-dev] [fuel] Unrelated changes in patches

Hi Dmitry, I've seen several cases where core reviewers bully contributors into refactoring a particular piece of logic because it contains common lines relating to some non-ideal code, even if the change doesn't relate to this logic. In general, I'm ok with formatting issues, but changing how a p

[openstack-dev] [fuel] Unrelated changes in patches

Hello, colleagues! It's often not so easy to decide, if you should include some unrelated changes to your patch, like fixing spaces, renaming variables or something else, which don't change logic. On the one hand you see something's wrong with the code and you'd like to fix it, on the other hand r

Re: [openstack-dev] [Fuel] branching Mitaka April 6, 2016

What about plugins? For instance: fuel-plugin-detach-keystone -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Mon, Apr 4, 2016 at 1:44 PM, Igor Belikov wrote: > Hi, > > Fuel SCF will be taking place on April 6th, this means that we’re going to > create stable/mitaka branches

Re: [openstack-dev] [Fuel] branching Mitaka April 6, 2016

Hi, Igor thank you for update. Folks, I also kindly ask to review the list of patch-sets regarding SCF [1] We've already built custom iso (with [1]) which passed BVT tests [1]. https://review.openstack.org/#/q/topic:9.0-scf,n,z 2016-04-04 14:44 GMT+03:00 Igor Belikov : > Hi, > > Fuel SCF will

[openstack-dev] [Fuel] branching Mitaka April 6, 2016

Hi, Fuel SCF will be taking place on April 6th, this means that we’re going to create stable/mitaka branches for a number of Fuel repos. PLEASE, take a look at the following list and respond if you think your project should be included or excluded from the list: * fuel-agent * fuel-astute * fue

[openstack-dev] [fuel]

Hi team, An issue with rsync was recently reported [0]. We have a symlink 'liberty-9.0/modules/osnailyfacter/modular/master' to examples directory in a fuel master node. However, rsync does not copy the symlink to slave nodes. Being easy to fix (by adding -l flag) this issue raises a question: do

[openstack-dev] [Fuel] Newton Design Summit sessions planning

Dear colleagues, Looks like we have final version sessions layout [1] for Austin design summit. We have 3 fishbows, 11 workrooms, full day meetup. Here you can find some useful information about design summit [2]. All session leads must read this page, be prepared for their sessions (agenda, slid

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

Hi Alex +1 to your proposal - this is long-awaited change. On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko wrote: > One more thing about spec to fixture mapping [0]. What if instead of: > > # RUN: (hiera1) (facts1) > > we'll use > > # RUN: (roles_array1) (facts1) > > ? > > We don't need to du

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

One more thing about spec to fixture mapping [0]. What if instead of: # RUN: (hiera1) (facts1) we'll use # RUN: (roles_array1) (facts1) ? We don't need to duplicate complicated task graph calculations to understand which task to execute, because we don't care about tasks ordering and dependenc

[openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

Hi. As you may know, we're still using some very old astute.yaml fixtures (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have problems with fixture-to-rspec mapping [1]. So we've started to work on those problems [2]. So please be aware of upcoming changes in noop rspec

Re: [openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

Bogdan, I mostly agree with you on this. The only data that might originate from a node is discovery-related parameters, like CPU/disks/NICs architecture and such. However, at the moment the deployment data is partially generated at every node (i.e. globals.yaml, override/plugins/* and some other

Re: [openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

On 04/01/2016 10:41 AM, Oleg Gelbukh wrote: > Andrew, > > This is an excellent idea. It is apparently more efficient and > error-proof to make the split not by the resulted data but at the time > it is actually generated. We will play with this idea a little bit, and > will come up with design pro

Re: [openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

Andrew, This is an excellent idea. It is apparently more efficient and error-proof to make the split not by the resulted data but at the time it is actually generated. We will play with this idea a little bit, and will come up with design proposal shortly. Meanwhile, please be informed that we al

[openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

One of the problems we've faced with trying to plug-in ConfigDB is trying to separate the cluster attributes from the node attributes in the serialized output (ie astute.yaml) I started talking with Alex S about how we could separate them after astute.yaml is prepared trying to ensure which was wh

Re: [openstack-dev] [fuel] Component Leads Elections

Hi fuelers, only few hours left until period of self-nomination will be closed, but so far we don't have neither consensus regarding how to proceed further nor candidates. I've increased period of self-nomination for another week (until April 7, 23:59 UTC) and expect to have decision about how we

[openstack-dev] [Fuel] CI may be broken for about 2 hours

We’ve organized a tiger team in order to merge two patches with a series of patches [1,2] in order to fix a swarm blocker. Our plan is the following: 1) Merge [1] and [2] 2) Trigger a build 3) Upload the new ISO to the CI system while it lasses the BVT 4) If the BVT is fine, switch the CI system

Re: [openstack-dev] [Fuel][library] CI gate for regressions detection in deployment data

It is time for update! The previous idea with the committed state and automatic cross-repo merge hooks in zuul seems too complex to implement. So, the "CI gate for blah blah" magically becomes now a manual helper tool for reviewers/developers, see the docs update [0], [1]. You may start using it r

[openstack-dev] [Fuel][Swarm blocker] Release data contain liberty name on mitaka packages

Folks, There is a bug that is tagged as a swarm blocker [1] and two patches that fix it. One of them is for nailgun [2] and another one is for fuel-library [3]. The reason I write here is that those patches seem to fix the issue but they will never pass tests on the CI when they are tested apar

Re: [openstack-dev] [FUEL] Timeout of deployment is exceeded & Fuel does not autodetect my hardware.

Hi, Sergii Here is the bug: https://bugs.launchpad.net/fuel/+bug/1564312 with the diagnostic snapshot. - Original Message - Sergii Golovatiuk sgolovatiuk at mirantis.com Thu Mar 31 09:09:39 UTC 2016 * Previous message: [openstack-dev] [FUEL] Timeout of deployment is exceeded

Re: [openstack-dev] [FUEL] Timeout of deployment is exceeded & Fuel does not autodetect my hardware.

Hi, According to logs I see manifest /etc/puppet/modules/osnailyfacter/modular/ceilometer/controller.pp was exceeded. However, at the same time I don't see any puppet.logs from primary-controllers :\ Though analysing other tasks like database.pp it was executed for 10 minutes when it usually tak

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hi, Problems which I see with current Shotgun are: 1. Luck of parallelism, so it's not going to fetch data fast enough from medium/big clouds. 2. There should be an easy way to run it manually (it's possible, but there is no ready-to-use config), it would be really helpful in case if Nailgun/Astut

Re: [openstack-dev] [fuel] Component Leads Elections

Hi, I'm not sure if it's a right place to continue this discussion, but if there are doubts that such role is needed, we should not wait for another half a year to drop it. Also I'm not sure if a single engineer (or two engineers) can handle majority of upcoming patches + specs + meetings around

Re: [openstack-dev] [Fuel] New version of fuel-devops (2.9.20)

I’ve just tried to look up for fuel-devops on PyPi and found nothing. Let’s set up everything to let OpenStack CI release this package to PyPi and start publish releases there. Also it’s better to use openstack-announce to announce new releases. - romcheg > 31 бер. 2016 р. о 11:52 Dennis Dmi

[openstack-dev] [Fuel] New version of fuel-devops (2.9.20)

Hi All, We are going to update the 'fuel-devops' framework on our product CI to the version 2.9.20. Changes since 2.9.17: * Fixes: - Fixes related to time synchronization issues: [1], [2], [10] - Fix for 'dos.py create' CLI command [4] - Use 0644 access mode for libvirt volumes created by fuel-

Re: [openstack-dev] [Fuel] [RDO] Volunteers needed

Aleksandra, You are right, we need to split this task into several smaller work items. For the start, I have created BP [1]. Let's discuss this on Fuel IRC meeting [2] today. I have put this topic to the agenda. And this is a great idea to put this task into the list for interns. I'll certainly d

Re: [openstack-dev] [FUEL] Timeout of deployment is exceeded & Fuel does not autodetect my hardware.

Hi Samer, On Thu, Mar 31, 2016 at 10:18 AM, Samer Machara < samer.mach...@telecom-sudparis.eu> wrote: > Bonjour, Hello. > > I'm trying to deploy the basic 3 nodes architecture to learn OpenStack: > 1 controller and 2 compute nodes. After several hours of deployment, I got > this error 'Timeout

[openstack-dev] [FUEL] Timeout of deployment is exceeded & Fuel does not autodetect my hardware.

Bonjour, Hello. I'm trying to deploy the basic 3 nodes architecture to learn OpenStack: 1 controller and 2 compute nodes. After several hours of deployment, I got this error 'Timeout of deployment is exceeded.'. So I tried to redeploy it but without success. I have installed Fuel 7.0 with lau

Re: [openstack-dev] [Fuel] [RDO] Volunteers needed

Hi, Vladimir, this is a great feature, which can make Fuel truly universal. But i think it is hard to fully commit to the whole thing at once, especially for new contributors. Let's start with splitting it into some observable chunks of work, in a form of wiki page, blueprint or spec. This way it

Re: [openstack-dev] [Fuel] Extra red tape for filing bugs

We also often use bugtracker as a TODO tracker. This template does not work for TODOs at all. I understand that it’s not technically mandatory to follow it, but if that Fuel Bug Checker is going to spam on every single TODO, our inboxes will overflow. > 30 бер. 2016 р. о 17:37 Roman Prykhodchen

[openstack-dev] [Fuel] Extra red tape for filing bugs

Guys, I’m not trying to be a foreteller but with a bug template this huge and complicated people will either not follow it or track bugs somewhere else. Perhaps we should make it simpler? Detailed bug description: Steps to reproduce: Expected results: Actual result: Reproducibility: W

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hi, Do we have any requirements for the new tool? Do we know what we don’t like about current implementation, what should be avoided, etc.? Before that we can only speculate. From my ops experience, shotgun like tools will not work conveniently on medium to big environments. Even on medium env

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Osquery [1] could also be considered as providing a lot of useful informations in a convenient way. [1] https://osquery.io/ On Wed, Mar 30, 2016 at 3:20 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > ​Igor, > > I can not agree more. Wherever possible we should > use existent matur

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

​Igor, I can not agree more. Wherever possible we should use existent mature solutions. Ansible is really convenient and well known solution, let's try to use it. Yet another thing should be taken into account. One of Shotgun features is diagnostic report that could then be attached to bugs to id

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

On 30/03/16 13:35, Igor Kalnitsky wrote: > Neil Jerram wrote: >> But isn't Ansible also over-complicated for just running commands over SSH? > > It may be not so "simple" to ignore that. Ansible has a lot of modules > which might be very helpful. For instance, Shotgun makes a database > dump and th

Re: [openstack-dev] [Fuel] [Openstack] Problem after reboot fuel-master VM

Samer, you could always use `dockerctl check all|` command. On Wed, Mar 30, 2016 at 2:47 PM, Adam Heczko wrote: > Samer my 2c are: > after Fuel node reboot just run 'docker ps -a' to get information if all > containers have been already running. > > On Wed, Mar 30, 2016 at 1:07 PM, Samer Machara

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Neil Jerram wrote: > But isn't Ansible also over-complicated for just running commands over SSH? It may be not so "simple" to ignore that. Ansible has a lot of modules which might be very helpful. For instance, Shotgun makes a database dump and there're Ansible modules with the same functionality

Re: [openstack-dev] [Fuel] [Openstack] Problem after reboot fuel-master VM

Samer my 2c are: after Fuel node reboot just run 'docker ps -a' to get information if all containers have been already running. On Wed, Mar 30, 2016 at 1:07 PM, Samer Machara < samer.mach...@telecom-sudparis.eu> wrote: > Thanks, >Problem solved by magic. It looks like, the nailgun service t

Re: [openstack-dev] [fuel] Component Leads Elections

Dmitry, "No need to rush" does not mean we should postpone team structure changes until Ocata. IMO, CL role (when it is exposed to Fuel) contradicts to our modularization activities. Fuel should be an aggregator of components. What if we decide to use Ironic or Neutron as Fuel components? Should w

Re: [openstack-dev] [Fuel] [Openstack] Problem after reboot fuel-master VM

Thanks, Problem solved by magic. It looks like, the nailgun service take some time to start up in my computer. - Original Message - From: "Samer Machara" To: "OpenStack Development Mailing List" Sent: Wednesday, March 30, 2016 12:39:35 PM Subject: Re: [Fuel] [Openstack] Problem af

Re: [openstack-dev] [Fuel] [Openstack] Problem after reboot fuel-master VM

Hi Vladimir, I'm using fuel 7.0, Which log I need to see? - Original Message - From: " Vladimir Kuklin vkuklin at mirantis.com To: "OpenStack Development Mailing List" Sent: Wed Mar 30 10:06:22 UTC 2016 Subject: [Fuel] [Openstack] Problem after reboot fuel-master VM Hi, Samer It se

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

+1 to discarding shotgun. Should we register a BP for that? > 30 бер. 2016 р. о 12:03 Igor Kalnitsky написав(ла): > > Hey Fuelers, > > I know that you probably wouldn't like to hear that, but in my opinion > Fuel has to stop using Shotgun. It's nothing more but a command runner > over SSH. Besi

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

FWIW, as a naive bystander: On 30/03/16 11:06, Igor Kalnitsky wrote: > Hey Fuelers, > > I know that you probably wouldn't like to hear that, but in my opinion > Fuel has to stop using Shotgun. It's nothing more but a command runner > over SSH. Besides, it has well known issues such as retrieving

Re: [openstack-dev] [Fuel] [Openstack] Problem after reboot fuel-master VM

Hi, Samer It seems that Nailgun has not started. Could you please provide us with the version of Fuel you are using? You can find logs for nailgun in: for <9.0/pre-Mitaka versions /var/log//nailgun/ for current Mitaka: /var/log/nailgun/ On Wed, Mar 30, 2016 at 12:38 PM, Samer Machara < samer.m

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hey Fuelers, I know that you probably wouldn't like to hear that, but in my opinion Fuel has to stop using Shotgun. It's nothing more but a command runner over SSH. Besides, it has well known issues such as retrieving remote directories with broken symlinks inside. So I propose to find a modern a

Re: [openstack-dev] [fuel][plugins][ovs] NSH Query

Hi, Vikram ++ plugin authors explicitly On Wed, Mar 30, 2016 at 12:20 PM, Vikram Choudhary wrote: > Hi Folks, > > We were trying https://github.com/openstack/fuel-plugin-ovs.git, and has > below query: > > *Our Setup:* > SF >

[openstack-dev] [Fuel] [Openstack] Problem after reboot fuel-master VM

Hello, I have rebooted the "fuel-master" VM and after that, I cannot access the Fuel UI. What I am missing. Please check the image to see the error. Another question, How can I rediscover a node that was removed from the pool of available nodes, and also add new nodes to the pool. I clone a fu

[openstack-dev] [fuel][plugins][ovs] NSH Query

Hi Folks, We were trying https://github.com/openstack/fuel-plugin-ovs.git, and has below query: *Our Setup:* SF | Classifier---SFF

Re: [openstack-dev] [fuel] Component Leads Elections

On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote: > > I think this call is too late to change a structure for now. I suggest > > that we always respect the policy we've accepted, and follow it. > > > > If Component Leads role is under a question, then I'd continue the > > discuss

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Please, propose your options here then: https://etherpad.openstack.org/p/shotgun-rename > 29 бер. 2016 р. о 18:15 Jay Pipes написав(ла): > > On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote: >> Should we propose options and then arrange a poll? > > Yup, ++ :) > >>> 29 бер. 2016 р. о 16:40 Ne

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote: Should we propose options and then arrange a poll? Yup, ++ :) 29 бер. 2016 р. о 16:40 Neil Jerram написав(ла): On 29/03/16 15:17, Jay Pipes wrote: Hi! Once Shotgun is pulled out of Fuel, may I suggest renaming it to something different? I

[openstack-dev] [Fuel] Component based testing pipeline

Dear colleagues, I have prepared a document [1] that describes some aspects of possible testing pipeline in a component based development environment. The main idea of the proposed pipeline is to untie two steps: 1) Merge the code to git 2) Adopt changes to Fuel By that I mean Fuel should be an

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Should we propose options and then arrange a poll? > 29 бер. 2016 р. о 16:40 Neil Jerram написав(ла): > > On 29/03/16 15:17, Jay Pipes wrote: >> Hi! >> >> Once Shotgun is pulled out of Fuel, may I suggest renaming it to >> something different? I know in the past that Anita and a few others >> t

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

On 29/03/16 15:17, Jay Pipes wrote: > Hi! > > Once Shotgun is pulled out of Fuel, may I suggest renaming it to > something different? I know in the past that Anita and a few others > thought the name was not something we should really be encouraging in > the OpenStack ecosystem. > > Just something

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hi! Once Shotgun is pulled out of Fuel, may I suggest renaming it to something different? I know in the past that Anita and a few others thought the name was not something we should really be encouraging in the OpenStack ecosystem. Just something to consider since it's being decoupled anyway

[openstack-dev] [Fuel] [RDO] Volunteers needed

Dear all, Fuel currently supports deployment of OpenStack using DEB packages (particularly Ubuntu, and Debian in near future). But we also used to deploy OpenStack on CentOS, but at some point we switched our focus on Ubuntu. It is not so hard to implement deployment of RDO using Fuel. Volunteers

Re: [openstack-dev] [fuel] Component Leads Elections

Mike, Inline comments. Vladimir, > I think this call is too late to change a structure for now. I suggest > that we always respect the policy we've accepted, and follow it. > > If Component Leads role is under a question, then I'd continue the > discussion, hear opinion of current component leads

Re: [openstack-dev] [Fuel] FFE request for ConfigDB service

Oleg and team, Thanks very much for your efforts to make this happened. I'm sure this experience will help us to implement thorough "Day 2" maintenance flow in future Fuel releases. Vladimir Kozhukalov On Tue, Mar 29, 2016 at 12:06 PM, Oleg Gelbukh wrote: > Greetings, > > Please, be informed

[openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Dear colleagues, This is a part of our plan to make Fuel even more modular. Governance patch: https://review.openstack.org/#/c/298603/ Project-config patch: https://review.openstack.org/#/c/298615/ Launchpad project: https://launchpad.net/shotgun Wiki page: https://wiki.openstack.org/wiki/Shotgun

Re: [openstack-dev] [Fuel] FFE request for ConfigDB service

Greetings, Please, be informed that the source code of Nailgun API extension has landed to the designated repository [1]. Project was code named 'tuning-box'. We are working to integrate it into the build and testing systems provided by Fuel infra. I suggest that the FFE can be closed. I'd like t

Re: [openstack-dev] [fuel] Component Leads Elections

Vladimir, I think this call is too late to change a structure for now. I suggest that we always respect the policy we've accepted, and follow it. If Component Leads role is under a question, then I'd continue the discussion, hear opinion of current component leads, and give this a time to be discu

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

​Guys, you are awesome. Thank you all very much.​ Vladimir Kozhukalov On Mon, Mar 28, 2016 at 11:50 PM, Alexey Shtokolov wrote: > Fuelers! > > I'm glad to announce that all patches [0] were merged! > > Many thanks to all of you who help us to make Fuel more flexible and > unlimited. > > Special

[openstack-dev] [Fuel] [FFE] Unlock Settings Tab

Fuelers! I'm glad to announce that all patches [0] were merged! Many thanks to all of you who help us to make Fuel more flexible and unlimited. Special thanks to our code and design reviewers: Igor Kalnitsky, Sergii Golovatiuk, Vitaly Kramskikh. And especially to the Team: Bulat Gaifullin, Ilya

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

Granted. New deadline is 21:00 UTC 03/28/2016. Vladimir Kozhukalov On Fri, Mar 25, 2016 at 8:17 PM, Alexey Shtokolov wrote: > Fuelers! > > > We are very close to landing our feature "Unlock Settings Tab". But we > still have a set of reviews [0] to be merged due to several reasons (incl. > the

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

Anastasia, we are going to invest one more day in investigation of high priority bug, we cannot reproduce it at the moment. I don't think that we should fix medium bugs in feature that soon will be deprecated. On Fri, Mar 25, 2016 at 3:54 PM, Anastasia Urlapova wrote: > Dima, > if we want to de

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

Fuelers! We are very close to landing our feature "Unlock Settings Tab". But we still have a set of reviews [0] to be merged due to several reasons (incl. the migration to python27-db gates on OpenStack Infra). I would like to request extra time till Monday to land them. [0] - https://goo.gl/kS

Re: [openstack-dev] [fuel] Component Leads Elections

Dear all, Let me raise my hand here. We introduced this role CL a while ago for two major reasons: 1) improve review process (CL are responsible for review SLA) 2) introduce review of overall architecture and avoid cross-feature, cross-component conflicts. These two points, in fact, mean the fol

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

On Fri, 2016-03-25 at 08:00 -0600, Alex Schultz wrote: > > On Fri, Mar 25, 2016 at 7:32 AM, Dmitry Guryanov com> wrote: > > Here is the bug which I'm trying to fix - https://bugs.launchpad.ne > > t/fuel/+bug/1538587. > > > > In  VMs (set up with fuel-virtualbox) kernel panic occurs every > > tim

[openstack-dev] [Fuel][Library][Packaging] Build fuel-library as deb package

Hello Fuelers, Currently we install fuel-library package on the master node and then copy Puppet modules to environment nodes using rsync. The main disadvantage here is the additional logic required to establish matching between different releases and corresponding Puppet stuff. The solution we p

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

On Fri, Mar 25, 2016 at 7:32 AM, Dmitry Guryanov wrote: > Here is the bug which I'm trying to fix - > https://bugs.launchpad.net/fuel/+bug/1538587. > > In VMs (set up with fuel-virtualbox) kernel panic occurs every time you > delete node, stack trace shows error in ext4 driver [1]. > The same as

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

Here is the bug which I'm trying to fix - https://bugs.launchpad.net/fuel/+bug/1538587. In VMs (set up with fuel-virtualbox) kernel panic occurs every time you delete node, stack trace shows error in ext4 driver [1]. The same as in the bug. Here is a patch - https://review.openstack.org/297669 .

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

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 wrote: > As we are going to deprecate logs on UI I'm going to mark following bugs > as "won't fix". Any objections? > High prio

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

+1 > 25 бер. 2016 р. о 13:31 Dmitry Pyzhov написав(ла): > > 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 p

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

I've read carefully the article about bios_grub partition you've given link to. And it turned out for me that it's only used for non-UEFI boot. It this case it's impossible to boot without stage1 (in mbr), because our PXE doesn't touch hard disks. So clearing BIOS_boot partition will not introduce

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 a

Re: [openstack-dev] [Fuel] Where the FU(EL) did my puppet files go?

On 03/25/2016 12:08 AM, Andrew Woodward wrote: > With the merging of last bits of changes of fuel-openstack-tasks[1], > fuel-remove-conflict-openstack, and > fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3] a lot of > the files structure relating to tasks has changed in fuel-library.

[openstack-dev] [Fuel] Where the FU(EL) did my puppet files go?

With the merging of last bits of changes of fuel-openstack-tasks[1], fuel-remove-conflict-openstack, and fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3] a lot of the files structure relating to tasks has changed in fuel-library. [1] https://blueprints.launchpad.net/fuel/+spec/fuel-

Re: [openstack-dev] [fuel] Component Leads Elections

Serg, Thanks for agreeing to officiate this cycle's component lead elections for us! -- Dmitry Borodaenko On Thu, Mar 24, 2016 at 12:55:57PM -0700, Serg Melikyan wrote: > Hi folks, > > I'd like to announce that we're running the Component Leads elections. > Detailed information is available o

[openstack-dev] [fuel] Component Leads Elections

Hi folks, I'd like to announce that we're running the Component Leads elections. Detailed information is available on wiki [0]. Component Lead: defines architecture of a particular module or component in Fuel, resolves technical disputes in their area of responsibility. All design specs that impa

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

On Wed, Mar 23, 2016 at 7:49 PM, Dmitry Guryanov wrote: > > I have no objections against clearing bios boot partition, but could > you describe scenario, how non-efi system will boot with valid > BIOS_grub and wiped boot code in MBR > I thoroughly agree that it's impossible to boot without stag

Re: [openstack-dev] [Fuel][Nailgun] Random failures in unit tests

I finally got it passing all the tests, including performance: https://review.openstack.org/#/c/294976/. I'd appreciate if you guys can review/land it sooner than later: patch touches many tests, and it would be beneficial for everyone to be based on updated code. Thanks, On Mon, Mar 21, 2016 at

Re: [openstack-dev] [Fuel][Upgrade][FFE] Reassigning Nodes without Re-Installation

Hi guys, According to the last discussion on the Fuel Team Meeting [1] the second chance was provided to this feature because it is directly related to the cluster_upgrade extension and has a minimal impact on the core part. A separate bug report [2] was created to track a progress of this feature

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

On Wed, 2016-03-23 at 18:22 +0300, Alexander Gordeev wrote: > Hello Dmitry, > > . >   > Yep, astute needs to be fixed as the way how it wipes the disks is > way too fragile, dangerous and not always reliable due to what you > mentioned above. > > Nope, I think that zeroing of 446 bytes is not

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

Hello Dmitry, First of all, thanks for recovering the thread. Please read my comments inline. On Tue, Mar 22, 2016 at 1:07 PM, Dmitry Guryanov wrote: > > The first problem could be solved with zeroing first 512 bytes of each > disk (not partition). Even 446 to be precise, because last 66 bytes

[openstack-dev] [Fuel] API changes for Nailgun cluster upgrade extension

Hi, fuelers! In accordance to policy of API changing in Fuel components established in this mail thread [1] the purpose of this notice is to inform everyone concerned about such modifications pertaining to Nailgun cluster upgrade extension that is going to be landed into upstream. New handler of

Re: [openstack-dev] [fuel][puppet] Switching fuel-library to consume stable/mitaka

Hi, > Additionally we will want to ensure that the fuel-ci will work for the > upstream stable/mitaka branches as it currently[0] isn't working since we > haven't cut a stable/mitaka branch for Fuel yet. Igor Belikov has been > notified of the current issues and is looking into a fix. I roll

[openstack-dev] [fuel][puppet] Switching fuel-library to consume stable/mitaka

Hey everyone, Emilien is in the process of cutting the stable/mitaka branches for all of the upstream puppet modules. As Fuel approaches SCF, we will want to switch from the master branches we are currently tracking to leverage the stable/mitaka branches. In talking with some other folks, I beli

Re: [openstack-dev] [Fuel] Packaging CI for Fuel

On 2016-03-22 15:20:22 + (+), Tristan Cacqueray wrote: [...] > With only my VMT hat on, this makes me wonder why the packaging needs > special care. Is there a reason why stable branch aren't built continuously? [...] My concern was more over handling packaging-specific security vulnerabil

Re: [openstack-dev] [Fuel] Packaging CI for Fuel

On 03/19/2016 06:53 PM, Jeremy Stanley wrote: > On 2016-03-19 05:10:18 -0500 (-0500), Monty Taylor wrote: > [...] >> It would also be good to tie off with the security team about >> this. One of the reasons we stopped publishing debs years ago is >> that it made us a de-facto derivative distro. Peo

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

For GPT disks and non-UEFI boot this method will work, since MBR will still contain first stage of a bootloader code. For UEFI boot things are little more complicated, we have to find EFI system partition, mount it and remove/edit some files. On Tue, Mar 22, 2016 at 4:26 PM, Bulat Gaifullin wrote

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

What about GPT[1] disks? As I know we have plans to support UEFI boot and GPT disks. [1] https://en.wikipedia.org/wiki/GUID_Partition_Table Regards, Bulat Gaifullin Mirantis Inc. > On 22 Mar 2016, at 13:46, Dmitry Guryanov wrote: > > On Tue, 2016-03-22 at 13:07 +0300, Dmitry Guryanov wrote

Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

On 03/22/2016 09:25 AM, Matthew Mosesohn wrote: > Andrew, > > The stubs + deprecation warning is exactly the approach I believewe > should take for renaming/moving tasks. LGTM to me as far as it keeps plugins intact. So let's please update the patch [0] or submit required patches to unblock it.

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

On Tue, 2016-03-22 at 13:07 +0300, Dmitry Guryanov wrote: > Hello, > > .. > > [0] https://github.com/openstack/fuel-astute/blob/master/mcagents/era > se_node.rb#L162-L174 > [1] https://github.com/openstack/fuel- > agent/blob/master/fuel_agent/manager.py#L194-L221 Sorry, here is a correct li

[openstack-dev] [Fuel] Wiping node's disks on delete

Hello, Here is a start of the discussion - http://lists.openstack.org/pipermail/openstack-dev/2015-December/083021.html . I've subscribed to this mailing list later, so can reply there. Currently we clear node's disks in two places. The first one is before reboot into bootstrap image [0] and the

Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

Andrew, The stubs + deprecation warning is exactly the approach I believewe should take for renaming/moving tasks. If it was possible for a plugin to override a task, but preserve the fields from the original task, we could avoid such scenarios. What I mean is that if the following task: - id: w

Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

I've mocked up the change to implementation using the already landed changes to ceph as an example https://review.openstack.org/295571 On Mon, Mar 21, 2016 at 3:44 PM Andrew Woodward wrote: > We had originally planned for the FFEs for both fuel-openstack-tasks[1] > and fuel-remove-conflict-open

[openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

We had originally planned for the FFEs for both fuel-openstack-tasks[1] and fuel-remove-conflict-openstack to [2] to close on 3/20, This would have placed them before changes that conflict with fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. [1] http://lists.openstack.org/pipermai

<    1   2   3   4   5   6   7   8   9   10   >