Well, I suggest continuing
https://review.openstack.org/#/c/179051/
It basically requires to update docstrings of handler functions
according to [1]. This way the documentation is as close to the code as
possible.
With some work one could add automatic generation of docs out of
JSONSchema
Ping with [1] as additional argument for migrating.
[1]
https://openstack.nimeyo.com/43700/openstack-keystone-rehashing-pecan-falcon-other-wsgi-debate?qa_q=rehashing+pecan
P.
On 03/24/2015 09:09 AM, Przemyslaw Kaminski wrote:
BTW, old urls do not match as yet exactly the new ones
Hello,
I prepared a small PoC of Swagger [1] as a proposal to [2]. If you want
to test it out, checkout that commit into your repo, start Nailgun
locally and point your browser to [3]. Basically you just need to put
Swagger-UI [4] somewhere and point your browser to /dist/index.html
there,
+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
https://github.com/stackforge/fuel-web core team. Julia's reviews are
always thorough and
://review.openstack.org/#/admin/projects/stackforge/fuel-plugin-external-nfs,access
[4]
https://review.openstack.org/#/admin/projects/stackforge/fuel-plugin-cinder-netapp,access
On 04/01/2015 03:48 PM, Przemyslaw Kaminski wrote:
Hello,
I've been investigating bug [1] concentrating on the
fuel-plugin
-glusterfs as long as
seems than I was only one person who push some commits to it.
On Thu, Apr 2, 2015 at 10:47 AM, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
Since there is no reply here I have taken steps to become core reviewer
of the (orphaned
://github.com/stackforge/fuel-plugin-cinder-netapp
On 04/01/2015 03:48 PM, Przemyslaw Kaminski wrote:
Hello,
I've been investigating bug [1] concentrating on the
fuel-plugin-external-glusterfs.
First of all: [2] there are no core reviewers for Gerrit for this repo
so even if there was a patch
-plugin-builder/1.0.2
2015-04-02 16:30 GMT+03:00 Przemyslaw Kaminski pkamin...@mirantis.com
mailto:pkamin...@mirantis.com:
Investigating the cinder-netapp plugin [1] (a 'certified' one) shows
fuel-plugin-build error:
(fuel)vagrant@ubuntu-14:/sources/fuel-plugin-cinder-netapp
2015-04-02 17:01 GMT+03:00 Przemyslaw Kaminski pkamin...@mirantis.com
mailto:pkamin...@mirantis.com:
Well then either we need to fix fuel-plugin-builder to accept such
situations.
Actually it is an issue with fpb since git does not accepty empty
directories [1] so pulling
Hello,
I've been investigating bug [1] concentrating on the
fuel-plugin-external-glusterfs.
First of all: [2] there are no core reviewers for Gerrit for this repo
so even if there was a patch to fix [1] no one could merge it. I saw
also fuel-plugin-external-nfs -- same issue, haven't checked
Hello,
In accordance with the consensus that was reached on the ML I've set up
the fuel-dev-tools repository [1]. It will be the target repo to merge
my 2 private repos [2] and [3] (I don't think it's necessary to set up 2
different repos for this now). The core reviewers are the fuel-core
group.
Sorry, I meant
[2] https://github.com/CGenie/fuel-utils/
P.
On 03/27/2015 08:34 AM, Przemyslaw Kaminski wrote:
Hello,
In accordance with the consensus that was reached on the ML I've set up
the fuel-dev-tools repository [1]. It will be the target repo to merge
my 2 private repos [2
Hello,
I want to summarize work I've done in spare time on migrating our API to
Pecan [1]. This is partially based on previous Nicolay's work [2]. One
test is still failing there but it's some DB lock and I'm not 100% sure
that this is caused because something is yet not done on Pecan side or
BTW, old urls do not match as yet exactly the new ones. There is a need
to write a test that will check all urls.py list and compare with new
handlers' urls to make sure nothing was missed.
P.
On 03/24/2015 08:46 AM, Przemyslaw Kaminski wrote:
Hello,
I want to summarize work I've done
.
Same for vagrant configuration - if it's useful (and it is
since newcomers are using them) we could at least move under
Mirantis organization on Github.
Best,
Seabastian
2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com:
Hello,
Some time ago I wrote some small tools
Hello,
Some time ago I wrote some small tools that make Fuel development easier
and it was suggested to add info about them to the documentation --
here's the review link [1].
Evgenyi Li correctly pointed out that we already have something like
fuel_development already in fuel-web. I think
for vagrant configuration - if it's useful (and it is
since newcomers are using them) we could at least move under
Mirantis organization on Github.
Best,
Seabastian
2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com
Maybe add a Changelog in the repo and maintain it?
http://keepachangelog.com/
Option #2 is OK but it can cause pain when testing -- upon each fresh
installation from ISO we would get that message and it might break some
tests though that is fixable. Option #3 is OK too. #1 is worst and I
Hello,
Recently I've been asked to implement Python side of a simple feature:
before deployment tell the UI user that network verification for current
cluster configuration has not been performed. Moreover, on the UI side
it's possible to do network checking on usaved cluster data -- in that
case
sure that it's not broken.
Thanks,
On Mon, Feb 16, 2015 at 2:54 PM, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
Hello,
This somehow relates to [1]: in integration tests we have a class
called FakeThread. It is responsible for spawning threads
+1 for that, it should be done with pagination too. IMHO pagination
simple filtering by object's status can be done generically on the API
side for all GET methods that derive from CollectionHandler.
P.
On 02/17/2015 10:18 AM, Lukasz Oles wrote:
Hello Julia,
I think node filtering and
On 02/16/2015 01:55 PM, Jay Pipes wrote:
On 02/16/2015 06:54 AM, Przemyslaw Kaminski wrote:
Hello,
This somehow relates to [1]: in integration tests we have a
class called FakeThread. It is responsible for spawning threads
to simulate asynchronous tasks in fake env
Hello,
This somehow relates to [1]: in integration tests we have a class
called FakeThread. It is responsible for spawning threads to simulate
asynchronous tasks in fake env. In BaseIntegrationTest class we have a
method called _wait_for_threads that waits for all fake threads to
terminate.
In
On 02/07/2015 12:09 PM, Dmitriy Shulyak wrote:
On Thu, Jan 15, 2015 at 6:20 PM, Vitaly Kramskikh
vkramsk...@mirantis.com mailto:vkramsk...@mirantis.com wrote:
I want to discuss possibility to add network verification status
field for environments. There are 2 reasons for this:
1) One
On 02/09/2015 12:06 PM, Dmitriy Shulyak wrote:
On Mon, Feb 9, 2015 at 12:51 PM, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
Well, there are some problems with this solution: 1. No 'pick
latest one with filtering to network_verify' handler is available
On 02/09/2015 01:18 PM, Dmitriy Shulyak wrote:
On Mon, Feb 9, 2015 at 1:35 PM, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
Well i think there should be finished_at field anyway, why not
to add it for this purpose?
So you're suggesting to add
stick to it also.
P.
On 01/14/2015 08:32 AM, Bartłomiej Piotrowski wrote:
On 01/13/2015 11:16 PM, Tomasz Napierala wrote:
On 13 Jan 2015, at 10:51, Przemyslaw Kaminski
pkamin...@mirantis.com wrote:
For example
https://www.python.org/download/releases/2.6.9/
All official maintenance
For example
https://www.python.org/download/releases/2.6.9/
All official maintenance for Python 2.6, including security patches,
has ended.
https://hg.python.org/cpython/raw-file/v2.7.9/Misc/NEWS
Especially the SSL stuff is interesting
http://bugs.python.org/issue22935
P.
On 01/13/2015
? without any api interaction
On Thu, Nov 27, 2014 at 9:39 AM, Przemyslaw Kaminski
pkamin...@mirantis.com wrote:
This I didn't know. It's true in fact, I checked the
manifests. Though monit is not deployed yet because of lack
of packages in Fuel ISO. Anyways, I think the argument about
using
First of all, compiling of statics shouldn't be a required step. No one
does this during development.
For production-ready plugins, the compiled files should already be
included in the GitHub repos and installation of plugin should just be a
matter of downloading it. The API should then take
at 3:30 PM, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
First of all, compiling of statics shouldn't be a required step.
No one does this during development.
For production-ready plugins, the compiled files should already be
included in the GitHub
The only useful paradigm to write in Flask is MethodView's for me [1]
because decorators seem hard to refactor for large projects. Please look
at adding URLs -- one has to additionally specify methods to match those
from the MethodView -- this is code duplication and looks ugly.
It seems
Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as
instance attributes just like in [1] but it's more of taste I guess.
[1]
http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request
P.
On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote:
On 11/28/2014 05:15 PM, Ivan Kliuk wrote:
Hi, team!
Let me please present ideas collected during the unit tests
improvement meeting:
1) Rename class ``Environment`` to something more descriptive
2) Remove hardcoded self.clusters[0], e.t.c from ``Environment``.
Let's use parameters instead
api interaction
On Thu, Nov 27, 2014 at 9:39 AM, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
This I didn't know. It's true in fact, I checked the manifests.
Though monit is not deployed yet because of lack of packages in
Fuel ISO. Anyways, I think
I agree, this was supposed to be small.
P.
On 11/26/2014 11:03 AM, Stanislaw Bogatkin wrote:
Hi all,
As I understand, we just need to monitoring one node - Fuel master.
For slave nodes we already have a solution - zabbix.
So, in that case why we need some complicated stuff like monasca?
We want to monitor Fuel master node while Zabbix is only on slave nodes
and not on master. The monitoring service is supposed to be installed on
Fuel master host (not inside a Docker container) and provide basic info
about free disk space, etc.
P.
On 11/26/2014 02:58 PM, Jay Pipes wrote:
On
.
On Wed, Nov 26, 2014 at 6:22 PM, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
We want to monitor Fuel master node while Zabbix is only on
slave nodes and not on master. The monitoring service is
supposed to be installed on Fuel
I proposed monasca-agent in a previous mail in this thread.
P.
On 11/21/2014 04:48 PM, Fox, Kevin M wrote:
How about this?
https://wiki.openstack.org/wiki/Monasca
Kevin *
*
*From:* Dmitriy Shulyak
*Sent:* Friday,
And it all started out with simple free disk space monitoring :)
I created a document
https://etherpad.openstack.org/p/fuel-master-monitoring
Let's write what exactly we want to monitor and what actions to take.
Then it would be easier to decide which system we want.
P.
On 11/24/2014 04:32
Napierala
tnapier...@mirantis.com mailto:tnapier...@mirantis.com wrote:
On 06 Nov 2014, at 12:20, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
I didn't mean a robust monitoring system, just something
simpler. Notifications is a good idea
...@mirantis.com wrote:
On 06 Nov 2014, at 12:20, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
I didn't mean a robust monitoring system, just something
simpler. Notifications is a good idea for FuelWeb.
I’m all for that, but if we add it, we need
with Fuel Web is a
nice-to-have (via AMQP perhaps), but anything that can solve our
out-of-disk scenario is ideal. I did my best to tune our logging and
logs rotation, but monitoring is the most sensible approach.
-Matthew
On Fri, Nov 21, 2014 at 12:21 PM, Przemyslaw Kaminski
pkamin
, it
is in no way the robust monitoring system. Forcing user to do
something on a regular basis is unlikely to work.
Anton
On Thu, Nov 6, 2014 at 11:55 AM, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:
I think we're missing the point here. What I meant
is quite good for
preventing failures that are predictable but for the abrupt
problems Zabbix just reports them 'post mortem'.
The only way to remove the single failure point is to implement
redundancy/HA
Anton
On Tue, Nov 4, 2014 at 6:26 PM, Przemyslaw Kaminski
pkamin
Hello,
In extension to my comment in this bug [1] I'd like to discuss the
possibility of adding Fuel master node monitoring. As I wrote in the
comment, when disk is full it might be already too late to perform any
action since for example Nailgun could be down because DB shut itself
down. So
46 matches
Mail list logo
