Re: [openstack-dev] [Fuel] Getting rid of ISO

This is so awesome! Thanks! On Tue, Aug 16, 2016 at 4:30 PM Jay Pipes wrote: > On 08/16/2016 04:58 AM, Vladimir Kozhukalov wrote: > > Dear colleagues, > > > > We finally have working custom deployment job that deploys Fuel admin > > node using online RPM repositories (not

[openstack-dev] [Fuel] Deprecating old CLI in python-fuelclient

Fuelers, We are proud to announce that we finally managed to reach the point when the old CLI in python-fuelclient (aka the old Fuel Client) can be deprecated and replaced with fuel2 — a cliff based CLI. Support of the full set of commands that are required to operate Fuel was already

Re: [openstack-dev] [Fuel] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

Folks, It’s been several days when the entire python-fuelclient team is blocked by a broken CI job. Please make it non-voting ASAP. - romcheg > 8 серп. 2016 р. о 12:19 Roman Prykhodchenko <m...@romcheg.me> написав(ла): > > Vladimir, > > Thanks you for the update on t

Re: [openstack-dev] [Fuel] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

Vladimir, Thanks you for the update on this. Is there any ETA available? On Mon, Aug 8, 2016 at 12:09 PM Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > We are working on this. Will fix soon. > > Vladimir Kozhukalov > > On Mon, Aug 8, 2016 at 12:52 PM, R

Re: [openstack-dev] [Fuel] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

If it’s not possible to fix this job during next few hours, let’s mark in as non-voting until the bug(s) are fixed. > 8 серп. 2016 р. о 11:48 Roman Prykhodchenko <m...@romcheg.me> написав(ла): > > Folks, > > Since the end of last week > master.python-fuelclient.pkgs.u

[openstack-dev] [Fuel] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

Folks, Since the end of last week master.python-fuelclient.pkgs.ubuntu.review_fuel_client [1] blocks all patches to python-fuelclient. As logs suggest this issue is caused by the Xenial merge party. Please resolve the issue ASAP because some folks are blocked and cannot finish their jobs in

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

ntov...@mirantis.com>> wrote: > > A huge +1 > > > > On Mon, Jul 25, 2016 at 4:33 PM, Yegor Kotko <yko...@mirantis.com > > <mailto:yko...@mirantis.com>> wrote: > >> > >> +1 > >> > >> On Mon, Jul 25, 2016 at 3:19 PM, Roman Pryk

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

Hi Fuelers, Vitalii has been providing great code reviews and patches for some time. His recent commitment to help consolidating both old and new fuel clients and his bug-squashing activities show his willingness to step up and take responsibilities within the community. He can often be found

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

Hi Fuelers, Vitalii has been providing great code reviews and patches for some time. His recent commitment to help consolidating both old and new fuel clients and his bug-squashing activities show his willingness to step up and take responsibilities within the community. He can often be found

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

Since Fuel is a part of OpenStack now, should we rename #fuel to #openstack-fuel? - romcheg > 24 черв. 2016 р. о 18:49 Andrew Woodward написав(ла): > > There is also #fuel-devops > > I never liked having all the channels, so +1 > > On Fri, Jun 24, 2016 at 4:25 AM Anastasia

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

A big +1 > 23 черв. 2016 р. о 14:59 Bulat Gaifullin > написав(ла): > > Totally agree with this decision. > > Vladimir, thank you for driving this activity. > > Regards, > Bulat Gaifullin > Mirantis Inc. > > > >> On 23 Jun 2016, at 13:31, Vladimir Kozhukalov

[openstack-dev] [Fuel] Storing deployment configuration before or after a successful deployment

Folks, Recently we were investigating an issue [1] when a user configured a cluster to cause deployment to fail and then expected a discard button will allow to reset changes made after that failure. As Julia mentioned in her comment on the bug, basically what we’ve got is that users actually

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

The only thing I would like to mention here is that scripts for making automatic releases on PyPi using OpenStack Infra won’t work, if the version is not formatted according to semver. - romcheg > 24 трав. 2016 р. о 14:34 Igor Kalnitsky написав(ла): > > Hey Zigo, >

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

Jeremy, Thanks for checking! Probably that is missing in the the release checklist. - romcheg > 26 квіт. 2016 р. о 17:35 Jeremy Stanley <fu...@yuggoth.org> написав(ла): > > On 2016-04-26 17:29:40 +0200 (+0200), Roman Prykhodchenko wrote: >> I still don’t see python-fue

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

I still don’t see python-fuelclient-9.0.0 on PyPi: https://pypi.python.org/pypi/python-fuelclient Shouldn’t someone investigate this? > 25 квіт. 2016 р. о 18:33 Daniele Pizzolli > написав(ла): > > On Mon, Apr

[openstack-dev] [Fuel] CI may be broken for about 2 hours

to the new ISO We anticipate the whole process to take about 2 hours. References: 1. https://review.openstack.org/#/c/295731/2 2. https://review.openstack.org/#/c/295737/1 - romcheg > 31 бер. 2016 р. о 14:15 Roman Prykhodchenko <m...@romcheg.me> написав(ла): > > Folks, >

[openstack-dev] [Fuel][Swarm blocker] Release data contain liberty name on mitaka packages

Folks, There is a bug that is tagged as a swarm blocker [1] and two patches that fix it. One of them is for nailgun [2] and another one is for fuel-library [3]. The reason I write here is that those patches seem to fix the issue but they will never pass tests on the CI when they are tested

Re: [openstack-dev] [Fuel] New version of fuel-devops (2.9.20)

I’ve just tried to look up for fuel-devops on PyPi and found nothing. Let’s set up everything to let OpenStack CI release this package to PyPi and start publish releases there. Also it’s better to use openstack-announce to announce new releases. - romcheg > 31 бер. 2016 р. о 11:52 Dennis

Re: [openstack-dev] [Fuel] Extra red tape for filing bugs

We also often use bugtracker as a TODO tracker. This template does not work for TODOs at all. I understand that it’s not technically mandatory to follow it, but if that Fuel Bug Checker is going to spam on every single TODO, our inboxes will overflow. > 30 бер. 2016 р. о 17:37 Ro

[openstack-dev] [Fuel] Extra red tape for filing bugs

Guys, I’m not trying to be a foreteller but with a bug template this huge and complicated people will either not follow it or track bugs somewhere else. Perhaps we should make it simpler? Detailed bug description: Steps to reproduce: Expected results: Actual result: Reproducibility:

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

ty to extend diagnostic > recipes in usual (for them) way. What do you think? > > Thanks, > - Igor > > On Tue, Mar 29, 2016 at 7:52 PM, Roman Prykhodchenko <m...@romcheg.me> wrote: >> Please, propose your options here then: >> https://etherpad.openstack.

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

Please, propose your options here then: https://etherpad.openstack.org/p/shotgun-rename > 29 бер. 2016 р. о 18:15 Jay Pipes <jaypi...@gmail.com> написав(ла): > > On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote: >> Should we propose options and then arrange a poll? >

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

Should we propose options and then arrange a poll? > 29 бер. 2016 р. о 16:40 Neil Jerram написав(ла): > > On 29/03/16 15:17, Jay Pipes wrote: >> Hi! >> >> Once Shotgun is pulled out of Fuel, may I suggest renaming it to >> something different? I know in the past

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

> <https://bugs.launchpad.net/fuel/+bug/1553170> > Medium priority: > https://bugs.launchpad.net/fuel/+bug/1554546 > <https://bugs.launchpad.net/fuel/+bug/1554546> > https://bugs.launchpad.net/fuel/+bug/1539508 > <https://bugs.launchpad.net/fuel/+bug/1539508> >

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

Folks, We have been analyzing a bunch of random failures in Fuel tests and encountered several ones caused by detector raising errors occasionally [1]. After attempts to reproduce the same behavior have failed we’ve decided to run the same test suit on overloaded nodes. Those test-runs allowed

Re: [openstack-dev] [Fuel][Infra] Nailgun extensions testing

The idea is to write python (or shell) script which will: > - clone all required repos (like fuel-web, extensions repos) using > probably zuul-cloner Doesn’t nodepool automatically do that? > - checkout to appropriate stable branches / will cherry-pick some > commit / stay on master As far

[openstack-dev] [Fuel] Getting rid of cluster status

Fuelers, I would like to continue the series of "Getting rid of …" emails. This time I’d like to talk about statuses of clusters. The issues with that attribute is that it is not actually related to real world very much and represents nothing. A few month ago I proposed to make it more

Re: [openstack-dev] [Fuel] Rewriting nailgun agent on Python proposal

My opition on this is that we have too many re-invented wheels in Fuel and it’s better think about replacing them with something we can re-use than re-inventing them one more time. Let’s take a look at Ironic and try to figure out how we can use its features for the same purpose. - romcheg >

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

>>2016-03-11 22:00 GMT+03:00 Mike Scherbakov >> <mscherba...@mirantis.com <mailto:mscherba...@mirantis.com>>: >> >>Deprecation warning for Fuel >>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244. >&

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

>>> <mailto:ppe...@mirantis.com> <mailto:ppe...@mirantis.com >>>> <mailto:ppe...@mirantis.com>>> wrote: >>>>> Fuelers, >>>>> >>>>> As Simon said, we already have a log centralisation solution for MOS >>&

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

Fuelers, I remember we’ve discussing this topic in our couloirs before but I’d like to bring that discussion to a more official format. Let me state a few reasons to do this: - Log management code in Nailgun is overcomplicated - Working with logs on big scale deployments is barely possible

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

gt; > 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko <m...@romcheg.me > <mailto:m...@romcheg.me>>: > Whoops! I forgot to attach the link. Sorry! > > 1. http://i.imgur.com/8GaUtDq.png <http://i.imgur.com/8GaUtDq.png> > > > 9 лют. 2016 р. о 13:48 Roman Pryk

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

Hi fuelers! I’m not sure, if it’s my personal problem or the UX can be improved a little, but I’ve literary spend more than 5 minutes trying to figure out how to find a URL of Horizon. I’ve made a screenshot [1] and I suggest to add a full a link with the full URL in its test after "The

[openstack-dev] [Fuel] virtualenv fails with SSLError: [Errno 20] Not a directory

Folks, as some of you may have noticed, there is a high rate of job failures on Fuel CI in python-fuelclient. That happens because there are some weird issues with virtualenv utility not being able to create new virtual environments. I’ve tested that on my local environment and the problem

Re: [openstack-dev] [Fuel] virtualenv fails with SSLError: [Errno 20] Not a directory

. References: 1. https://ci.fuel-infra.org/job/verify-python-fuelclient/1324/console > 4 лют. 2016 р. о 15:50 Roman Prykhodchenko <m...@romcheg.me> написав(ла): > > Folks, > > as some of you may have noticed, there is a high rate of job failures on Fuel > CI in python-fuelclie

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

t; which order plugins will be selected). > > Moreover, it makes a little sense to try to resolve this situation. If > two plugins change something in core, they are probably incompatible. > Manual actions are required. > > So that's, basically, why I think we should warn user ab

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

as for tasks). > > > Aleksey Kasatkin > > > On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko <m...@romcheg.me > <mailto:m...@romcheg.me>> wrote: > Frankly, I have not though about how to deal with multiple plugins yet. > However, what I think is that

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

antis.com>> wrote: > +1 to overriding VIPs > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin <vkuk...@mirantis.com > <mailto:vkuk...@mirantis.com>> wrote: > +1 to o

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

Folks, currently merge policy for network roles only allows to add new VIPs to already existing roles [1]. If a plugin supplies a VIP with a name that already exists but with different parameters, Nailgun will not allow to do that. We faced a need to override configuration of several VIPs by

Re: [openstack-dev] [fuel] [fuelclient] Pre-release versions of fuelclient for testing purposes

Releasing a beta version sounds like a good plan but does OpenStack Infra actually support this? > 20 січ. 2016 р. о 12:05 Oleg Gelbukh написав(ла): > > Hi, > > Currently we're experiencing issues with Python dependencies of our package > (fuel-octane), specifically

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

I’d like to add that nova-network support was removed from python-fuelclient in 8.0. > 14 січ. 2016 р. о 17:54 Vitaly Kramskikh > написав(ла): > > Folks, > > We have a request on review which prohibits creating new envs with > nova-network:

Re: [openstack-dev] [Fuel] Different versions for different components

anch with 8.0 version and master with > 9.0, but there is still bugfixing in progress, so there might be > changes in stable/8.0 code. > > 3) On RTM day we finally create 8.0 tags on stable/8.0 branch, and > this is the time when we should release packages to PyPI and other > resources.

[openstack-dev] [Fuel] Different versions for different components

Folks, I can see that version for python-fuelclient package is already [1] set to 8.0.0. However, there’s still no corresponding tag and so the version was not released to PyPi. The question is it finally safe to tag different versions for different components? As for Fuel client we need to

[openstack-dev] [Fuel] Dropping Python 2.6

Fuelers, Since Mitaka OpenStack Infra has no resources to test python 2.6 support so the corresponding jobs are not running anymore. Since Fuel master node is on CentOS 7 now, let’s drop Python 2.6 support in Fuel. - romcheg signature.asc Description: Message signed with OpenPGP using

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

o.com/67521/openstack-dev-fuel-dropping-python2-6-compatibility > > <https://openstack.nimeyo.com/67521/openstack-dev-fuel-dropping-python2-6-compatibility> > > On Mon, Dec 14, 2015 at 5:05 PM, Roman Prykhodchenko <m...@romcheg.me > <mailto:m...@romcheg.me>> wrote

[openstack-dev] [Fuel] Important: Functional tests are back. Please rebase

Fuelers, for a long time functional tests in Fuel Client were not triggered by Fuel CI because of a pesky bug [1] in our tox.ini. The fix [2] for it was landed a few minutes ago. Since we don’t have gate jobs that trigger functional tests, I gently ask you to rebase your patches for Fuel

[openstack-dev] [Fuel] Private links

Folks, on the last two days I have marked several bugs as incomplete because they were referring to one or more private resources that are not accessible by anyone who does not have a @mirantis.com account. Please keep in mind that Fuel is an open source project and the

Re: [openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

...@mirantis.com>> wrote: > +1. > No doubts. ) > > > Aleksey Kasatkin > > > On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov <dpyz...@mirantis.com > <mailto:dpyz...@mirantis.com>> wrote: > Guys, > > I propose to promote Roman Prykhodchenko

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

Alexey, thank you for bringing this up. IMO discussing security problems is better to be done in a special kind of Launchpad bugs. - romcheg > 7 груд. 2015 р. о 17:36 Alexey Elagin написав(ла): > > Hello all, > > We have a security problem in Fuel 7.0. It's related to

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

Maciej, thanks for bringing this topic up for the discussion! I absolutely agree with the idea that at this point we have a problem with patch size. Patches that are too big usually have two major issues: they either don’t get reviewed for a very long time or get random +1s from people who

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

Following up on my previous email: Every blueprint specification has a Work items section. That section should describe granular work items, not just things in general. We should encourage components leads to put their attention to this aspect. > 7 груд. 2015 р. о 12:23 Roman Prykhodche

[openstack-dev] [Fuel] Important notice about running tests for python-fuelclient

Hi fulers! I’d like to let you know that because of the bug [1] in tox 2.2.1 we had to change [2] tox.ini temporarily to unlock the gate until the author of tox is working on the fix for the problem. Those changes in tox.ini revoke all freedom of configuring how tests on one’s local environment

Re: [openstack-dev] [Fuel] Important notice about running tests for python-fuelclient

e-toxini-config-files > > <https://bitbucket.org/hpk42/tox/issues/285/tox-220-breaks-some-toxini-config-files> > [2] https://review.openstack.org/#/c/247452/6 > <https://review.openstack.org/#/c/247452/6> > > On Mon, Nov 23, 2015 at 12:45 PM, Roman Prykhodchenko <m.

Re: [openstack-dev] [Fuel] Changing APIs and API versioning

troducing API versioning - maybe we have other > > things we should invest our resources to > > Estimate all the disadvantages this decision might have > > Fix all the issues in the current API (like this one) > > Implement API versioning support (yes, we don't have th

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

on step. The good fix in my opinion is to move this check > into network checker (perhaps keep it here either), but that > definitely shouldn't be done in 7.0. > > Thanks, > Igor > > > On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko <m...@romcheg.me > <m

[openstack-dev] [Fuel] Changing APIs and API versioning

Hi folks, I’d like to touch the aspect of Fuel development process that seems to be as wrong as possible. That aspect is how we change the API. The issue is that in Fuel anyone can change API at any point of time without even warning the rest of the same component’s team. Relying on this kind

Re: [openstack-dev] [Fuel] Assigning VIPs on network config serialization

. >> >> Once again - why? I agree, perhaps it would be useful, but there's no >> strict requirement on this and we should resolve our issues >> step-by-step. See my response above. >> >> >>> No, Again, this is too late. >> >> Too lat

Re: [openstack-dev] [Fuel] Assigning VIPs on network config serialization

should fail, if there's not enough VIPs or > other resources. So users fix them, and try again. > * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and > it's safe to return allocated VIPs on that stage. > > So what do you think guys? > > Thanks, > I

[openstack-dev] [Fuel] Assigning VIPs on network config serialization

Hi folks! I’ve been discussing several bugs [1-3] with some folks and noticed that they share the same root cause which is that network serialization fails, if there’s not enough IP addresses in all available ranges of one of the available networks to assign them to all VIPs. There are several

Re: [openstack-dev] [Fuel] Plugins related functionality in Fuel Client

Since there are already two services Fuel Client has to interact with, I filed a bug, for using service discovery: https://bugs.launchpad.net/fuel/+bug/1504471 > 9 жовт. 2015 р. о 11:25 Roman Prykhodchenko <m...@romcheg.me> написав(ла): > > In that case I would suggest to al

Re: [openstack-dev] [Fuel] Plugins related functionality in Fuel Client

Nailgun’s API to have a single entry point. > > I don't think that application such as Nailgun should be responsible for > proxying > requests, we solved similar problem for OSTF with adding proxy rule in Nginx. > > Thanks, > > On Fri, Oct 9, 2015 at 11:45 AM, Roman Pry

Re: [openstack-dev] [Fuel] Plugins related functionality in Fuel Client

ce, instead of adding it > to Nailgun. > > Thanks, > > On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko <m...@romcheg.me > <mailto:m...@romcheg.me>> wrote: > Folks, > > it’s time to speak about Fuel Plugins and the way they are managed. > > Currently

Re: [openstack-dev] [Fuel] py.test vs testrepository

https://review.openstack.org/#/c/227895/ - romcheg > 9 жовт. 2015 р. о 01:51 Roman Prykhodchenko <m...@romcheg.me> написав(ла): > > Folks, > > Since we’ve reached the consensus here I’d like to invite you to review the > patch [1] that replaces py.test with testr without making debugin

[openstack-dev] [Fuel] Plugins related functionality in Fuel Client

Folks, it’s time to speak about Fuel Plugins and the way they are managed. Currently we have some methods in Fuel Client that allow to install, remove and do some other things to plugins. Everything looks great except that functionality requires Fuel Client to be installed on a master node and

Re: [openstack-dev] [Fuel] py.test vs testrepository

://review.openstack.org/#/c/227895 - romcheg > 7 жовт. 2015 р. о 14:41 Roman Prykhodchenko <m...@romcheg.me> написав(ла): > > Michał, > > some comments in-line > >>> - testrepository and related components are used in OpenStack Infra >>> environment f

Re: [openstack-dev] [Fuel] py.test vs testrepository

components, e. g., Fuel Client, first and then try in in Nailgun. - romcheg > 7 жовт. 2015 р. о 02:06 Monty Taylor <mord...@inaugust.com> написав(ла): > > On 10/06/2015 06:01 PM, Thomas Goirand wrote: >> On 10/06/2015 01:14 PM, Yuriy Taraday wrote: >>> On Mon, Oct 5, 2015

Re: [openstack-dev] [Fuel] py.test vs testrepository

Yuri, sticking to global requirements and interacting deeper with OpenStack Infra are up-to-date objectives for Fuel and those are pretty much technical question. However, software development is not only solving technical tasks, it also incorporates interaction between people and other teams

Re: [openstack-dev] [Fuel] py.test vs testrepository

Michał, some comments in-line >> - testrepository and related components are used in OpenStack Infra >> environment for much more tasks than just running tests > > If by "more tasks" you mean parallel testing, py.test also has a > possibility to do that by pytest-xdist. As Monthy mentioned,

[openstack-dev] [Fuel] py.test vs testrepository

Disclaimer: I didn’t want to fire up this war but it silently hit one of my patches so now I think it’s better to spread it to a wide audience. When I was dealing with one of the regular dependency hell in Fuel Client I noticed, that stuff which is not in global requirements may make the

[openstack-dev] [Fuel] python-jobs now vote on Fuel Client

Good news folks! Since python jobs worked well on a number of patches, their mode was switched to voting. They were also added to the gate pipeline. - romcheg signature.asc Description: Message signed with OpenPGP using GPGMail

[openstack-dev] [Fuel] Number of IP addresses in a public network

Hi folks! Recently a problem that network check does not tell whether there’s enough IP addresses in a public network [1] was reported. That check is performed by CheckBeforeDeployment task, but there is two problems that happen because this verification is done that late: - A deployment

Re: [openstack-dev] [fuel] Branching strategy vs feature freeze

Dmitry, thank you for a well described plan. May I please ask you for a little TL;DR excerpt of what’s going to be changed, because I’m affraid some folks may get lost or may not have enough time to analyze it deeply (I actually see that happening but I won’t do fingerpointing :) ). -

[openstack-dev] [Fuel] fuel-dev-tools package is not published on PyPi

Folks, I can see fuel-dev-tools packaged registered on PyPi [1] but when I tried to install it, I got a message that pip could not find a version that satisfies the requirement. These utils are extremely useful and really help to avoid much pain while testing something on a live environment

Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs

...@mirantis.com написав(ла): If there will be 4-5 patches, then I do not have anything against it. I'm just skeptic that we will have so many ;) 2015-08-20 14:05 GMT+02:00 Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me: I think, that if there are 4-5 patches that pass python jobs

[openstack-dev] [Fuel] Changes to the blueprint specification template

Folks, as you may remember, we were about to merge some changes to the blueprint spec template to make our specifications in Fuel more specific regarding different components and subsystems. That time we decided to move the changes to 8.0, so new specs in 8.0 will have to follow the new

Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs

On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me wrote: Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible

Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs

all the code that uses six library for Python 2 3 compatibility. Best, Sebastian 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com mailto:bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman

[openstack-dev] [Fuel] Great updates to tests and CI jobs

Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible with the upstream CI. Besides sharing great news I think it’s necessary to share changes we had to do, in

[openstack-dev] [Fuel] Get rid of run_test.sh in Fuel Client

Hi Fuelers! I was working on enabling Python tests in Fuel Client to run on OpenStack CI and I figured out that we actually have a piece of legacy code which can be removed now. That piece is run_tests.sh file. For those who’s not aware, that script allows to run different tests under

Re: [openstack-dev] [Fuel] Release of python-fuelclient today

Привет, нет, обычный how to contribute. 31 лип. 2015 о 15:01 Roman Prykhodchenko m...@romcheg.me написав(ла): Folks, today I’m going to make a new public release of Fuel Client. If you badly need to merge something before that or have any objections, please let me know before 17:00 CEST

Re: [openstack-dev] [Fuel] Release of python-fuelclient today

Sorry, folks, I pressed a wrong button for replying. 31 лип. 2015 о 15:56 Roman Prykhodchenko m...@romcheg.me написав(ла): Привет, нет, обычный how to contribute. 31 лип. 2015 о 15:01 Roman Prykhodchenko m...@romcheg.me написав(ла): Folks, today I’m going to make a new public release

[openstack-dev] [Fuel] Release of python-fuelclient today

Folks, today I’m going to make a new public release of Fuel Client. If you badly need to merge something before that or have any objections, please let me know before 17:00 CEST (UTC+2). - romcheg signature.asc Description: Message signed with OpenPGP using GPGMail

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

+1 to merging the CLI part, if all our comments there are filed as High priority bugs and then fixed ASAP - romcheg 24 лип. 2015 о 07:58 Mike Scherbakov mscherba...@mirantis.com написав(ла): Colleagues, it sounds like we need to complete what was requested by Julia here (and it would

[openstack-dev] [Fuel] python-fuelclient-6.1.2

Folks, I’m glad to announse that verison 6.1.2 of Fuel Client was released. The team fixed a few important issues in order to make it possible to interact with Fuel 6.1 using the official client. CHANGELOG === 6.1.2 --- * Change version to 6.1.2 * Update link to developers'

Re: [openstack-dev] [Fuel] Improvement of the blueprint specs template

Guys, I’d like to ask all Fuel component leads to take a look at the proposed changes and check whether all important sections were added. - romcheg 18 черв. 2015 о 13:14 Roman Prykhodchenko m...@romcheg.me написав(ла): I realize, that discussing this topic in the email is hard. I filed

Re: [openstack-dev] [Fuel] Improvement of the blueprint specs template

I realize, that discussing this topic in the email is hard. I filed a review request with some changes to the template and invite you folks to take a look at that: https://review.openstack.org/193070 https://review.openstack.org/193070 16 черв. 2015 о 17:08 Roman Prykhodchenko m

[openstack-dev] [Fuel] Improvement of the blueprint specs template

Hi folks! I was reviewing one of specs for Fuel 7.0 and realized the information there is messed up and it’s pretty hard to put it all together. The reason for that is basically that Fuel is a multicomponent project but the template does not consider that — there is a Proposed change section

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

then an element of data model? Or that's exactly the complexity you want to get rid of? -- Best regards, Oleg Gelbukh On Tue, May 26, 2015 at 4:16 PM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me wrote: Oleg, Aleksander also proposed a nice proposed a nice solution [1

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

will implement it. Aleksey Kasatkin On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me wrote: Hi folks! Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

, it would be enough if environment was set to 'operational' when all nodes in it become 'ready', no matter how they were deployed (i.e. via Web UI or CLI). -- Best regards, Oleg Gelbukh On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me wrote: Hi

Re: [openstack-dev] [Fuel] python-fuelclient 6.1.0 is released

. Could you please elaborate on backwards compatibility between the new client and older versions of Fuel API? For example, is it possible to use the new client to work with Fuel 4.x? 5.x? -- Best regards, Oleg Gelbukh On Fri, May 15, 2015 at 5:39 PM, Roman Prykhodchenko m...@romcheg.me

[openstack-dev] [Fuel] Setting cluster status when provisioning a node

Hi folks! Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node is started using the command line client. The background for that issue is that the provisioning task does not seem to update the cluster status

[openstack-dev] [Fuel] Setting cluster status when provisioning a node

Hi folks! Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node is started using the command line client. The background for that issue is that the provisioning task does not seem to update the cluster status

[openstack-dev] [Fuel] python-fuelclient 6.1.0 is released

Hi folks! I’m glad to announce that the first independent release of Fuel Client was published to PyPi: https://pypi.python.org/pypi/python-fuelclient https://pypi.python.org/pypi/python-fuelclient You can either download it from the web page or install with pip install python-fuelclient.

[openstack-dev] [Fuel] Transaction scheme

Hi folks! Recently I faced a pretty sad fact that in Nailgun there’s no common approach to manage transactions. There are commits and flushes in random places of the code and it used to work somehow just because it was all synchronous. However, after just a few of the subcomponents have been

Re: [openstack-dev] [Fuel] PEP8 issues in Fuel-Web repo

This is also relevant for python-fuelclient. 6 квіт. 2015 о 12:27 Nikolay Markov nmar...@mirantis.com написав(ла): Hello everyone, I know this is really low priority and so on, but here is this bug about moving to the newest version of hacking package:

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

partially fixes this issue. The only thing I’d like to add to that scheme is this: - Add a CI jod that on daily basis checks whether python-requirements are in line with the requirements in RPM specs. - romcheg 26 бер. 2015 о 12:07 Roman Prykhodchenko m...@romcheg.me написав(ла): So guys, I

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

IIRC in this thread we agreed to use separate core groups for different repositories http://lists.openstack.org/pipermail/openstack-dev/2015-January/055111.html http://lists.openstack.org/pipermail/openstack-dev/2015-January/055111.html Why not follow that approach in this case? 27 бер. 2015

[openstack-dev] [Fuel] Version bump in the beginning of a release cycle

Hi folks, This end of the release cycle I realized that due to different reasons bumping a version of Fuel’s components takes much more than just updating a set of text files. In fact it causes different kinds of cross-component problems which of course must be fixed. This email is not about

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

:16 PM, Roman Prykhodchenko m...@romcheg.me wrote: Folks, I assume you meant: If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from *Fuel* Requirements». Exactly. I'm not sure it's good idea. We should stay so close

  1   2   >