Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for fuel-plugins-core

Sorry for being late on this. I've added Ilya to fuel-plugins-core group. Congrats, Ilya! On Sun, Sep 11, 2016 at 9:35 PM, Alexey Shtokolov wrote: > My strong +1 > > Ilya made and keeps making a great contribution to the development of Fuel > Plugins Framework > on both

[openstack-dev] [Fuel] Nominate Ilya Kutukov for fuel-plugins-core

Hey Fuelers, I'd like to nominate Ilya for joining fuel-plugins-core group. He's a top contributor by both reviews [1] and commits [2] over the past release cycle. Fuel cores, please share your votes. - Igor [1] http://stackalytics.com/?module=fuel-plugins=newton=marks [2]

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

-1 for the proposal. I see no problems to add guys who're familiar with various sub-projects to multiple core groups. On Tue, Sep 6, 2016 at 10:38 AM, Evgeniy L wrote: > +1 to Lukasz. > -1 to the proposal, we had it this way for a quite some time, and it was not > good for the

Re: [openstack-dev] pydotplus (taskflow) vs pydot-ng (fuel)

Hi Thomas, If I'm not mistaken, pydot-ng [1] has been made by ex-fueler in order to overcome some limitations of pydot ( and do not change much. If pydotplus is alive project and do the same thing, I vote for using it in Fuel. Thanks, Igor [1]: https://pypi.io/project/pydot-ng/ On Tue, Aug 2,

Re: [openstack-dev] [Fuel]Nominating Vitalii Kulanov for python-fuelclient-core

Vitaly's doing a great job. +2, no doubts! On Mon, Jul 25, 2016 at 6:27 PM, Tatyana Leontovich wrote: > A huge +1 > > On Mon, Jul 25, 2016 at 4:33 PM, Yegor Kotko wrote: >> >> +1 >> >> On Mon, Jul 25, 2016 at 3:19 PM, Roman Prykhodchenko

Re: [openstack-dev] [all][Python 3.4-3.5] Async python clients

Denis Makagon wrote: > I'm using event loop with uvloop policy, so i must stay non-blocked > within main thread and don't mess up with GIL by instantiating new thread. You won't be blocked or "messed up" with GIL as long as new thread is I/O bound. Background thread is a good solution in such

[openstack-dev] [Fuel][Plugins] Fuel Plugin Builder 4.1.0 released!

Hey Fuelers, I'm glad to announce that FPB (fuel plugin builder) v4.1.0 has been released on PyPI [1]. It's mostly a maintenance release without new features. Here's a changelog highlights: * `tasks.yaml` is now optional for package version "4.0.0" [2] * Fuel Mitaka (9.0) is supported by

Re: [openstack-dev] [Fuel] Replace OSTF with Rally

> On Jun 27, 2016, at 16:57, Andrey Kurilin wrote: > > Rally consists of two main components: Rally Task and Rally Verification. > They are totally separated. > Task component is fully pluggable and you can run there whatever you want in > whatever you want way. Andrey,

Re: [openstack-dev] [Fuel] Replace OSTF with Rally

> On Jun 27, 2016, at 16:23, Alex Schultz wrote: > > I thought Rally was more for benchmarking. Wouldn't Tempest make more sense? > According to Rally wiki page [1], it seems they have a verification layer (Tempest so far). Hm, I wonder does it mean we will need to

Re: [openstack-dev] [Fuel] Merge IRC channels

> On Jun 25, 2016, at 12:39, Roman Prykhodchenko wrote: > > Since Fuel is a part of OpenStack now, should we rename #fuel to > #openstack-fuel? > > - romcheg +1. Let's be consistent in naming convention with most Big Tent projects. - igor

Re: [openstack-dev] [Fuel] Deprecation of fuel-mirror tool

Vladimir, Thanks for driving this! What about fuel-mirror itself? Does it mean it's deprecated? If so, what will happen to perestroika scripts inside it [1]? It seems strange that fuel-mirror contains them. Thanks, Igor [1] https://github.com/openstack/fuel-mirror/tree/master/perestroika >

Re: [openstack-dev] [fuel] discovery and deploy a compute node automatically

> On May 25, 2016, at 13:53, jason wrote: > > Thanks, and yes you got my point, my "automatically ", means after a new node > has been discovered , the deployement process starts automatically. Cron may > help, but what if I need more info to check if that new discovered

Re: [openstack-dev] [fuel] discovery and deploy a compute node automatically

Hey Jason, What do you mean by "automatically"? You need to assign "compute" role on that discovered node, and hit "Deploy Changes" button. If you really want to deploy any new discovered node automatically, I think you can create some automation script and put it under cron. Hope it helps,

Re: [openstack-dev] [fuel] release version numbers: let's use semvers

Hey Zigo, In Python community there's a PEP-440 [1] that defines a versioning scheme. The thing you should know is, the PEP __is not__ compatible with semver, and it's totally fine to have two components version. So I don't think we should force version changes from two-components to

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

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

gt; > 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

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

Re: [openstack-dev] [Infra][Fuel] Increasing deadlock_timeout for PostgreSQL

Hey Roman, Thank you for investigation. However, I think that changing 'deadlock_timeout' won't help us. According to PostgreSQL documentation [1], this option sets how frequently to check if there is a deadlock condition. So it won't fix deadlocks themselves. Thus I see no reason why we should

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

Hey Fuelers, As you might know recently we encounter a lot of random test failures on CI, and they are still there (likely with a bit less probability). A nature of that random failures is actually not a random, they are happened because of so called fake threads. Fake threads, actually, ain't

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

ch is the main reason > of randomly failing UI tests. To fix it, we need to fix fake threads > behaviour. > > 2016-03-16 17:06 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>: >> >> Hey Fuelers, >> >> As you might know recently we encounter a lot of

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

wrote: >> > Dmitry, >> > >> > We are really close to have the consensus, but we need one more meeting >> > with Fuel-Python Component Lead Igor Kalnitsky to make the final >> > decision. >> > All patches [0] are on review. The meeting is sc

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

ppe...@mirantis.com> wrote: > > On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com) > wrote: > > Hey Roman, > > Thank you for bringing this up. +1 from my side, especially taking > into account the patch where we tried to solve logrotated logs problem > [1

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

Hey Roman, Thank you for bringing this up. +1 from my side, especially taking into account the patch where we tried to solve logrotated logs problem [1]. It's complex and unsupportable, as well as already existed logview code in Nailgun. Patrick, Simon, Does LMA plugin support logs from master

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov <ikutu...@mirantis.com> >> >>>> wrote: >> >>>>> >> >>>>> Igor, i completely agree, actually plugin examples is almost a >> >>>>> copy-paste. >> >>

Re: [openstack-dev] [fuel][Fuel-web] : make html command not working

Hey Prameswar, That't because dependencies weren't installed. I can't remember which ones are required for building docs so my suggestion is to install them all. $ virtualenv venv $ . venv/bin/activate $ pip install -r ../nailgun/test-requirements.txt $ make html Let me know if

Re: [openstack-dev] [Fuel][Fuel-web] Jenkins failing, tox -e py27 error

Hey Jeremy, I got it and I'm working on patch [1] that must solve it. I simply stop doing postre setup since it seems is already setup. [1] https://review.openstack.org/#/c/289278/ On Mon, Mar 7, 2016 at 4:38 PM, Jeremy Stanley wrote: > On 2016-03-07 16:02:40 +0530 (+0530),

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

ght now we have failed tests until we can decide on a solution >> that works for everybody. >> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >> > No, this is a wrong road to go. >> > >> > What if in Fuel 10 we dr

Re: [openstack-dev] [Fuel][Fuel-web] Jenkins failing, tox -e py27 error

Hey Prameswar, It seems we're experiencing that issue on all our patches. For example, the same error blocks that patch from merge [1]. I think it's some OpenStack CI issue. Let's give a time. - Igor [1] https://review.openstack.org/#/c/287558/ On Mon, Mar 7, 2016 at 12:32 PM, Prameswar Lal

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

No, this is a wrong road to go. What if in Fuel 10 we drop v1 plugins support? What should we do? Remove v1 example from source tree? That doesn't seem good to me. Example plugins are only examples. The list of supported releases must be maintained on system test side, and system tests must

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

t 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 <ika

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

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

Re: [openstack-dev] [Fuel][FFE] Use RGW as a default object store instead of Swift

Hey Konstantin, I see that provided patch [1] is for stable/8.0. Fuel 8.0 is recently released and we usually do not accept any features to stable branch. Or your meant that patch for master branch? Thanks, Igor [1]: https://review.openstack.org/#/c/286100/ On Tue, Mar 1, 2016 at 4:44 PM,

[openstack-dev] [Fuel] [Plugins] Fuel Plugin Builder 4.0.0 released

Hey Fuelers, I want to announce that FPB (fuel plugin builder) v4.0.0 has been released on PyPI [1]. New package version "4.0.0" includes but not limited to: * New flag `is_hotpluggable` in `metadata.yaml` that allows to install and use plugin on previously deployed environments. * Plugin can

Re: [openstack-dev] [Fuel][murano][fuel-plugins] Move Murano to plugin from Fuel box

Hey Denis, I didn't read the spec yet, but want to raise one important question. AFAIU, you plan to release Murano plugin between Fuel 9.0 and Fuel 10, so the question is do you plan to support installation of Murano plugin on Fuel 9.0? If so, that might be a problem. Thanks, - Igor On Wed, Feb

Re: [openstack-dev] [Fuel] Wildcards instead of

re is already a task running by the wildcard: > https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4 > However, it this case it might work with plugins. > > Best regards, > Kyrylo > > On Fri, Feb 19, 2016 at

Re: [openstack-dev] [Fuel] Wildcards instead of

Hey Kyrylo, As it was mentioned in the review: you're about to break roles defined by plugins. That's not good move, I believe. Regarding 'exclude' directive, I have no idea what you're talking about. We don't support it now, and, anyway, there should be no difference between roles defined by

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Vladimir, Obviously, there will be regressions in other scenarios. However, it's better to catch them now. We have not much time before FF, and it'd be better to merge such features as early as possible, and do not wait for merge hell a day before FF. The thing we need to know is that BVT is

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

, 2016 at 12:04 PM, Tatyana Leontovich > <tleontov...@mirantis.com> wrote: >> >> +1 >> >> >> >> On Mon, Feb 8, 2016 at 11:54 AM, Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >>> >>> Hey Fuelers, >>> >>>

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

loyment result message, Horizon link is in the top block on the dashboard > - it's very hard to get lost. > > 2016-02-11 20:10 GMT+07:00 Igor Kalnitsky <ikalnit...@mirantis.com>: >> >> Vitaly, >> >> What about adding some button with "Go" or "Vis

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

adding or removing some >>> files or replacing some paths. >>> * and, perhaps, logic anchors with YACL or other DSL in tasks >>> dependancies if this functionality will be added this in theory could allow >>> to use or not to use some graph parts depending

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

Vitaly, What about adding some button with "Go" or "Visit" text? Somewhere on the right size of line? It'd be easy to understand what to click to visit the dashboard. - Igor On Thu, Feb 11, 2016 at 1:38 PM, Vitaly Kramskikh wrote: > Roman, > > For with enabled SSL it

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Well, I'm going to build a new ISO and run BVT. As soon as they are green, I'm going to approve the change. On Tue, Feb 9, 2016 at 12:32 PM, Bogdan Dobrelya <bdobre...@mirantis.com> wrote: > On 08.02.2016 17:05, Igor Kalnitsky wrote: >> Hey Fuelers, >> >> When we are

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

k results and merge changes tomorrow. > I've run BVT more than 100 times, it works, but I would like to check more > deployment cases. > And I guess it should be easy to troubleshoot if docker-related and > task-based related changes will be separated by a few days. > > 2016-

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Hey Fuelers, When we are going to enable it? I think since HCF is passed for stable/8.0, it's time to enable task-based deployment for master branch. Opinion? - Igor On Wed, Feb 3, 2016 at 12:31 PM, Bogdan Dobrelya wrote: > On 02.02.2016 17:35, Alexey Shtokolov wrote:

[openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Hey Fuelers, I'd like to nominate Fedor Zhadaev for the fuel-menu-core team. Fedor's doing good review with detailed feedback [1], and has contributes over 20 patches during Mitaka release cycle [2]. Fuel Cores, please reply back with +1/-1. - igor [1]

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

Simon, > Nope, it doesn't work for me since it should run for *all* the nodes, > irrespective of their roles. AFAIK update_required doesn't support '*'. If your plugin provides a new node role as well as additional tasks for other node roles, you may try to workaround that by using

Re: [openstack-dev] [Fuel] CentOS bootstrap image retirement

No objections from my side. Let's do it. On Tue, Feb 2, 2016 at 8:35 PM, Dmitry Klenov wrote: > Hi Sergey, > > I fully support this idea. It was our plan as well when we were developing > Ubuntu Bootstrap feature. So let's proceed with CentOS bootstrap removal. > > BR, >

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Roman P. wrote: > Putting extra checks will create a more fool-proof but less configurable > software. I’d vote for letting users shoot their feet using their plugins > but making Fuel more flexible. I won't agree here. You see, what if two plugins wants to override the core network role?

Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

Hey folks, Simon P. wrote: > 1. Run task X for plugin A (if installed). > 2. Run task Y for plugin B (if installed). > 3. Run task Z for plugin A (if installed). Simon, could you please explain do you need this at the first place? I can imagine this case only if your two plugins are kinda

Re: [openstack-dev] [All][Packetary][Fuel] New project: Packetary (Repository management library)

Hey Bulat, It's nice to hear that packetary finally got its own repo. However, I took a look at roadmap [1] and wonder why do you plan to add possibility to build RPM/DEB packages? It seems to me like it shouldn't be packetary's concern, and I'd like to see packetary as repo management tool, not

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

Dmitry, > We can mark a cluster 'operational' after successful deployment. And we > can disable 'stop' button on this kind of clusters. I think this is a best solution so far. Moreover, I don't know how to fix it properly since there could be a lot of questions how this button should behave at

Re: [openstack-dev] [fuel] New gate jobs for 'fuel-agent' and 'python-fuelclient' packages

Hey Dmitry - That's cool, thank you. I wonder you build RPM or DEB or both? - Igor On Thu, Jan 21, 2016 at 12:48 PM, Dmitry Kaiharodsev wrote: > Hi to all, > > please be informed that starting from today we're launching additional > gating jobs [1] [2]: > > - for

Re: [openstack-dev] [fuel] New gate jobs for 'fuel-agent' and 'python-fuelclient' packages

- trying to build DEB > as well > > [1] > https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/builders/build-pkgs.sh > > On Thu, Jan 21, 2016 at 12:51 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> Hey Dmitry - >> &

Re: [openstack-dev] [Fuel] nova-network removal

Roman, Sheena, You meant to remove nova-network completely? Or only for new environments? Should we support nova-network for old (let's say, 7.0) clusters? Thanks, Igor On Fri, Jan 15, 2016 at 10:03 PM, Sheena Gregson wrote: > Adrian – can someone from the PI team please

Re: [openstack-dev] [Fuel] How to auto allocate VIPs for roles in different network node groups?

> Random choices aren't good IMHO, let's use defaults. What if neither of node is in default group? Still use default group? And prey that some third-party plugin will handle this case properly? AFAIU, default nodegroup is slightly artificial thing. There's no such thing like *default*

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

lective >> container > > > > AFAIK '/var/log/docker-logs/' is available from mcollective container and > mounted to /var/log/: > > [root@fuel-lab-cz5557 ~]# dockerctl shell mcollective mount -l | grep > os-varlog > /dev/mapper/os-varlog on /var/log type ext4 > (rw,rela

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Hey Maceij - > About hardlinks - wouldn't it be better to use symlinks? > This way we don't occupy more space than necessary AFAIK, hardlinks won't occupy much space. They are the links, after all. :) As for symlinks, I'm afraid shotgun (and fabric underneath) won't resolve them and links are

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

ke it follow symbolic links, so it looks good to me. >> >> Bartłomiej >> >> On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >>> >>> Hey Maceij - >>> >>> > About hard

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! >>> >>> R

Re: [openstack-dev] [Fuel] [Nailgun] Deadlocks and random test failures

Hey Vitaly, Are you the problem is in deadlock? I see the deadlock detecter traceback, but not an actual deadlock. I'm not sure could it be a reason for failure or not, it's better to ask Alexander Kislitsky. Thanks, Igor On Wed, Dec 30, 2015 at 2:57 PM, Vitaly Kramskikh

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

have as well >> gotten used to it and assumed by default that this would not change. So some >> of their respective features they are developing for their own sake may >> depend on Postgres 9.3 and we will never be able to tell the fraction of >> such use cases. Moreover,

Re: [openstack-dev] [Fuel] Liberty naming in Fuel 8.0

Hi Sergii, You've raised an old thread started by Oleg G. once again [1]. Last time we didn't reach any agreements, but I'm sure that it would be better to change version into "liberty-8.0" instead of "2015.2.0-8.0". What do you think? It could be done easily with two patches - one to nalgun,

Re: [openstack-dev] [Fuel] Nominate Artem Roma for fuel-ostf core

I believe fuel-ostf project needs a python dev to take care of adapter. So +1 from my side. P.S: I'm not a fuel-ostf core, but I think Dmitry S. doesn't show any attention to this project. In order to maintain a high quality of code, I'd consider to remove him from this group. On Wed, Dec 23,

Re: [openstack-dev] [Fuel] Nominate Artem Panchenko for fuel-qa core

Artem is doing a great job! Definitely +1. On Wed, Dec 23, 2015 at 4:33 PM, Bulat Gaifullin wrote: > +1 > > Regards, > Bulat Gaifullin > Mirantis Inc. > > > > On 23 Dec 2015, at 17:29, Aleksey Kasatkin wrote: > > +1 > > Aleksey Kasatkin > > > On

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

015 7:32 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt > on Wizard > >> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky >> <ik

Re: [openstack-dev] [Fuel] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

eksey Kasatkin >>> <akasat...@mirantis.com> wrote: >>>> >>>> +1. >>>> >>>> >>>> Aleksey Kasatkin >>>> >>>> >>>> On Mon, Dec 14, 2015 at 12:49 PM, Vladimir Sharshov >>>> <vshar

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

Hello, Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or single entry point) for dealing with other hypervisors, including qemu and kvm. So it's kinda confusing, I'd prefer to find another solution. Thanks, Igor On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M

Re: [openstack-dev] [Fuel] Removal of support for nova-network

I don't think it's a good idea to drop support of 7.0 nova-network setup in 8.0. We should keep compatibility for at least one release. On Tue, Dec 22, 2015 at 9:15 AM, Aleksey Kasatkin wrote: > Sergii, > > We could remove it completely from nailgun if support for 7.0 and

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

HV like > vCenter, Xen, or HyperV. The actual selection between qemu and kvm will be a > HV specific option in this case. > > On Mon, Dec 21, 2015 at 1:24 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> Hello, >> >> Agree with Kevin. libvirt itself isn

Re: [openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

> create Bareon-API repository, and start production ready implementation For what reason do we need a separate repo? I thought API will be a part of bareon repo. Or bareon is just a provisioning agent, which will be driven by bareon-api? On Thu, Dec 17, 2015 at 12:29 PM, Evgeniy L

Re: [openstack-dev] [Fuel][Ubuntu bootstrap] WebUI notification

isabled by fuel-bootstrap-cli after building, > activation of bootstrap image. > > Best regards, > Svechnikov Artur > > On Wed, Dec 16, 2015 at 4:05 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> > I really don't like setting the error message as

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

> From what I understand, we are using 9.2 since the CentOS 7 switch. Can > anyone point me to a bug caused by that? AFAIK, there's no such bugs. Some folks have just *concerns*. Anyway, it's up to packaging team to decide whether to package or not. From Nailgun POV, I'd like to see classical

Re: [openstack-dev] [Fuel][Ubuntu bootstrap] WebUI notification

> I really don't like setting the error message as the default one in > the DB schema and consider it as a last resort solution. If > possible update the message to error one just before you start > to build the image. +1. > What about add some check or some message > "Fuel-master Deployment in

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

Does it mean SQLAlchemy will have one unified interface to make JSON queries? So we can use different backends if necessary? Thanks, - Igor On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer <mba...@redhat.com> wrote: > > > On 12/15/2015 07:20 AM, Igor Kalnitsky wrote: >&g

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

/objects/release.py#L142-L145 > [2] > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L554-L555 > [3] > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/serializers/node.py#L124-L126 > > -- > Best

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

es. Obviously, accidental change of Postgres version does not follow > such a policy in any way. So I see no other ways except for getting back to > Postgres 9.3. > > > On Tue, Dec 15, 2015 at 7:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> Hey Mike, &g

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

Danjou <jul...@danjou.info> wrote: > On Mon, Dec 14 2015, Igor Kalnitsky wrote: > >> The things I want to notice are: >> >> * Currently we aren't tied up to PostgreSQL 9.3. >> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using a >> set o

Re: [openstack-dev] [Fuel] [Plugins] Ways to improve plugin links handling in 9.0

Hey Vitaly, I agree that having a lot of logic (receiving auth token, creating payload and doing post request) in RPM post_install section is a huge overhead, and definitely it's not a way to go. We have to find better solution, and I think it should be done declaratively (via some YAML).

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

; Regards, > > Artem Silenkov > --- > MOS-Packaging > > On Tue, Dec 15, 2015 at 1:28 PM, Julien Danjou <jul...@danjou.info> wrote: >> >> On Mon, Dec 14 2015, Igor Kalnitsky wrote: >> >> > The things I want to notice are: >> > >> >

Re: [openstack-dev] [Fuel] Separate master node provisioning and deployment

Vladimir, Thanks for raising this question. I totally support idea of separating provisioning and deployment steps. I believe it'll simplify a lot of things. However I have some comments regarding this topic, see them inline. :) > For a package it is absolutely normal to throw a user dialog.

[openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

Hi Fuelers, As you might know, recently we moved to CentOS 7 and as a result we got a small regression with PostgreSQL: * Fuel 7 runs on CentOS 6.6 and uses manually built PostgreSQL 9.3. * Fuel 8 runs on CentOS 7 and uses PostgreSQL 9.2 from CentOS upstream repos. There are different opinions

Re: [openstack-dev] [Fuel] Separate master node provisioning and deployment

more flexible > because deployment could be modular (several stages). > > One of potential disadvantages is that it is harder to track package > dependencies, but I think > a deployment script should be a root of the package dependency tree. > > > > Vladimir Kozhukal

[openstack-dev] [Fuel] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

Hi Fuelers, I'd like to nominate Bulat Gaifulin [1] for * fuel-web-core [2] * fuel-mirror-core [3] Bulat's doing a really good review with detailed feedback and he's a regular participant in IRC. He's co-author of packetary and fuel-mirror projects, and he made valuable contribution to fuel-web

Re: [openstack-dev] [Fuel] Multiple repos UX

Hey folks - +1 from my side on the idea of having the unified repo format. It will simplify a cross-project contribution. I think we can file a blueprint for 9.0. I have only two questions to discuss: * We need to declare format for RPM repos either. * Shouldn't we use slightly different set of

Re: [openstack-dev] [Fuel] Multiple repos UX

we are developing yet another standard. > > Do we really need a custom format? Why can not we use native format > for yum.conf and apt.sources files, and native tooling (all those > python bindings, cli utils and so on) which is already developed to > work with them? > > On Fr

Re: [openstack-dev] [Fuel] Christmas Core Cleanup

n that particular > repo (he is core in fuel-web repo). I'm not sure how stackalytics tracks > that. > > [1] http://stackalytics.com/report/contribution/fuel-docs/90 > > Thanks, > > On Thu, Dec 10, 2015 at 8:12 AM Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: &g

[openstack-dev] [Fuel] Christmas Core Cleanup

# shotgun [3] * Dmitry Shulyak * Evgeniy L # fuel-upgrade [4] * Aleksey Kasatkin * Vladimir Kozhukalov # fuel-main [5] * Dmitry Pyzhov * Roman Vyalov # fuel-agent [6] * Aleksey Kasatkin * Evgeniy L * Igor Kalnitsky Also, I've removed Sebastian Kalinowski as he

Re: [openstack-dev] [Fuel] Christmas Core Cleanup

ject > matter experts) > in specific areas, so they will continue reviewing related patches. > > Thanks, > > On Thu, Dec 10, 2015 at 2:42 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: >> >> Hey folks, >> >> In an effort to do some houseke

Re: [openstack-dev] [Fuel] Extend FFE for "Disable queue mirroring for RPC queues in RabbitMQ"

Hey Dmitry, Despite the fact the feature promises performance boost (IIUC) and it's really nice to have it, I agree with Mike's opinion - it's late to continue working on features. Each delay means less time to test it, and we need to focus on quality. I'm sorry, but I have to say "No" on

Re: [openstack-dev] [Fuel] Patch size limit

Hey Andrii, I'm totally agree with you about contribution guides, except one thing - we need and should force users to split huge patches into set of small ones. Mostly because it will simplify support and review of patches. Previously we ignored this rule pretty often, and get a lot of troubles

Re: [openstack-dev] [Fuel] FFE for Ubuntu bootstrap

Hey Dmitry, I'm ok with FFE till Tuesday. Moreover, it makes sense to do so in order to reduce affection on CentOS 7 patches. - Igor On Thu, Dec 3, 2015 at 8:58 PM, Dmitry Klenov wrote: > Hi folks, > > Let me clarify the situation with Ubuntu bootstrap feature. > > First

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

> shouldn't we switch tests to work with python2.7 instead of python2.6? Currently we run tests using both py26 and py27, see the * gate-fuel-web-python27 (openstack infra) * verify-fuel-web-py27 (fuel infra) So the question is should we drop py26 jobs? I think yes, we should.. but once CentOS

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

ng Fuel, of course) won’t have py26 gates. > > 2. We still run py26 tests on Fuel-CI side and don’t plan to drop them along > with > OS-Infra folks, so it’s absolutely possible to have a working py26 CI for the > duration > of Centos 7 migration (or keep it even after that). > &

Re: [openstack-dev] [Fuel] Feature Freeze is soon

Sheena, Yeah, we will have a meeting in #fuel-dev IRC channel. :) - Igor On Wed, Dec 2, 2015 at 4:25 PM, Sheena Gregson wrote: > Is the meeting at 8am PST today? > > > > From: Mike Scherbakov [mailto:mscherba...@mirantis.com] > Sent: Wednesday, December 02, 2015 1:57 AM

Re: [openstack-dev] [Fuel] Patch size limit

Hey folks, I agree that patches must be as small as possible. I believe it will significantly increase our review experience - more fast review, and, therefore, landing to master. However, I don't agree that we should introduce criteria based on LOC, because of mentioned reasons above. I believe

Re: [openstack-dev] [Fuel][FFE] Component registry

Fuelers, As we decided on today's IRC meeting in #fuel-dev, FFE is granted for 1 week only. Thanks, igor On Wed, Dec 2, 2015 at 5:42 PM, Andrian Noga wrote: > Colleagues, > > Folks, > I would like to request feature freeze exception for Component registry >

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request: Task Based Deployment in Astute

Hey folks, As we decided on today's IRC meeting in #fuel-dev, FFE exception is granted on the following conditions (if get them right): * the feature is marked as experimental * patches should be merged by the end of next week Thanks, igor On Tue, Dec 1, 2015 at 10:01 PM, Vladimir Kuklin

[openstack-dev] [Fuel] Fuel Python Gerrit Dashboard

Hey Fuelers, As a part of improving review process, I've prepared a Gerrit Dashboard for Python projects [1]. First and foremost, I did it for myself (I believe it will help me to get attention to *ready-to-merge* patches), but I want to share the link with you. Feel free to use it! [1]

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hey Vladimir, Thanks for your effort on doing this job. Unfortunately we have not so much time left and FF is coming, so I'm afraid it's become unreal to make it before FF. Especially if it takes 2-3 days to fix system tests. Andrew, I had the same opinion some time ago, but it was changed

Re: [openstack-dev] [Fuel] CentOS-7 Transition Plan

these two >>> features (Centos7 and Docker removal). We agreed that Dmitry's feature is >>> much more complicated and of higher priority. So, Centos 7 should be merged >>> first and then I'll rebase my patches (mostly supervisor -> systemd). >>> >>&

  1   2   3   >