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
> My strong +1
> Ilya made and keeps making a great contribution to the development of Fuel
> Plugins Framework
> on both
I'd like to nominate Ilya for joining fuel-plugins-core group. He's a
top contributor by both reviews  and commits  over the past
release cycle. Fuel cores, please share your votes.
-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
If I'm not mistaken, pydot-ng  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
On Tue, Aug 2,
Vitaly's doing a great job. +2, no doubts!
On Mon, Jul 25, 2016 at 6:27 PM, Tatyana Leontovich
> A huge +1
> On Mon, Jul 25, 2016 at 4:33 PM, Yegor Kotko wrote:
>> On Mon, Jul 25, 2016 at 3:19 PM, Roman Prykhodchenko
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
I'm glad to announce that FPB (fuel plugin builder) v4.1.0 has been
released on PyPI .
It's mostly a maintenance release without new features. Here's a
* `tasks.yaml` is now optional for package version "4.0.0" 
* Fuel Mitaka (9.0) is supported by
> 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.
> 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 , it seems they have a verification layer
(Tempest so far). Hm, I wonder does it mean we will need to
> On Jun 25, 2016, at 12:39, Roman Prykhodchenko wrote:
> Since Fuel is a part of OpenStack now, should we rename #fuel to
> - romcheg
+1. Let's be consistent in naming convention with most Big Tent projects.
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 ? It
seems strange that fuel-mirror contains them.
> 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
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
Hope it helps,
In Python community there's a PEP-440  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
>>>> > 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
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
> 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
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
Thank you for investigation. However, I think that changing
'deadlock_timeout' won't help us. According to PostgreSQL
documentation , 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
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
ch is the main reason
> of randomly failing UI tests. To fix it, we need to fix fake threads
> 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
>> > 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  are on review. The meeting is sc
> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com)
> 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
Thank you for bringing this up. +1 from my side, especially taking
into account the patch where we tried to solve logrotated logs problem
. It's complex and unsupportable, as well as already existed
logview code in Nailgun.
Does LMA plugin support logs from master
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.
That't because dependencies weren't installed. I can't remember which
ones are required for building docs so my suggestion is to install
$ virtualenv venv
$ . venv/bin/activate
$ pip install -r ../nailgun/test-requirements.txt
$ make html
Let me know if
I got it and I'm working on patch  that must solve it. I simply
stop doing postre setup since it seems is already setup.
On Mon, Mar 7, 2016 at 4:38 PM, Jeremy Stanley wrote:
> On 2016-03-07 16:02:40 +0530 (+0530),
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>
>> > No, this is a wrong road to go.
>> > What if in Fuel 10 we dr
It seems we're experiencing that issue on all our patches. For
example, the same error blocks that patch from merge .
I think it's some OpenStack CI issue. Let's give a time.
On Mon, Mar 7, 2016 at 12:32 PM, Prameswar Lal
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
>> 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
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
I see that provided patch  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?
On Tue, Mar 1, 2016 at 4:44 PM,
I want to announce that FPB (fuel plugin builder) v4.0.0 has been
released on PyPI .
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
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.
On Wed, Feb
re is already a task running by the wildcard:
> However, it this case it might work with plugins.
> Best regards,
> On Fri, Feb 19, 2016 at
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
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
, 2016 at 12:04 PM, Tatyana Leontovich
> <tleontov...@mirantis.com> wrote:
>> On Mon, Feb 8, 2016 at 11:54 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
>>> Hey Fuelers,
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>:
>> What about adding some button with "Go" or "Vis
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
The original idea is to provide a way to build plugin that are
compatible with few releases. It makes sense to me, cause it looks
awful if you need to maintain different branches for different Fuel
releases and there's no difference in the sources. In that case, each
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.
On Thu, Feb 11, 2016 at 1:38 PM, Vitaly Kramskikh
> For with enabled SSL it
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
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.
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
On Wed, Feb 3, 2016 at 12:31 PM, Bogdan Dobrelya wrote:
> On 02.02.2016 17:35, Alexey Shtokolov wrote:
I'd like to nominate Fedor Zhadaev for the fuel-menu-core team.
Fedor's doing good review with detailed feedback , and has
contributes over 20 patches during Mitaka release cycle .
Fuel Cores, please reply back with +1/-1.
> 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
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.
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?
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
It's nice to hear that packetary finally got its own repo. However, I
took a look at roadmap  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
> 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
Hey Dmitry -
That's cool, thank you. I wonder you build RPM or DEB or both?
On Thu, Jan 21, 2016 at 12:48 PM, Dmitry Kaiharodsev
> Hi to all,
> please be informed that starting from today we're launching additional
> gating jobs  :
> - for
- trying to build DEB
> as well
> On Thu, Jan 21, 2016 at 12:51 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> Hey Dmitry -
You meant to remove nova-network completely? Or only for new
environments? Should we support nova-network for old (let's say, 7.0)
On Fri, Jan 15, 2016 at 10:03 PM, Sheena Gregson wrote:
> Adrian – can someone from the PI team please
> 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*
> 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
> /dev/mapper/os-varlog on /var/log type ext4
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
ke it follow symbolic links, so it looks good to me.
>> On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
>>> Hey Maceij -
>>> > About hard
>>> 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!
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.
On Wed, Dec 30, 2015 at 2:57 PM, Vitaly Kramskikh
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,
You've raised an old thread started by Oleg G. once again . 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
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,
Artem is doing a great job! Definitely +1.
On Wed, Dec 23, 2015 at 4:33 PM, Bulat Gaifullin
> Bulat Gaifullin
> Mirantis Inc.
> On 23 Dec 2015, at 17:29, Aleksey Kasatkin wrote:
> Aleksey Kasatkin
015 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 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
>>> <akasat...@mirantis.com> wrote:
>>>> Aleksey Kasatkin
>>>> On Mon, Dec 14, 2015 at 12:49 PM, Vladimir Sharshov
Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or
single entry point) for dealing with other hypervisors, including qemu
So it's kinda confusing, I'd prefer to find another solution.
On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M
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
> We could remove it completely from nailgun if support for 7.0 and
> 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>
>> Agree with Kevin. libvirt itself isn
> 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
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>
>> > I really don't like setting the error message as
> 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
> 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.
> What about add some check or some message
> "Fuel-master Deployment in
Does it mean SQLAlchemy will have one unified interface to make JSON
queries? So we can use different backends if necessary?
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:
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>
>> Hey Mike,
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  that ties Fuel up to PostgreSQL 9.3+ by using a
>> set o
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).
> Artem Silenkov
> 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:
Thanks for raising this question. I totally support idea of separating
provisioning and deployment steps. I believe it'll simplify a lot of
However I have some comments regarding this topic, see them inline. :)
> For a package it is absolutely normal to throw a user dialog.
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
> 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
I'd like to nominate Bulat Gaifulin  for
* fuel-web-core 
* fuel-mirror-core 
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
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
I have only two questions to discuss:
* We need to declare format for RPM repos either.
* Shouldn't we use slightly different set of
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
n that particular
> repo (he is core in fuel-web repo). I'm not sure how stackalytics tracks
>  http://stackalytics.com/report/contribution/fuel-docs/90
> On Thu, Dec 10, 2015 at 8:12 AM Igor Kalnitsky <ikalnit...@mirantis.com>
# shotgun 
* Dmitry Shulyak
* Evgeniy L
# fuel-upgrade 
* Aleksey Kasatkin
* Vladimir Kozhukalov
# fuel-main 
* Dmitry Pyzhov
* Roman Vyalov
# fuel-agent 
* Aleksey Kasatkin
* Evgeniy L
* Igor Kalnitsky
Also, I've removed Sebastian Kalinowski as he
> matter experts)
> in specific areas, so they will continue reviewing related patches.
> On Thu, Dec 10, 2015 at 2:42 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> Hey folks,
>> In an effort to do some houseke
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
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
I'm ok with FFE till Tuesday. Moreover, it makes sense to do so in
order to reduce affection on CentOS 7 patches.
On Thu, Dec 3, 2015 at 8:58 PM, Dmitry Klenov wrote:
> Hi folks,
> Let me clarify the situation with Ubuntu bootstrap feature.
> 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
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
> OS-Infra folks, so it’s absolutely possible to have a working py26 CI for the
> of Centos 7 migration (or keep it even after that).
Yeah, we will have a meeting in #fuel-dev IRC channel. :)
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
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
As we decided on today's IRC meeting in #fuel-dev, FFE is granted for
1 week only.
On Wed, Dec 2, 2015 at 5:42 PM, Andrian Noga wrote:
> I would like to request feature freeze exception for Component registry
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
On Tue, Dec 1, 2015 at 10:01 PM, Vladimir Kuklin
As a part of improving review process, I've prepared a Gerrit
Dashboard for Python projects . 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 - 100 of 227 matches
Mail list logo