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

Hi, Hmm.. I think ~15 minutes isn't long enough to skip this approach in production. What about using lrzip only for end-users, but keep regular tarball for CI and internal usage? Thanks, Igor On Thu, Aug 21, 2014 at 5:22 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote: I see no other quick

Re: [openstack-dev] [Fuel] Node renaming in Fuel

Hi Dmitry, It's not as easy as you think. The node's name may be reseted during some of our actions. For example, if you remove node from a cluster a node's name will be reseted. So the idea of the blueprint [1] is to provide mechanism when you once set names and they will not be reseted. [1]:

Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF

in LP all open bugs regarding Zabbix feature? On Thu, Sep 11, 2014 at 12:11 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: I think we should not count bugs for HCF criteria if they affect only experimental feature(s). +1, I'm totally agree with you - it makes no sense to count experimental

[openstack-dev] [Fuel] Symlinks to new stuff for OpenStack Patching

Hello fuelers, I'm working on openstack patching for 5.1 and I've met some problems. The problems I've met are in repos/puppets installing process. The problems are almost same, so I describe it on repos example. The repos data are located in /var/www/nailgun. This folder is mounted as /repo

Re: [openstack-dev] [Fuel] Symlinks to new stuff for OpenStack Patching

on). I hope this helps. -Matthew On Sun, Jun 15, 2014 at 2:32 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hello fuelers, I'm working on openstack patching for 5.1 and I've met some problems. The problems I've met are in repos/puppets installing process. The problems are almost same

Re: [openstack-dev] [Fuel] Support for plugins in fuel client

Hi guys, Actually, I'm not a fun of cliff, but I think it's a good solution to use it in our fuel client. Here some pros: * pluggable design: we can encapsulate entire command logic in separate plugin file * builtin output formatters: we no need to implement various formatters to represent

Re: [openstack-dev] [Fuel] Removing old node logs

Hi guys, What about our diagnostic snapshot? I mean we're going to make snapshot of entire /var/log and obviously this old logs will be included in snapshot. Should we skip theem or such situation is ok? - Igor On Tue, Jun 24, 2014 at 5:57 PM, Aleksandr Didenko adide...@mirantis.com wrote:

Re: [openstack-dev] [Fuel] Removing old node logs

PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi guys, What about our diagnostic snapshot? I mean we're going to make snapshot of entire /var/log and obviously this old logs will be included in snapshot. Should we skip theem or such situation is ok? - Igor On Tue, Jun 24, 2014

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

Hi fuelers, I'm working on Patching for OpenStack and I have the following questions: 1/ We need to save new puppets and repos under some versioned folder: /etc/puppet/{version}/ or /var/www/nailgun/{version}/centos. So the question is which version to use? Fuel or OpenStack? 2/ Which

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

on (2014.1.1), and version of Fuel it's included in (5.0.1), e.g. 2014.1.1-5.0.1. Between Fuel versions, we can have additional bugfix patches added to shipped OpenStack components. my 2c, -DmitryB On Tue, Jul 1, 2014 at 9:50 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi fuelers

Re: [openstack-dev] [fuel] oddness with sqlalchemy db().refresh(object)

Hi guys, *@Roman*, we have db().refresh(task_provision) since the line above (self._call_silently) may change task status directly in db, not in SQLAlchemy session. *@Andrew*, it's really strange. I just checkout your request, return refreshing task and run tests. As a result, I have no

Re: [openstack-dev] [fuel] oddness with sqlalchemy db().refresh(object)

the patch set (5) with db().refresh(task_provision) enabled. On Sun, Apr 13, 2014 at 3:28 AM, Igor Kalnitsky ikalnit...@mirantis.comwrote: Hi guys, *@Roman*, we have db().refresh(task_provision) since the line above (self._call_silently) may change task status directly in db

Re: [openstack-dev] [oslo] Logging exceptions and Python 3

Hi, Is there a reason to log the exception as Unicode on Python 2? Sure, why not? Some exceptions may have unicode message with non-ASCII characters. and we obviously can't cast such exceptions with str() in Python 2.x. The problem is that I don't know what is the best syntax to log

Re: [openstack-dev] [oslo] Logging exceptions and Python 3

. For example u can do. LOG.warn(Something broke at this point, exc_info=True) From: Igor Kalnitsky ikalnit...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 2:20 PM To: OpenStack Development

Re: [openstack-dev] [oslo] Logging exceptions and Python 3

can use attributes for getting exception message. In that case, I propose not to do an explicit conversion, and leave this task for logging module. - Igor On Sun, May 18, 2014 at 2:03 AM, Johannes Erdfelt johan...@erdfelt.comwrote: On Fri, May 16, 2014, Igor Kalnitsky ikalnit

Re: [openstack-dev] [oslo] Logging exceptions and Python 3

So, write: LOG.debug(u'Could not do whatever you asked: %s', exc) or just: LOG.debug(exc) Actually, that's a bad idea to pass an exception instance to some log function: LOG.debug(exc). Let me show you why. Here a snippet from logging.py: def getMessage(self): if not

Re: [openstack-dev] [oslo][db] oslo.db repository review request

Hi guys, +1 to Roman's suggestion. I think we have to use 0.MINOR.PATCH at least during a few cycles. API changes aren't a problem if we use a specific (frozen) version in requirements. Thanks, Igor On Fri, May 30, 2014 at 6:37 PM, Roman Podoliaka rpodoly...@mirantis.com wrote: Hi Sergey,

Re: [openstack-dev] [Fuel] [Rally] Using fuelclient as a library - battle report

Hi Lukasz, I have the same thoughts - we have to design a good Python library for dealing with Nailgun and this library has to be used by: * Fuel CLI * System Tests * Fuel Upgrade * OSTF * other scripts But it's a big deal and we definetely should have a separate blueprint for this task.

[openstack-dev] [Fuel] Let's remove fuelweb from repo paths

Hi fuelers, I'm going to propose you remove fuelweb word from repos' paths. What am I talking about? Let me show you. Currently we have the following paths to repos: /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/ /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/ Obviously, the

Re: [openstack-dev] [Fuel] Let's remove fuelweb from repo paths

it carefully (for instance, building custom ISO with changes and making sure it passes BVTs), then let's do it. On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi fuelers, I'm going to propose you remove fuelweb word from repos' paths. What am I talking about

Re: [openstack-dev] [Fuel] Let's remove fuelweb from repo paths

Folks, BVT tests are passed successfully. What about merging? Thanks, Igor On Fri, Oct 10, 2014 at 12:40 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: As I mentioned early, I already have an ISO with patches and it works fine in my own deployment. However, I ran the BVT tests on centos

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

+1. On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of increasing amount of core reviewers. I would like to propose Bogdan Dobrelia(bogdando) and Sergii

Re: [openstack-dev] [Fuel] Let's remove fuelweb from repo paths

, Igor On Fri, Oct 10, 2014 at 2:55 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Folks, BVT tests are passed successfully. What about merging? Thanks, Igor On Fri, Oct 10, 2014 at 12:40 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: As I mentioned early, I already have an ISO

[openstack-dev] [Fuel] Failed upgrade chain - 5.1 - 5.1.1 - 6.0

Hi folks, Yesterday I performed the following upgrade chain: 5.1 - 5.1.1 - 6.0 and upgrading to 6.0 was failed. I did some research and figure out that Nailgun's container doesn't have Nailgun at all. So here's what happened. 1. When we're upgrading to 6.0 we already have three repos in

Re: [openstack-dev] [Fuel] Failed upgrade chain - 5.1 - 5.1.1 - 6.0

and post upgrade logs? I'm interested to see which pieces cause the failure and this is some area I didn't plan for in container upgrades. Best Regards, Matthew Mosesohn On Fri, Nov 14, 2014 at 3:43 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi folks, Yesterday I performed

Re: [openstack-dev] [Fuel] Separate code freeze for repos

Guys, The idea of separate unfreezing is cool itself, but we have to define some rules how to define that fuel-web is stable. I mean, in fuel-web we have different projects, so when Fuel UI is stable, the fuel_upgrade or Nailgun may be not. - Igor On Fri, Nov 14, 2014 at 3:52 PM, Vitaly

Re: [openstack-dev] [Fuel] Failed upgrade chain - 5.1 - 5.1.1 - 6.0

some problems - let us know. - Igor On Fri, Nov 14, 2014 at 2:38 PM, Daniele Pizzolli daniele.pizzo...@create-net.org wrote: Igor Kalnitsky ikalnit...@mirantis.com writes: Mat, I've filed a bug [1] and provide you a puppet output inside Nailgun container [2]. If I remove /etc/yum.repos.d

Re: [openstack-dev] [Fuel] fuel master monitoring

+1 for Dima's suggestion. We need to stop reinventing the wheel. There are a lot tools around us, so let's pick one of them and will use it. On Thu, Nov 20, 2014 at 10:13 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Guys, maybe we can use existing software, for example Sensu [1]? Maybe i am

Re: [openstack-dev] [Fuel] fuel master monitoring

I heard about Monit a lot of good reviews, but unfortunately it looks like Monit doesn't support plugins and doesn't provide API. It may be a stumbling block if one day we decide to go deeper in monitoring task. On Fri, Nov 21, 2014 at 11:01 AM, Matthew Mosesohn mmoses...@mirantis.com wrote: I'm

Re: [openstack-dev] [Fuel] fuel master monitoring

Folks, Maybe I understand some things wrong, but Zabbix is a different story. We deploy Zabbix per cluster, so it doesn't monitor for *all* slaves or master node. It monitors only one cluster. Therefore I see no reasons to choose Zabbix over monit. I mean, it shouldn't be We MUST use Zabbix

Re: [openstack-dev] [Fuel][Nailgun] Web framework

Hi, Sebastian, Thank you for raising this topic again. Yes, indeed, we need to move out from web.py as soon as possible and there are a lot of reasons why we should do it. But this topic is not about Why, this topic is about Flask or Pecan. Well, currently Fuel uses both of this frameworks: *

Re: [openstack-dev] [Fuel][Nailgun] Web framework

AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting

Re: [openstack-dev] [Fuel][Nailgun] Web framework

Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or

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

+1 to stop parsing logs on UI and show them as is. I think it's more than enough for all users. On Fri, Dec 12, 2014 at 8:35 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote: We have a high priority bug in 6.0: https://bugs.launchpad.net/fuel/+bug/1401852. Here is the story. Our openstack

Re: [openstack-dev] [Fuel] Core rights in Fuel repositories

+1, no objections from my side. On Fri, Jan 23, 2015 at 6:04 PM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks! After moving python-fuelclient to its own repo some of you started asking a good question which is How do we manage core rights in different Fuel repositories. The problem

Re: [openstack-dev] [Fuel] Getting rid of kickstart/preseed for all NEW releases

Just want to be sure I understand you correctly: do you propose to FORBID kickstart/preseed installation way in upcoming release at all? On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Subject is changed. Vladimir Kozhukalov On Mon, Jan 26, 2015 at 4:55

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

+1 for removing attribute. @Evgeniy, I'm not sure that this attribute really shows all changes that's going to be done. On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L e...@mirantis.com wrote: To be more specific, +1 for removing this information from UI, not from backend. On Mon, Jan 26, 2015 at

Re: [openstack-dev] [Fuel] Getting rid of kickstart/preseed for all NEW releases

. It is to be possible to install OS using kickstart for all currently available OpenStack releases. Vladimir Kozhukalov On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Just want to be sure I understand you correctly: do you propose to FORBID kickstart/preseed

Re: [openstack-dev] [Fuel]When will fuel support centos 7?

Hi, Yes, we do have a plan for CentOS 7, but as far as I know it was postponed to MOS 7.0. That means we will not have Cent OS 7 in upcoming release. - Igor On Thu, Jan 15, 2015 at 1:16 PM, me,apporc appleorchard2...@gmail.com wrote: Hi, Do we have plan for centos 7 ? Regards, apporc

Re: [openstack-dev] [Fuel][Plugins] Fuel plugin builder tagging and pypi publishing

+1. On Fri, Feb 13, 2015 at 11:41 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for the whole idea, I really waited for it until first release of fuel-plugin-builder. Without tags it's hard to say which commit is included in PyPI release. Also automation of release process is a

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

changed (or even otherwise, what was not touched - and so might bring a surprise later). We might want to think about it after wizard-like UI is implemented. On Mon, Jan 26, 2015 at 8:26 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1 for removing attribute. @Evgeniy, I'm not sure

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

nmar...@mirantis.com wrote: Igor, But why can't we implement it properly on the first try? It doesn't seem like a hard task and won't take much time. On Wed, Jan 28, 2015 at 12:50 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Nik, I'm now here and I don't agree that we need to remove

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

Hi, Roman, Indeed, we have to go forward and drop python 2.6 support. That's how it supposed to be, but, unfortunately, it may not be as easy as it seems at first glance. Fuel Master is flying on top of Cent OS 6.5 which doesn't have python 2.7 at all. So we must either run master node on Cent

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

Guys, The question not about Do we want to drop 2.6 or not?. The question about Do we have resources to do that in this release cycle?. It may be not as easy at it seems and it obviously requires additional testing. - Igor On Wed, Jan 14, 2015 at 11:18 AM, Przemyslaw Kaminski

Re: [openstack-dev] [fuel][client] new client implementation ideas

Hi, Konstantin, Thank you for sharing ideas. Your yet-one-more implementation of fuel-client one more time confirms that currently we have completely unusable implementation. Just for your information: we have plans for python-fuelclient refactoring [1]. The main point of this blueprint is to

Re: [openstack-dev] [Fuel] Merge code before spec is merged?

Fuelers, I see no problems here. I think it's ok if some parts of feature were merged before the spec, because it means the feature is under development. Moreover, if we merge specs asap there's a chance that we'll miss something. Therefore, the chance that it will be found and discussed at the

Re: [openstack-dev] [Fuel] FFE python-fuelclient improvements

Yep, I think we can do merge them. +1 from my side. On Tue, Mar 17, 2015 at 12:50 PM, Evgeniy L e...@mirantis.com wrote: +1, because those patches are simple don't look destructive. On Mon, Mar 16, 2015 at 7:43 PM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks, due to some technical

Re: [openstack-dev] [Fuel] Testing DB migrations

Hi, guys, Indeed, it's a hot topic since it looks like there's no silver bullet at all. As OpenStack community, we should move toward oslo.db approach, but it may require hard effort from our side. Meantime, as a part of bp/consume-external-ubuntu [1] I've prepared a base class for testing

Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

+1. She's doing great job! On Thu, Mar 26, 2015 at 6:09 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: +1 Best Regards, Sergii Golovatiuk On 25 Mar 2015, at 12:10, Dmitry Borodaenko dborodae...@mirantis.com wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the

Re: [openstack-dev] [Fuel] Nominate Andrey Skedzinskiy for fuel-qa(devops) core

+1. On Mon, Apr 13, 2015 at 4:09 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Strong +1 Nastya forgot to mention Andey's participation in Ubuntu 14.04 feature. With Andrey's help the feature went smooth and easy ;) -- Best regards, Sergii Golovatiuk, Skype #golserge IRC

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

Dmitry, 1/ +1 2/ +1 3/ +1 P.S: Dmitry, please send one mail per nomination next time. It's much easier to vote for each candidate in separate threads. =) Thanks, Igor On Mon, Apr 13, 2015 at 4:24 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote: Hi, 1) I want to nominate Vladimir Sharshov to

Re: [openstack-dev] [Fuel] Infiniband support in Fuel

Hello, If all is ok, let's move bug to 7.0 and fix it with netaddr as it was proposed in comments to the ticket. - Igor On Wed, Apr 29, 2015 at 6:29 PM, Nikolay Markov nmar...@mirantis.com wrote: Hi everybody, does anybody besides Mellanox need this? If not and while it's already solved

Re: [openstack-dev] [Fuel] Transaction scheme

First of all I propose to wrap HTTP handlers by begin/commit/rollback I don't know what you are talking about, but we do wrap handlers in transaction for a long time. Here's the code

Re: [openstack-dev] [Fuel] Transaction scheme

. On Wed, May 6, 2015 at 12:57 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: First of all I propose to wrap HTTP handlers by begin/commit/rollback I don't know what you are talking about, but we do wrap handlers in transaction for a long time. Here's the code https://github.com

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

+1. Julia's doing good job. On Thu, Apr 30, 2015 at 12:33 PM, Przemyslaw Kaminski pkamin...@mirantis.com wrote: +1, indeed Julia's reviews are very thorough. P. On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote: Hi, I'd like to nominate Julia Aranovich

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

Tomasz, multi-node mode is a legacy non-HA mode with only 1 controller. Currently, our so-called HA mode support deployment with 1 controller, so it makes no sense to support both modes. On Wed, Apr 15, 2015 at 6:38 PM, Tomasz Napierala tnapier...@mirantis.com wrote: Do you mean single node?

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

dpyz...@mirantis.com wrote: +1 On Mon, Apr 13, 2015 at 2:07 PM, Evgeniy L e...@mirantis.com wrote: +1 On Fri, Apr 10, 2015 at 1:35 PM, Roman Prykhodchenko m...@romcheg.me wrote: +1. Sebastian does great job in reviews! 10 квіт. 2015 о 12:05 Igor Kalnitsky ikalnit...@mirantis.com

Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role - the spec is available

Hi Samuel, Here's my 2 cents on this topic. First of all, I'd like to ask you - what problem do you try to solve? Please, answer on that first because it'll help me to come back with solution. Currently it looks like an error-prone approach to apply nova-nfs tasks only on roles with some label.

Re: [openstack-dev] [Fuel] Packaged Fuel and Feature Groups

Hi, There are few places where 'feature_groups' is used by Nailgun to turn on/off some experimental stuff. For instance, if there's an 'experimental' word in the 'feature_groups' list then Nailgun will allow you to create new environments based on old releases. Thanks, Igor On Thu, Jun 18, 2015

Re: [openstack-dev] [Fuel] Ceph Public Network Setting

Hello, That makes sense to me. Still, I want to point that we're going to implement advanced networking and with this feature you'll be able to assign every single network role to any network. That means, you'll be able to assign ceph network role to storage, management or whatever-you-want

Re: [openstack-dev] [Fuel][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core

+1. Alex's doing a great job! On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko svasile...@mirantis.com wrote: +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [Fuel][Plugins] Feedback

Hi Sheena, Sure, I can do it. Should I push tag only for last release or for all releases that are available on PyPI? Thanks, Igor On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson sgreg...@mirantis.com wrote: So the only cores are Igor and Evgeniy? Can one of you add tags for the new release

Re: [openstack-dev] [Fuel][CI] CI on commit message

Guys, How do you suppose to know that only commit message was changed? Do you want to implement manual comparison between patch sets?! Currently Gerrit checks whether patchset was changed or not by tracking Git commit SHA1 sum, and, btw, chaning commit message will lead to changing commit sha1

Re: [openstack-dev] [Fuel][Plugins] Feedback

want tags for any releases that have plugins associated, or we are planning to have plugins associated (so, 6.0, 6.1, 7.0). -Original Message- From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] Sent: Thursday, July 30, 2015 9:46 AM To: OpenStack Development Mailing List

Re: [openstack-dev] [Fuel][Plugins] Feedback

...@mirantis.com wrote: Ah, my mistake - yes, please push tags for all of the plugin builder versions. -Original Message- From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] Sent: Thursday, July 30, 2015 10:47 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev

Re: [openstack-dev] [Fuel] Fuel Project Specifications

Hi Alex, Finally we have it! Thank you. BTW, any chance to use upstream infra [1] for this purpose? [1] http://specs.openstack.org Thanks, Igor On Mon, Aug 10, 2015 at 6:11 PM, Alexander Charykov achary...@mirantis.com wrote: Hello all. We have launched fuel specs service at [1] where you

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

Hello, Here's my 2 cents on it. I think the effort we put to support fuelmenu doesn't worth it. I used to deploy fuel too often in previous release, and I never used features of fuelmenu? Why? Because I prefer to apply changes on already deployed node. Moreover, I don't like that users are

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: Hi, Since the feature

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

Hello, My 2 cents on it. Following plan C requires a huge effort from developer, and it may be unacceptable when FF is close and there're a lot of work to do. So it looks like the plan B is most convenient for us and eventually we will have all features in fuel2. Alternatively we can go with

Re: [openstack-dev] [fuel] FFE for bug/1475759 ceph generators

Hi folks, Andrew, the code looks safe to me and the only question I have what the point of this patch if it's unused? I mean the generators? Until you use them in cluster attributes (openstack.yaml) new generators are useless, and don't fix anything. Are you going to use them in 7.0 to fix some

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

to our attempts to develop good api. Thanks, On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https

[openstack-dev] [Fuel] [Plugins] Node role as a plugin is in master

Hi fuelers, I'm glad to announce that bp/role-as-a-plugin story [1] has been successfully implemented. Since yesterday all functional is in master, feel free to use it in your plugins. Briefly, now you are able.. * to define new node roles in the similar to openstack.yaml way with all supported

Re: [openstack-dev] [Fuel] Question about unique default hostname for node

Hi guys, @Sergii, it looks like you misunderstood something. `node-uuid` is not a general use case. It's only about conflicting nodes, and I'm sure everyone's going to change such a hostname in order to avoid confusion. @Andrew, a) Database refuses hostnames that break unique constraint, sot

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

+1. On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote: At the moment we have several core reviewers for the fuel-main project. Roman Vyalov is responsible for merging of infrastructure-related variables and for the lists of packages. I am responsible for merges in

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hello guys, Update 'make iso' scripts: * Make them use 'r10k' (or other tool) to download upstream modules based on 'Puppetfile' I foreseen holywars with our Build team. AFAIK they are deeply concerned about Internet access during ISO build process. Hence, they'll propose to package

Re: [openstack-dev] [Fuel] Aligning LP groups with real teams

Hello, Here's my +2 on this. :) BTW, any chance we can somehow to reduce spam emails when some bug was assigned to another team? For instance, I see email notifications when bug's assigned to fuel-library. Thanks, Igor On Fri, Jul 17, 2015 at 4:16 PM, Tatyana Leontovich

Re: [openstack-dev] [Fuel] Nailgun agent core reviewers nomination

+1 On Fri, Jul 17, 2015 at 5:43 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: +1 On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: +1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 10:20 AM, Vladimir

Re: [openstack-dev] [Fuel][Plugins] Plugins on separate launchpad projects

Hello Patrick, Thank you for raising this topic. I think that it'd be nice to create a separate projects for Fuel plugins if it wasn't done yet. Fuel plugins have different release cycles and do not share core group. So it makes pretty much sense to me to create separate projects. Otherwise, I

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

holywars as we are going to add our tests to Puppet manifests projects. We'll be able to resolve fast enough. In case of problems we can stick librarian to particular commit in upstream repo. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Fri, Jul 17, 2015 at 8:19 AM, Igor

Re: [openstack-dev] [Fuel] Question about unique default hostname for node

Hi Fedor, Use 'node-{ID}-{#}' format, where {#} we'll chose in loop till the first unique. I don't like this approach by many reasons. Here's some of them: * With a loop you're going to perform N SQL queries in order to check for uniqueness, and that's a bad design and it'd be better to

Re: [openstack-dev] [Fuel] Changing APIs and API versioning

Roman, Vitaly, You're both saying right things, and you guys bring a sore topic up again. The thing is that Nailgun's API isn't the best one.. but we're trying to improve it step-by-step, from release to release. We have so many things to reconsider and to fix that it'd require a huge effort to

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

Hi all, > Just a small note, we shouldn't remove it completely from Nailgun > codebase, because we still have old environments to support, How many releases we should wait before nova-network completely? AFAIK, it was deprecated since 6.1.. and it was kept in 7.0 only for VCenter case. If so,

Re: [openstack-dev] [Fuel] Modularization activity POC

to put new services into separate repos? >>> How do you plan to package those - will you create RPM package for each, >>> as well as Docker container (as we have everything in containers on Fuel >>> master node) >>> >>> These questions, of course, shou

Re: [openstack-dev] [Fuel] Assigning VIPs on network config serialization

Then we should close [1] as invalid, shoudn’t we? >> >> > 20 жовт. 2015 р. о 15:55 Igor Kalnitsky <ikalnit...@mirantis.com> >> > написав(ла): >> > >> > Roman, >> > >> >> This behavior is actually described in [1]. Shou

Re: [openstack-dev] [Fuel] Deprecation of GRE network segmentation in Fuel 8.0

Hey Artem, > GRE network segmentation option has been deprecated for clusters > with Neutron since 7.0 release, both on UI and Library side What do you mean by "deprecated"? Was it removed? If so, why did we have a chance to create GRE if it wasn't supported? If so, we definitely have to forbid

Re: [openstack-dev] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

Hey Julia, Thank you for feedback. I took a look over the bug and here's my thoughts: * [1] Looks like Invalid to me. I'm not sure, but it looks like you VMs just wrongly configures. It's a pretty common mistake for VBox scripts. Did you use them? * [2] Partially Invalid. I left my comments, so

Re: [openstack-dev] [Fuel] Default PostgreSQL server encoding is 'ascii'

Hello, Yeah, that's true. There shouldn't be any VBox specific hacks, and I believe PostgreSQL uses locale's encoding by default (which is ASCII in containers). Well, basically the bug should be assigned on library team - we should specify UTF-8 explicitly in PostgreSQL config, since Nailgun

Re: [openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

Folks, I have one thing to add: if workaround is unavoidable, please DO comment it. Usually workaround aren't obvious, and it would be incredibly helpful to comment all of them; and do not hesitate to write extensive comments. The clearer you write - the less time your colleagues will spend next

Re: [openstack-dev] [Fuel][fuel] How can I install Redhat-OSP using Fuel

Hey Fei LU, Thanks for being interested in Fuel. I'll help you with pleasure. First of all, as Vladimir mentioned, you need to create a new release. That's could be done by POST request to /api/v1/releases/. You can use JSON of CentOS with slight changes. When releases is created you need to do

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Hi Javeria, Try to use 'master' in 'role' field. Example: - role: 'master' stage: pre_deployment type: shell parameters: cmd: echo all > /tmp/plugin.all timeout: 42 Let me know if you need additional help. Thanks, Igor P.S: Since Fuel 7.0 it's

Re: [openstack-dev] [Fuel] Change VIP address via API

Hey Aleksey, I agree that we need a separate API call for VIP allocation, thought I don't agree on some points you have proposed. See my comments below. > use PUT to change VIPs addresses (set them manually or request > to allocate them automatically) PUT requests SHOULD NOT be used for VIP

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

ote: >>> >>> After closer look, the only viable option in closer term seems to be >>> 'liberty-8.0' version. It does not to break comparisons that exist in the >>> code and allows for smooth transition. >>> >>> -- >>> Best regards, >>> Oleg

Re: [openstack-dev] [Fuel] Modularization activity POC

Hey Evgeniy. This is awesome news1 I believe that microservices is way to go. Despite the fact that them bring a set of classical problems (e.g. duplication of domain entities) we will win more than loose. :) If there will be any specs or design meetings, please send me invite - I'd gladly join

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

Hey Oleg, I've read the post [1] and I didn't get how exactly minor releases of *stable* branch will be versioned? Let's say 2015.2.0 is Liberty. How 2015.2.1 will be versioned? [1] http://ttx.re/new-versioning.html Thanks, Igor On Thu, Oct 15, 2015 at 6:59 PM, Oleg Gelbukh

Re: [openstack-dev] [Fuel] Proposal to freeze old Fuel CLI

+1 to Sebastian. On Wed, Oct 14, 2015 at 12:13 PM, Sebastian Kalinowski wrote: > Roman, this was already discussed in [1]. > The conclusion was that we will implement new features in both places so > user will not have to > use "old" fuelclient to do some things and the

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

.0/'. > > -- > Best regards, > Oleg Gelbukh > > On Fri, Oct 16, 2015 at 12:45 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> Hey Oleg, >> >> I've read the post [1] and I didn't get how exactly minor releases of >> *stable* branch will

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

rmail/openstack-dev/2015-May/065144.html > [2] > https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases > > -- > Best regards, > Oleg Gelbukh > > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote:

Re: [openstack-dev] [Fuel] Assigning VIPs on network config serialization

ctually described in [1]. Should we allocate VIPs on > network check as well? > > > 1. https://bugs.launchpad.net/fuel/+bug/1487996 > > > - romcheg > > >> 19 жовт. 2015 р. о 18:28 Igor Kalnitsky <ikalnit...@mirantis.com> >> написав(ла): >> >>

  1   2   3   >