Re: [openstack-dev] [openstak-dev][Fuel] Not properly merged specifications

Hey Sergii, Yeah, I had a conversation with Dmitry B. and we have decided on the following points: * Component Leads (CLs) must ensure that specs are reviewed and +1 by SMEs * All CLs have to +1/+2 on every spec (even if it's almost unrelated to other components). * Iff spec has pluses from all c

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hey Vladimir, Thanks for your effort on doing this job. Unfortunately we have not so much time left and FF is coming, so I'm afraid it's become unreal to make it before FF. Especially if it takes 2-3 days to fix system tests. Andrew, I had the same opinion some time ago, but it was changed beca

Re: [openstack-dev] [Fuel] CentOS-7 Transition Plan

ocker removal). We agreed that Dmitry's feature is >>> much more complicated and of higher priority. So, Centos 7 should be merged >>> first and then I'll rebase my patches (mostly supervisor -> systemd). >>> >>> >>> >>> >>> >>> Vlad

Re: [openstack-dev] [Fuel] CentOS-7 Transition Plan

Hey Dmitry, Thank you for your effort. I believe it's a huge step forward that opens number of possibilities. > Every container runs systemd as PID 1 process instead of > supervisord or application / daemon. Taking into account that we're going to drop Docker containers, I think it was unnecessa

[openstack-dev] [Fuel] Approved but not implemented specs

Hey Fuelers, Today I noticed that some of Fuel specs have been merged for 7.0 while the features themselves weren't landed. It's kind confusing since it seems like the feature was implemented in 7.0 while it's not. What do you think guys about moving such specs into 8.0 folder? I believe it's a w

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

; >> > wrote: >> > > >> > > Hello, Igor. >> > > >> > > >But I'd like to hear from QA how do we rely on >> container-based >> > > infrastructure? Would it be hard to change our sys-tests

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hey guys, Despite the fact I like containers (as deployment unit), we don't use them so. That means I +1 idea to drop containers, just because I believe that would * simplify a lot of things * helps get rid of huge amount of hacks * increase master node deployment * release us from annoying suppo

Re: [openstack-dev] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

Hey Julia, Thank you for feedback. I took a look over the bug and here's my thoughts: * [1] Looks like Invalid to me. I'm not sure, but it looks like you VMs just wrongly configures. It's a pretty common mistake for VBox scripts. Did you use them? * [2] Partially Invalid. I left my comments, so I

Re: [openstack-dev] [Fuel] Deprecation of GRE network segmentation in Fuel 8.0

Hey Artem, > GRE network segmentation option has been deprecated for clusters > with Neutron since 7.0 release, both on UI and Library side What do you mean by "deprecated"? Was it removed? If so, why did we have a chance to create GRE if it wasn't supported? If so, we definitely have to forbid

Re: [openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

Folks, I have one thing to add: if workaround is unavoidable, please DO comment it. Usually workaround aren't obvious, and it would be incredibly helpful to comment all of them; and do not hesitate to write extensive comments. The clearer you write - the less time your colleagues will spend next

Re: [openstack-dev] [Fuel][fuel] How can I install Redhat-OSP using Fuel

Hey Fei LU, Thanks for being interested in Fuel. I'll help you with pleasure. First of all, as Vladimir mentioned, you need to create a new release. That's could be done by POST request to /api/v1/releases/. You can use JSON of CentOS with slight changes. When releases is created you need to do t

Re: [openstack-dev] [Fuel] Default PostgreSQL server encoding is 'ascii'

Hello, Yeah, that's true. There shouldn't be any VBox specific hacks, and I believe PostgreSQL uses locale's encoding by default (which is ASCII in containers). Well, basically the bug should be assigned on library team - we should specify UTF-8 explicitly in PostgreSQL config, since Nailgun work

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Hi Javeria, Try to use 'master' in 'role' field. Example: - role: 'master' stage: pre_deployment type: shell parameters: cmd: echo all > /tmp/plugin.all timeout: 42 Let me know if you need additional help. Thanks, Igor P.S: Since Fuel 7.0 it's recommen

Re: [openstack-dev] [Fuel] Change VIP address via API

Hey Aleksey, I agree that we need a separate API call for VIP allocation, thought I don't agree on some points you have proposed. See my comments below. > use PUT to change VIPs addresses (set them manually or request > to allocate them automatically) PUT requests SHOULD NOT be used for VIP allo

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

Hi all, > Just a small note, we shouldn't remove it completely from Nailgun > codebase, because we still have old environments to support, How many releases we should wait before nova-network completely? AFAIK, it was deprecated since 6.1.. and it was kept in 7.0 only for VCenter case. If so, may

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

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 have so many things to reconsider and to fix that it'd require a huge effort to m

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

'd propose to add a handler for allocation of VIPs if VIPs can be useful > before deployment. > I'm not sure what are the cases. > > > > Aleksey Kasatkin > > > On Wed, Oct 21, 2015 at 11:45 AM, Roman Prykhodchenko wrote: >> >> Then we should close [1] as inv

Re: [openstack-dev] [Fuel] Modularization activity POC

package those - will you create RPM package for each, >>> as well as Docker container (as we have everything in containers on Fuel >>> master node) >>> >>> These questions, of course, should be covered in spec - so may be I >>> should just wait for you gu

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

roles? > > On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky > wrote: >> >> Hi Dmitry, >> >> > Insert required metadata into roles that relies on another roles, for >> > compute it will be something like: >> > >> > compute: >> &

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

Hi Dmitry, > Insert required metadata into roles that relies on another roles, for > compute it will be something like: > > compute: > requires: controller > 1 Yeah, that's actually what I was thinking about when I wrote: > Or should we improve it somehow so it would work for one nod

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

Hey Mike, AFAIK, there's no bug/blueprint on LP. The question I want to raise here is what will happen if I decide to deploy a cluster with one compute without controllers? It looks like a bad UX to me, though it may increase speed of CI gates where one node with one role is enough. Can we ignor

Re: [openstack-dev] [Fuel] fuelmenu code freeze

Hey Vladimir, That's awesome news. I blocked all fuelmenu patches [1] with a link to this thread. So don't worry, we won't merge them accidentally. BTW, could you provide any ETA when moving will be done? [1] https://review.openstack.org/#/q/project:openstack/fuel-web+file:%255Efuelmenu.*+statu

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

Roman, > This behavior is actually described in [1]. Should we allocate > VIPs on network check as well? No, we shouldn't. We should check whether it's enough IPs for nodes / VIPs with current network configuration, but no more. - igor On Tue, Oct 20, 2015 at 4:54 PM, Igor

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

s actually described in [1]. Should we allocate VIPs on > network check as well? > > > 1. https://bugs.launchpad.net/fuel/+bug/1487996 > > > - romcheg > > >> 19 жовт. 2015 р. о 18:28 Igor Kalnitsky >> написав(ла): >> >> Hi Roman, >> >>&

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

ckBeforeDeployment task > separately (only within ApplyChanges for now). It will help the user to > diagnose different problems. It seems to be a subject for another > discussion/ticket though. > > Thanks, > > > > > Aleksey Kasatkin > > > On Mon, Oc

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

Hi Roman, > Not assign addresses to VIPs is a network configuration is being > serialized for API output. AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP. So we can keep only *public* VIP, and do not assign / show others. > Check number of IP addresses wherever it is possib

Re: [openstack-dev] [Fuel] Modularization activity POC

Hey Evgeniy. This is awesome news1 I believe that microservices is way to go. Despite the fact that them bring a set of classical problems (e.g. duplication of domain entities) we will win more than loose. :) If there will be any specs or design meetings, please send me invite - I'd gladly join d

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

loser term seems to be >>> 'liberty-8.0' version. It does not to break comparisons that exist in the >>> code and allows for smooth transition. >>> >>> -- >>> Best regards, >>> Oleg Gelbukh >>> >>> On Fri, Oct 16, 201

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

15-May/065144.html > [2] > https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases > > -- > Best regards, > Oleg Gelbukh > > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky > wrote: >> >> Oleg, >> >> Yes, I know. St

Re: [openstack-dev] [Fuel] Proposal to freeze old Fuel CLI

+1 to Sebastian. On Wed, Oct 14, 2015 at 12:13 PM, Sebastian Kalinowski wrote: > 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 w

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

7;. > > -- > Best regards, > Oleg Gelbukh > > On Fri, Oct 16, 2015 at 12:45 PM, Igor Kalnitsky > wrote: >> >> Hey Oleg, >> >> I've read the post [1] and I didn't get how exactly minor releases of >> *stable* branch will be versio

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

Hey Oleg, I've read the post [1] and I didn't get how exactly minor releases of *stable* branch will be versioned? Let's say 2015.2.0 is Liberty. How 2015.2.1 will be versioned? [1] http://ttx.re/new-versioning.html Thanks, Igor On Thu, Oct 15, 2015 at 6:59 PM, Oleg Gelbukh wrote: > Hello, >

[openstack-dev] [fuel] fuel-python lead candidacy

Hey everyone, I'd like to announce my candidacy for fuel-python component lead position. I've been working on the Nailgun project for year and half now, as one of regular contributor. Last fall I became a core reviewer, and since then I'm doing my best to help others to land their patches and to

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

Hey Roman, > It’s ”standard" in OpenStack so using it gives Fuel more karma > and moves it more under big tent As far as I understand it doesn't affect our movement under big tent. > It’s in global requirements, so it doesn’t cause dependency hell Honestly I have no idea how py.test caused a de

Re: [openstack-dev] [fuel][shotgun] do we still use subs?

Hey Alex, I'm +1 for removal. I don't thing shotgun should be responsible for log sanitizing, because sensitive data shouldn't get to the logs at the first place. Thanks, Igor On Wed, Sep 30, 2015 at 4:05 PM, Alexander Gordeev wrote: > Hello fuelers, > > My question is related to shotgun tool[1

Re: [openstack-dev] [fuel] PTL & Component Leads elections

> * September 29 - October 8: PTL elections So, it's in progress. Where I can vote? I didn't receive any emails. On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala wrote: >> On 18 Sep 2015, at 04:39, Sergey Lukjanov wrote: >> >> >> Time line: >> >> PTL elections >> * September 18 - September 28,

[openstack-dev] [Fuel] [Plugins] Fuel Plugin Builder 3.0.0 released

Hello fuelers, I want to announce that FPB (fuel plugin builder) v3.0.0 has been released on PyPI [1]. New package version "3.0.0" includes the following features: - New `node_roles.yaml` file that allows to add new node roles. - New `volumes.yaml` file that allows to add new volumes and/or defi

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

s if they are stupid are not. We are > working for our users, not vice versa. > > On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky > wrote: >> >> Mike, >> >> > still not exactly true for some large enterprises. Due to all the >> > security, etc., >

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

on people want offline deployment feature is not because of poor >> connection, but rather the enterprise intranets where getting subnet with >> external access sometimes is a real pain in various body parts. >> >> -- >> Best regards, >> Oleg Gelbukh >> >>

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Hello, I agree with Vladimir - the idea of online repos is a right way to move. In 2015 I believe we can ignore this "poor Internet connection" reason, and simplify both Fuel and UX. Moreover, take a look at Linux distributives - most of them fetch needed packages from the Internet during installa

Re: [openstack-dev] [Fuel][Plugins] request for update of fuel-plugin-builder on pypi

Hi guys, I'm going to wait for the patch [1] and then make a FPB release. Regarding repo restructuring.. We do have an issue, and IIRC it's targeted to 8.0. [1]: https://review.openstack.org/#/c/221434/ Thanks, Igor On Wed, Sep 9, 2015 at 2:23 PM, Swann Croiset wrote: > +2 to sergii > > and b

Re: [openstack-dev] [Fuel][Plugins] Deployment order with custom role

ented with plugin-custom-role feature. This is not about plugin-custom-role, this is about our task deployment framework. I heard there were some plans on its improvements. Regards, Igor On Mon, Sep 7, 2015 at 3:27 PM, Swann Croiset wrote: > > > On Mon, Sep 7, 2015 at 11:12 AM, Igor Kal

Re: [openstack-dev] [Fuel][Plugins] Deployment order with custom role

Hi Swann, > However, we still need deployment order between independent > plugins and it seems impossible to define the priorities There's no such things like priorities for now.. perhaps we can introduce some kind of anchors instead of priorities, but that's another story. Currently the only wa

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

hey are humans then? :) I can only speak for myself, and that's what I want to say: during 7.0 dev cycle I burned in hell and I don't want to continue that way. Thanks, Igor On Wed, Sep 2, 2015 at 3:14 PM, Jay Pipes wrote: > On 09/02/2015 03:00 AM, Igor Kalnitsky wrote: >> >

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

It won't work that way. You either busy on writing code / leading feature or doing review. It couldn't be combined effectively. Any context switch between activities requires an extra time to focus on. On Wed, Sep 2, 2015 at 5:46 AM, Tomasz Napierala wrote: >> On 01 Sep 2015

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

Hi folks, So basically.. * core reviewers won't be feature leads anymore * core reviewers won't be assigned to features (or at least not full-time) * core reviewers will spend time doing review and participate design meetings * core reviewers will spend time triaging bugs Is that correct? Thank

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

Hello, My 5 cents on it. I don't think it's really a High or Critical bug for 7.0. If there's not enough IPs the CheckBeforeDeploymentTask will fail. And that's actually Ok, it may fail by different reason without starting actual deployment (sending message to Astute). But I agree it's kinda str

Re: [openstack-dev] [Fuel] Fuel Project Specifications

Hi Alex, Finally we have it! Thank you. BTW, any chance to use upstream infra [1] for this purpose? [1] http://specs.openstack.org Thanks, Igor On Mon, Aug 10, 2015 at 6:11 PM, Alexander Charykov wrote: > Hello all. > > We have launched fuel specs service at [1] where you can read fuel > proje

Re: [openstack-dev] [Fuel][Plugins] Feedback

Ah, my mistake - yes, please push tags for all of the plugin builder > versions. > > -Original Message----- > From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] > Sent: Thursday, July 30, 2015 10:47 AM > To: OpenStack Development Mailing List (not for usage questions) > &

Re: [openstack-dev] [Fuel][Plugins] Feedback

want tags for any releases that have plugins > associated, or we are planning to have plugins associated (so, 6.0, 6.1, > 7.0). > > -Original Message- > From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] > Sent: Thursday, July 30, 2015 9:46 AM > To: OpenStack Developmen

Re: [openstack-dev] [Fuel][Plugins] Feedback

Hi Sheena, Sure, I can do it. Should I push tag only for last release or for all releases that are available on PyPI? Thanks, Igor On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson wrote: > So the only cores are Igor and Evgeniy? Can one of you add tags for the new > release versions? > > > > Fr

Re: [openstack-dev] [Fuel][CI] CI on commit message

Guys, How do you suppose to know that only commit message was changed? Do you want to implement manual comparison between patch sets?! Currently Gerrit checks whether patchset was changed or not by tracking Git commit SHA1 sum, and, btw, chaning commit message will lead to changing commit sha1 su

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

t; >>>>> 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 : >>>>>> >>>>>> Hi Igor, >>>>

Re: [openstack-dev] [fuel] FFE for bug/1475759 ceph generators

Hi folks, Andrew, the code looks safe to me and the only question I have what the point of this patch if it's unused? I mean the generators? Until you use them in cluster attributes (openstack.yaml) new generators are useless, and don't fix anything. Are you going to use them in 7.0 to fix some C

Re: [openstack-dev] [Fuel][Plugins] Plugins on separate launchpad projects

Hello Patrick, Thank you for raising this topic. I think that it'd be nice to create a separate projects for Fuel plugins if it wasn't done yet. Fuel plugins have different release cycles and do not share core group. So it makes pretty much sense to me to create separate projects. Otherwise, I ha

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L wrote: > Hi, > > Since the feature is essential, a

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

Hello, My 2 cents on it. Following plan C requires a huge effort from developer, and it may be unacceptable when FF is close and there're a lot of work to do. So it looks like the plan B is most convenient for us and eventually we will have all features in fuel2. Alternatively we can go with C..

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

livering on time with expected level of quality >>>> >>>> +390, -35 LOC also scare me a little bit, it's not a tiny change. >>>> >>>> One of the possible workarounds can be, if we deliver this patch after >>>> HCF, and have an updated

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

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, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich wrote: > Team, > > I would like to request an exception from the Feature Freeze for CLI change

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1. On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov wrote: > At the moment we have several core reviewers for the fuel-main project. > > Roman Vyalov is responsible for merging of infrastructure-related variables > and for the lists of packages. > I am responsible for merges in make system. And I

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

Hello, Here's my 2 cents on it. I think the effort we put to support fuelmenu doesn't worth it. I used to deploy fuel too often in previous release, and I never used features of fuelmenu? Why? Because I prefer to apply changes on already deployed node. Moreover, I don't like that users are prompt

[openstack-dev] [Fuel] [Plugins] Node role as a plugin is in master

Hi fuelers, I'm glad to announce that bp/role-as-a-plugin story [1] has been successfully implemented. Since yesterday all functional is in master, feel free to use it in your plugins. Briefly, now you are able.. * to define new node roles in the similar to openstack.yaml way with all supported

Re: [openstack-dev] [Fuel] Question about unique default hostname for node

Hi guys, @Sergii, it looks like you misunderstood something. `node-uuid` is not a general use case. It's only about conflicting nodes, and I'm sure everyone's going to change such a hostname in order to avoid confusion. @Andrew, a) Database refuses hostnames that break unique constraint, sot it'

Re: [openstack-dev] [Fuel] Question about unique default hostname for node

Hi Fedor, > Use 'node-{ID}-{#}' format, where {#} we'll chose in loop till the first > unique. I don't like this approach by many reasons. Here's some of them: * With a loop you're going to perform N SQL queries in order to check for uniqueness, and that's a bad design and it'd be better to avo

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

ywars as we are going to add our tests to Puppet > manifests projects. We'll be able to resolve fast enough. In case of > problems we can stick librarian to particular commit in upstream repo. > > > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC

Re: [openstack-dev] [Fuel] Aligning LP groups with real teams

Hello, Here's my +2 on this. :) BTW, any chance we can somehow to reduce spam emails when some bug was assigned to another team? For instance, I see email notifications when bug's assigned to fuel-library. Thanks, Igor On Fri, Jul 17, 2015 at 4:16 PM, Tatyana Leontovich wrote: > Hi, > > Alex v

Re: [openstack-dev] [Fuel] Nailgun agent core reviewers nomination

+1 On Fri, Jul 17, 2015 at 5:43 AM, Dmitry Borodaenko wrote: > +1 > > On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk > wrote: >> >> +1 >> >> -- >> Best regards, >> Sergii Golovatiuk, >> Skype #golserge >> IRC #holser >> >> On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov >> wrote: >>> >>>

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hello guys, > Update 'make iso' scripts: > * Make them use 'r10k' (or other tool) to download upstream modules based > on 'Puppetfile' I foreseen holywars with our Build team. AFAIK they are deeply concerned about Internet access during ISO build process. Hence, they'll propose to package upst

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

Hi, My 2 cents on it. Let's abandon patch: * if there's at least one -1, and there were no activity for 2 weeks * if it has positive feedback, bat there were no activity for 4 weeks Thanks, Igor On Wed, Jul 8, 2015 at 2:33 PM, Oleg Gelbukh wrote: > Given this is _inactivity_ timeout, 2 weeks

Re: [openstack-dev] [Fuel][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core

+1. Alex's doing a great job! On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko wrote: > +1 > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec

Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role - the spec is available

Hi Samuel, Here's my 2 cents on this topic. First of all, I'd like to ask you - what problem do you try to solve? Please, answer on that first because it'll help me to come back with solution. Currently it looks like an error-prone approach to apply nova-nfs tasks only on roles with some label. W

Re: [openstack-dev] [Fuel] Ceph Public Network Setting

Hello, That makes sense to me. Still, I want to point that we're going to implement advanced networking and with this feature you'll be able to assign every single network role to any network. That means, you'll be able to assign ceph network role to storage, management or whatever-you-want netw

Re: [openstack-dev] [Fuel] Packaged Fuel and "Feature Groups"

Hi, There are few places where 'feature_groups' is used by Nailgun to turn on/off some experimental stuff. For instance, if there's an 'experimental' word in the 'feature_groups' list then Nailgun will allow you to create new environments based on old releases. Thanks, Igor On Thu, Jun 18, 2015

Re: [openstack-dev] [Fuel] Transaction scheme

be split into independent units. > > I like the solution with sending tasks to Astute at the end of handler > execution. > > On Wed, May 6, 2015 at 12:57 PM, Igor Kalnitsky > wrote: >> >> > First of all I propose to wrap HTTP handlers by begin/commit/rollback >>

Re: [openstack-dev] [Fuel] Transaction scheme

> First of all I propose to wrap HTTP handlers by begin/commit/rollback I don't know what you are talking about, but we do wrap handlers in transaction for a long time. Here's the code https://github.com/stackforge/fuel-web/blob/2de3806128f398d192d7e31f4ca3af571afeb0b2/nailgun/nailgun/api/v1/handl

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

+1. Julia's doing good job. On Thu, Apr 30, 2015 at 12:33 PM, Przemyslaw Kaminski wrote: > +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 >>

Re: [openstack-dev] [Fuel] Infiniband support in Fuel

Hello, If all is ok, let's move bug to 7.0 and fix it with netaddr as it was proposed in comments to the ticket. - Igor On Wed, Apr 29, 2015 at 6:29 PM, Nikolay Markov wrote: > Hi everybody, does anybody besides Mellanox need this? If not and while > it's already solved issue for Mellanox itse

Re: [openstack-dev] [Fuel] removing single mode

Tomasz, multi-node mode is a legacy non-HA mode with only 1 controller. Currently, our so-called HA mode support deployment with 1 controller, so it makes no sense to support both modes. On Wed, Apr 15, 2015 at 6:38 PM, Tomasz Napierala wrote: > Do you mean single node? > >> On 15 Apr 2015, at 17

Re: [openstack-dev] [Fuel] Nominate Sebastian Kalinowski for fuel-web/python-fuelclient core

, Dmitry Pyzhov wrote: >> >> +1 >> >> On Mon, Apr 13, 2015 at 2:07 PM, Evgeniy L wrote: >>> >>> +1 >>> >>> On Fri, Apr 10, 2015 at 1:35 PM, Roman Prykhodchenko >>> wrote: >>>> >>>> +1. Sebast

Re: [openstack-dev] [Fuel] Several nominations for fuel project cores

Dmitry, 1/ +1 2/ +1 3/ +1 P.S: Dmitry, please send one mail per nomination next time. It's much easier to vote for each candidate in separate threads. =) Thanks, Igor On Mon, Apr 13, 2015 at 4:24 PM, Dmitry Pyzhov wrote: > Hi, > > 1) I want to nominate Vladimir Sharshov to fuel-astute core.

Re: [openstack-dev] [Fuel] Nominate Andrey Skedzinskiy for fuel-qa(devops) core

+1. On Mon, Apr 13, 2015 at 4:09 PM, Sergii Golovatiuk wrote: > Strong +1 > > Nastya forgot to mention Andey's participation in "Ubuntu 14.04" feature. > With Andrey's help the feature went smooth and easy ;) > > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Mon

Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

+1. She's doing great job! On Thu, Mar 26, 2015 at 6:09 AM, Sergii Golovatiuk wrote: > +1 > > > > Best Regards, > Sergii Golovatiuk > >> On 25 Mar 2015, at 12:10, Dmitry Borodaenko wrote: >> >> Fuelers, >> >> I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. >> She has contrib

Re: [openstack-dev] [Fuel] FFE python-fuelclient improvements

Yep, I think we can do merge them. +1 from my side. On Tue, Mar 17, 2015 at 12:50 PM, Evgeniy L wrote: > +1, because those patches are simple don't look destructive. > > On Mon, Mar 16, 2015 at 7:43 PM, Roman Prykhodchenko wrote: >> >> Hi folks, >> >> due to some technical issues we were unable

Re: [openstack-dev] [Fuel] Testing DB migrations

Hi, guys, Indeed, it's a hot topic since it looks like there's no silver bullet at all. As OpenStack community, we should move toward oslo.db approach, but it may require hard effort from our side. Meantime, as a part of bp/consume-external-ubuntu [1] I've prepared a base class for testing migrat

Re: [openstack-dev] [Fuel][Plugins] Fuel plugin builder tagging and pypi publishing

+1. On Fri, Feb 13, 2015 at 11:41 AM, Sebastian Kalinowski wrote: > +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 a

Re: [openstack-dev] [Fuel] Merge code before spec is merged?

Fuelers, I see no problems here. I think it's ok if some parts of feature were merged before the spec, because it means the feature is under development. Moreover, if we merge specs asap there's a chance that we'll miss something. Therefore, the chance that it will be found and discussed at the de

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

4 PM, Nikolay Markov wrote: > Igor, > > But why can't we implement it properly on the first try? It doesn't > seem like a hard task and won't take much time. > > On Wed, Jan 28, 2015 at 12:50 PM, Igor Kalnitsky > wrote: >> Nik, >> >>> I&#x

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

ll really help us to cver complex cases in the future. > > On Tue, Jan 27, 2015 at 10:52 AM, Mike Scherbakov > wrote: >> +1, I do not think it's usable as how it is now. Let's think though if we >> can come up with better idea how to show what has been changed (or even &g

Re: [openstack-dev] [Fuel] Getting rid of kickstart/preseed for all NEW releases

OpenStack releases which are defined in openstack.yaml. It is to be possible >> to install OS using kickstart for all currently available OpenStack >> releases. >> >> Vladimir Kozhukalov >> >> On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky >> wrote

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

+1 for removing attribute. @Evgeniy, I'm not sure that this attribute really shows all changes that's going to be done. On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L wrote: > To be more specific, +1 for removing this information from UI, not from > backend. > > On Mon, Jan 26, 2015 at 7:46 PM, Evge

Re: [openstack-dev] [Fuel] Getting rid of kickstart/preseed for all NEW releases

Just want to be sure I understand you correctly: do you propose to FORBID kickstart/preseed installation way in upcoming release at all? On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov wrote: > Subject is changed. > > Vladimir Kozhukalov > > On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukal

Re: [openstack-dev] [Fuel] Core rights in Fuel repositories

+1, no objections from my side. On Fri, Jan 23, 2015 at 6:04 PM, Roman Prykhodchenko wrote: > Hi folks! > > After moving python-fuelclient to its own repo some of you started asking a > good question which is How do we manage core rights in different Fuel > repositories. The problem is that the

Re: [openstack-dev] [Fuel]When will fuel support centos 7?

Hi, Yes, we do have a plan for CentOS 7, but as far as I know it was postponed to MOS 7.0. That means we will not have Cent OS 7 in upcoming release. - Igor On Thu, Jan 15, 2015 at 1:16 PM, me,apporc wrote: > Hi, > > Do we have plan for centos 7 ? > > > > Regards, > > apporc > > > _

Re: [openstack-dev] [fuel][client] new client implementation ideas

Hi, Konstantin, Thank you for sharing ideas. Your "yet-one-more implementation of fuel-client" one more time confirms that currently we have completely unusable implementation. Just for your information: we have plans for python-fuelclient refactoring [1]. The main point of this blueprint is to p

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

Guys, The question not about "Do we want to drop 2.6 or not?". The question about "Do we have resources to do that in this release cycle?". It may be not as easy at it seems and it obviously requires additional testing. - Igor On Wed, Jan 14, 2015 at 11:18 AM, Przemyslaw Kaminski wrote: > I jus

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

Hi, Roman, Indeed, we have to go forward and drop python 2.6 support. That's how it supposed to be, but, unfortunately, it may not be as easy as it seems at first glance. Fuel Master is flying on top of Cent OS 6.5 which doesn't have python 2.7 at all. So we must either run master node on Cent OS

Re: [openstack-dev] [Fuel] Logs format on UI (High/6.0)

+1 to stop parsing logs on UI and show them "as is". I think it's more than enough for all users. On Fri, Dec 12, 2014 at 8:35 PM, Dmitry Pyzhov wrote: > We have a high priority bug in 6.0: > https://bugs.launchpad.net/fuel/+bug/1401852. Here is the story. > > Our openstack services use to send l

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

Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 's

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

doesn't solve out of the box, like working with non-RESTful >>> >> URLs, reverse URL lookup, returning custom body in 404 response, >>> >> wrapping errors to JSON automatically, etc. >>> >> >>> >> As far as I see, each OpenStack

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

Hi, Sebastian, Thank you for raising this topic again. Yes, indeed, we need to move out from web.py as soon as possible and there are a lot of reasons why we should do it. But this topic is not about "Why", this topic is about "Flask or Pecan". Well, currently Fuel uses both of this frameworks:

<    1   2   3   >