Hi all,
As next step for improving Fuel security we are introducing SSL for both
Fuel [1] and OS API endpoints [2]. Both specs assume usage of self-signed
certificates generated by Fuel.
It also required to allow users to use their own certs to secure their
deployments
(two blueprints that touch
On Tue, Sep 9, 2014 at 5:53 PM, Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
So I think that we need to start on [3]. As this is required for OSt
public
endpoint SSL and also for Fuel SSL it can be quicker to make a first stage
where a self-signed certificate is managed from nailgun and a
I have some topics for [1] that I want to discuss:
1) Should we allow users to turn SSL on/off for Fuel master?
I think we should since some users may don't care about SSL and
enabling it will just make them unhappy (like warnings in browsers,
expiring certs).
2) Will we allow users (in
Hi all,
Some time ago we had a discussion about moving Nailgun to new web framework
[1].
There was comparison [2] of two possible options: Pecan [3] and Flask [4].
We came to conclusion that we need to move Nailgun on some alive web
framework
instead of web.py [5] (some of the reasons: [6]) but
2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:
I don't like that Flask uses a global request object [3].
Przemyslaw, actually Pecan does use global objects too. BTW, what's
wrong with global objects? They are thread-safe in both Pecan and
Flask.
To be fair, Pecan could
I never used Flask and Pecan personally so I can only rely from what I saw
in this thread and in both projects docs.
I don't have strong opinion, just want to share some thoughts.
I think that as a part of OpenStack community we should stick with Pecan
and because of the same reason
we can have a
2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:
Ok, guys,
It became obvious that most of us either vote for Pecan or abstain from
voting.
Yes, and it's been 4 days since last message in this thread and no
objections, so it seems
that Pecan in now our framework-of-choice
. I guess we'll dedicate some
engineer(s) responsible for doing such a research and then make all
our decisions on subject.
On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:
2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:
Ok
+1
2015-01-26 11:33 GMT+01:00 Roman Prykhodchenko m...@romcheg.me:
Hi Guys,
According to our previous thread [1] and the decision made there I’d like
to initiate separation of the original fuel-core group.
At the first step propose the following python guys from the original
fuel-core
+1 I'm all for separating it.
2015-01-26 17:52 GMT+01:00 Alexander Gordeev agord...@mirantis.com:
Hello Vladimir,
totally +1 for separating Fuel Agent out of fuel-web.
what will happen with fuel_agent_ci ?
On Mon, Jan 26, 2015 at 7:42 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com
Hello Fuelers,
There is more and more Python code appearing in fuel-library [1] that is
used in our Puppet manifests. Now, with introduction of Granular Deployment
feature it could appear more often as
writing some tasks as a Python script is a nice option.
First problem that I see is that in
+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 really nice thing and make it more
transparent.
2015-02-13 9:59 GMT+01:00 Evgeniy L
Hi,
2015-02-09 13:57 GMT+01:00 Nikolay Markov nmar...@mirantis.com:
They say, there is some kind of holywar around the topic on if
fuel-client tests should rely on working Nailgun API without mocking
it.
Could you point us where was such hollywar was, so we could get some
background on the
I assume that you considered a situation when we have a common repository
with RPMs for Fuel master and for nodes.
There are some plans (unfortunately I do not know details, so maybe someone
from OSCI could tell more) to split those repositories. How this workflow
will work with those separated
As I wrote in the review already: I like the idea of merging
those two tools and making a separate repository. After that
we could make they more visible in our documentation and wiki
so they could benefit from being used by broader audience.
Same for vagrant configuration - if it's useful (and
to add this to our jobs for unittests
run and syntax check. I am adding Aleksandr Didenko into the loop as he is
currently working on the similar task.
On Wed, Feb 18, 2015 at 4:53 PM, Jay Pipes jaypi...@gmail.com wrote:
On 02/18/2015 04:57 AM, Sebastian Kalinowski wrote:
Hello Fuelers
+1
2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski pkamin...@mirantis.com:
+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
http://stackalytics.com/report/users/jkirnosova for fuel-web
Hello,
Today we added Samuel Bartel as a Core Review for NetApp plugin [1]. He
will be now main
person leading the plugin development.
Congrats!
Best,
Sebastian
[1] https://github.com/stackforge/fuel-plugin-cinder-netapp
Hello,
I propose to move two old, unmaintained plugins to stackforge-attic as
there is no interest or plans in continuing development of them:
* https://github.com/stackforge/fuel-plugin-group-based-policy -
development is now done in another repository as different plugin
*
Indeed, great news!
I would only suggest to wait a little bit more that a few days with
switching
to the voting mode since it looks like there will be not so many patches
proposed to python-fuelclient as we are heading towards Hard Code Freeze.
I hope that the next step will be to enable Python
. They are really simple with a
very little room for a failure so should we wait longer?
19 серп. 2015 о 19:50 Sebastian Kalinowski skalinow...@mirantis.com
написав(ла):
Indeed, great news!
I would only suggest to wait a little bit more that a few days with
switching
to the voting mode since
+1
2015-06-30 10:38 GMT+02:00 Evgeniy L e...@mirantis.com:
+1
On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
+1. Alex's doing a great job!
On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko
svasile...@mirantis.com wrote:
+1
for clarification, in this case I think we
should follow plan C, new features should not slow us down
in migration from old to new version of the client.
On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:
2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin
2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com:
Hi Sheena,
Created ticket to change the structure of the directories [1].
And as far as I know any core can push tags into the repository,
Sebastian, Igor and I.
One correction: I'm not a core in fuel-plugins ;)
[1]
+1 for option 2)
But I have a question: how do we fit with this into the scope of Feature
Freeze and Soft Code Freeze this week?
Any ETAs?
2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh vkramsk...@mirantis.com:
FYI: There is Strict-Transport-Security
I agree here with Evgeniy. Even if it's not a trivial change, we cannot
leave a new API in such shape.
2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com:
Hi Igor,
I don't agree with you, some basic validation is essential part of
any handler and our API, currently it's easy to get
Andrew, thanks for this request and for the explanations.
+1 for this exception. The new generators are not conflicting with existing
ones, code is ready and tested so let's merge it.
2015-07-25 1:24 GMT+02:00 Andrew Woodward xar...@gmail.com:
I'm writing to ask for a FFE for landing the ceph
types of delimiters (it is regarding ERB
style template) but we have some more important issues.
Evgeniy, is your meaning to include those to FFE ?
Aleksey Kasatkin
On Fri, Jul 24, 2015 at 2:12 PM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:
I agree here with Evgeniy. Even if it's
I'm against getting rid of fuelmenu. As Alex wrote - we need to remember
who are the people that we are targeting.
We are adding multiple dialog windows with confirmations, warnings and
special way to do dangerous actions
(like environment deletion or reset), but in the same time we want to force
+1
2015-07-23 19:23 GMT+02:00 Dmitry Borodaenko dborodae...@mirantis.com:
+1
On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
+1
On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com
wrote:
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov
+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 it.
Thanks,
and task actions covered and even they
are not covered in 100%.
[1] http://paste.openstack.org/show/404439/
[2] http://paste.openstack.org/show/404440/
Thanks,
On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:
Hi folks,
For a some time in python-fuelclient
Hi folks,
For a some time in python-fuelclient we have two CLI apps: `fuel` and
`fuel2`. It was done as an implementation of blueprint [1].
Right now there is a situation where some new features are added just to
old `fuel`, some to just `fuel2`, some to both. We cannot simply switch
completely
+1 for this exception - as Evgeniy said it is developed not in the core but
in extension and risk is low.
2015-07-24 10:17 GMT+02:00 Evgeniy L e...@mirantis.com:
Hi,
If we have a rule that feature freeze exceptions should have essential
priority,
I'm not sure if it matters how risky it's,
2015-10-23 11:36 GMT+02:00 Igor Kalnitsky :
> 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
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 "new" to others.
There were no progress with moving old commands to new CLI and I didn't
seen plans to do so.
IMHO
2015-10-21 8:11 GMT+02:00 Mike Scherbakov :
>
> Simon is asking a valid request: if you add his folder in the file, he
> will be always added to the review request by script, once it's
> implemented. Only in the case when contribution is made to his particular
> area of
I've already wrote in the review that caused this thread that I do not want
to blindly follow rules for using one or another. We should always consider
technical requirements. And I do not see a reason to leave py.test (and
nobody
show me such reason) and replace it with something else.
+1
2015-09-03 21:34 GMT+02:00 Bartlomiej Piotrowski :
> I have no idea if I'm eligible to vote, but I'll do it anyway:
>
> +1
>
> Bartłomiej
>
> On Thu, Sep 3, 2015 at 9:16 PM, Sergey Vasilenko
> wrote:
>
>> +1
>>
>> /sv
>>
>>
+1
2015-09-14 22:37 GMT+02:00 Ivan Kliuk :
> +1
>
> On Mon, Sep 14, 2015 at 10:19 PM, Anastasia Urlapova <
> aurlap...@mirantis.com> wrote:
>
>> Folks,
>> I would like to nominate Denis Dmitriev[1] for fuel-qa/fuel-devops core.
>>
>> Dennis spent three months in Fuel BugFix
40 matches
Mail list logo