Re: [openstack-dev] [fuel] Fuel API settings reference

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 probab

Re: [openstack-dev] [Fuel] Pecan migration status

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. There i

[openstack-dev] [Fuel] Swagger documentation

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, filling

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

+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 > for fuel-web > core team. Julia's reviews are > always thor

Re: [openstack-dev] [Fuel] glusterfs plugin

`-- .gitkeep > | `-- ubuntu > | `-- .gitkeep > *`-- tasks.yaml > > > > 2015-04-02 17:01 GMT+03:00 Przemyslaw Kaminski <mailto:pkamin...@mirantis.com>>: > > Well then either we need to fix fuel-plugin-builder to accept such > situations. >

Re: [openstack-dev] [Fuel] glusterfs plugin

ronment_config.yaml > |-- metadata.yaml > |-- pre_build_hook > |-- repositories > | |-- centos > | `-- ubuntu > `-- tasks.yaml > > > > [1]. https://pypi.python.org/pypi/fuel-plugin-builder/1.0.2 > > > 2015-04-02 16:30 GMT+03:00 Przemyslaw Kaminski <

Re: [openstack-dev] [Fuel] glusterfs plugin

tos Apparently some files are missing from the git repo or the manifest is incorrect. Does anyone know something about this? P. [1] https://github.com/stackforge/fuel-plugin-cinder-netapp On 04/01/2015 03:48 PM, Przemyslaw Kaminski wrote: > Hello, > > I've been investigating bug [1]

Re: [openstack-dev] [Fuel] glusterfs plugin

viewer to 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 > mailto:pkamin...@mirantis.com>> wrote: > > Since there is no reply here I have taken steps to become core r

Re: [openstack-dev] [Fuel] glusterfs plugin

https://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] concentr

[openstack-dev] [Fuel] glusterfs plugin

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 othe

Re: [openstack-dev] [Fuel] fuel-dev-tools repo

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 > m

[openstack-dev] [Fuel] fuel-dev-tools repo

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.

Re: [openstack-dev] [Fuel] Pecan migration status

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 wor

[openstack-dev] [Fuel] Pecan migration status

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 just

Re: [openstack-dev] [Fuel] development tools

ew 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. >>>&

Re: [openstack-dev] [Fuel] development tools

ey could benefit from being used by broader audience. > > 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 > > >

[openstack-dev] [Fuel] development 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 though

Re: [openstack-dev] [Fuel] Deprecation warnings in python-fuelclient-6.1.*

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 wouldn't

[openstack-dev] [Fuel] Network verification status flag

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

Re: [openstack-dev] [Fuel] fake threads in tests

g it, some fake thread specific tests should be added to > make sure that it's not broken. > > Thanks, > > On Mon, Feb 16, 2015 at 2:54 PM, Przemyslaw Kaminski > mailto:pkamin...@mirantis.com>> wrote: > > Hello, > > This somehow relates to [1]: in integrati

Re: [openstack-dev] [Fuel] [UI] Sorting and filtering of node list

+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 s

Re: [openstack-dev] [Fuel] fake threads in tests

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 a

[openstack-dev] [Fuel] fake threads in tests

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 my

Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

On 02/09/2015 01:18 PM, Dmitriy Shulyak wrote: > > On Mon, Feb 9, 2015 at 1:35 PM, Przemyslaw Kaminski > 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: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

On 02/09/2015 12:06 PM, Dmitriy Shulyak wrote: > > On Mon, Feb 9, 2015 at 12:51 PM, Przemyslaw Kaminski > mailto:pkamin...@mirantis.com>> wrote: > > Well, there are some problems with this solution: 1. No 'pick > latest one with filtering to network_verify'

Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

On 02/07/2015 12:09 PM, Dmitriy Shulyak wrote: > > On Thu, Jan 15, 2015 at 6:20 PM, Vitaly Kramskikh > 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 of the most fr

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

p 2.6 we should 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 >>> wrote: >>> >>> For example >>> >&

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

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 08:

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

end http requests from monit, e.g for >>> creating notifications? I scanned through the docs and found >>> only alerts for sending mail, also where token (username/pass) >>> for monit will be stored? >>> >>> Or maybe there is another plan? without a

Re: [openstack-dev] [Fuel] Building Fuel plugins with UI part

5, 2014 at 3:30 PM, Przemyslaw Kaminski 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

Re: [openstack-dev] [Fuel] Building Fuel plugins with UI part

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 car

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

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: 2014-

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

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 thoug

Re: [openstack-dev] [Fuel] [Nailgun] Unit tests improvement meeting minutes

th swagger? On Mon, Dec 1, 2014 at 1:14 PM, Przemyslaw Kaminski mailto:pkamin...@mirantis.com>> 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`` t

Re: [openstack-dev] [Fuel] [Nailgun] Unit tests improvement meeting minutes

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 3)

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

t any api interaction On Thu, Nov 27, 2014 at 9:39 AM, Przemyslaw Kaminski 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 thi

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

. On Wed, Nov 26, 2014 at 6:22 PM, Przemyslaw Kaminski 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 master host (

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

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

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

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? Let's

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

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

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

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, November

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

integration 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 wrote:

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

m>> wrote: On 06 Nov 2014, at 12:20, Przemyslaw Kaminski 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 nee

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

.com/sensu On Wed, Nov 12, 2014 at 12:47 PM, Tomasz Napierala mailto:tnapier...@mirantis.com>> wrote: On 06 Nov 2014, at 12:20, Przemyslaw Kaminski mailto:pkamin...@mirantis.com>> wrote: > I didn't mean a robust monitoring system, just something simpler. Notific

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

hough, 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 mailto:pkamin...@mirantis.com>> wrote: I think we're missing the point here. What I meant

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

re rather reactive way of fixing problems. Zabbix 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 T

[openstack-dev] [Fuel] fuel master monitoring

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