Re: [openstack-dev] [Fuel][Solar] Integration in 9.0

[Tomasz Napierala]

> On 26 Feb 2016, at 14:40, Jedrzej Nowak  wrote:
> 
> 3. describe this everything in fuel docs
> 
> Maybe instead blueprint  in 1st step should we create full blown fuel-spec ? 
> That spec obviously will not require any QA activities.

If we actually need feedback, then we need spec. I would go with spec, not 
necessary “full blown”.

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

[Tomasz Napierala]

Hi,

Just wondering what is fine result and decision? This change is pretty wide and 
impacts many dev (and users), I think we should be listening to the feedback 
before making any decision. 

Regards,


> On 17 Dec 2015, at 11:01, Artem Silenkov  wrote:
> 
> Hello! 
> We have merged 9.3 a week ago. From packaging team side downgrade is not an 
> option and was made by mistake.
> Regards 
> Artem Silenkov 
> ---
> MOS-PAckaging
> 
> 
> On Thu, Dec 17, 2015, 12:32 Oleg Gelbukh  wrote:
> In fact, it seems that 9.2 is in the mix since the introduction of centos7. 
> Thus, all tests that have been made since then are made against 9.2. So, 
> upgrading it to 9.3 actually is a change that has to be blocked by FF/SCF.
> 
> Just my 2c.
> 
> --
> Best regards,
> Oleg Gelbukh
> 
> On Thu, Dec 17, 2015 at 12:13 PM, Evgeniy L  wrote:
> Hi Andrew,
> 
> It doesn't look fair at all to say that we use Postgres specific feature for 
> no reasons
> or as you said "just because we want".
> For example we used Arrays which fits pretty well for our roles usage, which 
> improved
> readability and performance.
> Or try to fit into relational system something like that [1], I don't think 
> that we will get
> a good result.
> 
> P.S. sending a link to a holywar topic (schema vs schemaless), won't help to 
> solve our
> specific problem with Postgres downgrading vs keeping old (new) version.
> 
> [1] 
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml
> 
> 
> On Tue, Dec 15, 2015 at 10:53 PM, Andrew Maksimov  
> wrote:
> +1 to Igor suggestion to downgrade Postgres to 9.2. Our users don't work 
> directly with Postgres, so there is no any deprecation of Fuel features.
> Maintaining our own custom Postgres package just because we want "JSON 
> column" is not a rational decision. Come on, fuel is not a billing system 
> with thousands tables and special requirements to database. At least, we 
> should try to keep it simple and avoid unnecessary complication.
> 
> PS
>  BTW, some people suggest to avoid using  json columns, read [1] PostgreSQL 
> anti-patterns: unnecessary json columns.
> 
> [1] - 
> http://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary-jsonhstore-dynamic-columns/
> 
> Regards,
> Andrey Maximov
> Fuel Project Manager
> 
> 
> On Tue, Dec 15, 2015 at 9:34 PM, Vladimir Kuklin  wrote:
> Folks
> 
> Let me add my 2c here.
> 
> I am for using Postgres 9.3. Here is an additional argument to the ones 
> provided by Artem, Aleksandra and others.
> 
> Fuel is being sometimes highly customized by our users for their specific 
> needs. It has been Postgres 9.3 for a while and they might have as well 
> gotten used to it and assumed by default that this would not change. So some 
> of their respective features they are developing for their own sake may 
> depend on Postgres 9.3 and we will never be able to tell the fraction of such 
> use cases. Moreover, downgrading DBMS version of Fuel should be inevitably 
> considered as a 'deprecation' of some features our software suite is 
> providing to our users. This actually means that we MUST provide our users 
> with a warning and deprecation period to allow them to adjust to these 
> changes. Obviously, accidental change of Postgres version does not follow 
> such a policy in any way. So I see no other ways except for getting back to 
> Postgres 9.3.
> 
> 
> On Tue, Dec 15, 2015 at 7:39 PM, Igor Kalnitsky  
> wrote:
> Hey Mike,
> 
> Thanks for your input.
> 
> > actually not.  if you replace your ARRAY columns with JSON entirely,
> 
> It still needs to fix the code, i.e. change ARRAY-specific queries
> with JSON ones around the code. ;)
> 
> > there's already a mostly finished PR for SQLAlchemy support in the queue.
> 
> Does it mean SQLAlchemy will have one unified interface to make JSON
> queries? So we can use different backends if necessary?
> 
> Thanks,
> - Igor
> 
> On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer  wrote:
> >
> >
> > On 12/15/2015 07:20 AM, Igor Kalnitsky wrote:
> >> Hey Julien,
> >>
> >>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql
> >>
> >> I believe this blueprint is about DB for OpenStack cloud (we use
> >> Galera now), while here we're talking about DB backend for Fuel
> >> itself. Fuel has a separate node (so called Fuel Master) and we use
> >> PostgreSQL now.
> >>
> >>> does that mean Fuel is only going to be able to run with PostgreSQL?
> >>
> >> Unfortunately we already tied up to PostgreSQL. For instance, we use
> >> PostgreSQL's ARRAY column type. Introducing JSON column is one more
> >> way to tighten knots harder.
> >
> > actually not.  if you replace your ARRAY columns with JSON entirely,
> > MySQL has JSON as well now:
> > https://dev.mysql.com/doc/refman/5.7/en/json.html
> >
> > there's already a mostly finished PR 

Re: [openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

[Tomasz Napierala]

I agree with Evgeny: from work organization it would more optimal to have 2 
repos. API and system facing programming are completely different domains, 
requiring different skill sets. In my opinion separation would lower the entry 
barriers.

Regards,

> On 17 Dec 2015, at 15:53, Evgeniy L  wrote:
> 
> Hi Igor,
> 
> Bareon by itself doesn't have any REST interface, Bareon is basically 
> fuel_agent,
> which is framework + CLI wrapper to use it as an agent.
> In order to store and edit required entities in the database we need some 
> wrapper,
> which adds this functionality. This simple wrapper will be implemented in 
> Bareon-API.
> User should be able to use Bareon without any additional API/Database if 
> she/he
> wants to do some basic stuff without need to store the configuration, which 
> is not
> Fuel use case.
> If the question was specifically about Bareon-API in separate repo, there is 
> no
> reason to store it in a single repo, since we may have separate teams working
> on those sub-projects and those solve a bit different problems, user facing 
> api
> vs low level tools.
> 
> Thanks,
> 
> On Thu, Dec 17, 2015 at 5:33 PM, Igor Kalnitsky  
> wrote:
> > create Bareon-API repository, and start production ready implementation
> 
> For what reason do we need a separate repo? I thought API will be a
> part of bareon repo. Or bareon is just a provisioning agent, which
> will be driven by bareon-api?
> 
> On Thu, Dec 17, 2015 at 12:29 PM, Evgeniy L  wrote:
> > Hi,
> >
> > Some time ago, we’ve started a discussion [0] about Fuel modularisation
> > activity.
> > Due to unexpected circumstances POC has been delayed.
> >
> > Regarding to partitioning/provisioning system, we have POC with a demo [1]
> > (thanks to Sylwester), which shows how the integration of Fuel and Bareon
> > [2] can
> > be done.
> >
> > To summarise the implementation:
> > * we have a simple implementation of Bareon-API [3], which stores
> > partitioning
> >   related data and allows to edit it
> > * for Nailgun new extension has been implemented [4], which uses Bareon-API
> >   to store partitioning information, so we will be able to easily switch
> > between
> >   classic volume_manager implementation and Bareon-API extension
> > * when provisioning gets started, extensions retrieves the data from
> > Bareon-API
> >
> > Next steps:
> > * create Bareon-API repository, and start production ready implementation
> > * create a spec for Fuel project
> > * create a spec for Bareon project
> >
> > If you have any questions don’t hesitate to ask them in this thread, also
> > you can
> > find us on #openstack-bareon channel.
> >
> > Thanks!
> >
> > [0]
> > http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html
> > [1] https://www.youtube.com/watch?v=GTJM8i7DL0w
> > [2]
> > http://lists.openstack.org/pipermail/openstack-dev/2015-December/082397.html
> > [3] https://github.com/Mirantis/bareon-api
> > [4] https://review.openstack.org/#/c/250864/
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Experimental Task Based Deployment Landed into Master

[Tomasz Napierala]

Great job, especially considering complexity of the problem and late arrival. 
This proves that magic still can happen :)


Regards,

> On 12 Dec 2015, at 00:25, Vladimir Kuklin  wrote:
> 
> Fuelers
> 
> I am thrilled to announce that task based deployment engine [0] has been just 
> merged into Fuel master. We checked it against existing BVT test cases for 
> regressions as well as against functional testing for several cases of 
> deployment. All the OSTF and network verification tests have successfully 
> passed.
> 
> We will obviously need to polish it and fix bugs which will arise, but this 
> is a gigantic step forward for our orchestration engine which should allow us 
> to drastically increase our development velocity as well as end user 
> experience.
> 
> Thanks to all who participated in development testing and review:
> 
> Dmitry Ilyin
> Vladimir Sharshov
> Bulat Gaifullin
> Alexey Shtokolov
> Igor Kalnitsky
> Evgeniy Li
> Sergii Golovatiuk
> Dmitry Shulyak
>  
> and many-many others
> 
> I am pretty confident that this will allow us to develop and test faster as 
> well as introduce support of some of Life-Cycle Management scenarios in 8.0 
> release.
> 
> Once again, thank you all, folks, for your dedicated work and efforts on 
> making Fuel better.
> 
> [0] https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

> On 23 Nov 2015, at 23:57, Igor Kalnitsky  wrote:
> 
> 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 unnecessary complication of your work.

I was trying to find a place where it was agreed to drop containers, and 
failed. The only thread I’m aware of [0] does not seem to be closed and does 
not provide any clear decisions.


[0]http://lists.openstack.org/pipermail/openstack-dev/2015-November/079866.html

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

> On 23 Oct 2015, at 16:09, Sergey Lukjanov  wrote:
> 
> Hi folks,
> 
> component lead elections ended as well.
> 
> Congrats to Sergii Golovatiuk for becoming official Fuel-library component 
> lead!
> 
> Results: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_93a6886b38223ab3

Everyone - thanks for voting.

Sergii - please accept my congratulations!

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

+1 here. There were very little implemented in the new client in terms of 
feature parity, it’s not ready to be real replacement yet.


> On 14 Oct 2015, at 11:13, 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 were no progress with moving old commands to new CLI and I didn't seen 
> plans to do so.
> IMHO without a detailed plan on migrating old commands to new client and 
> without a person (or people)
> that will drive this task we *cannot* freeze old fuelclient as new one is 
> still not fully usable.
> 
> Best,
> Sebastian
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070279.html
> 
> 
> 2015-10-14 10:56 GMT+02:00 Roman Prykhodchenko :
> Fuelers,
> 
> as you know a big effort has been put into making Fuel Client’s CLI better 
> and as a result we got a new fuel2 utility with a new set of commands and 
> options. Some folks still put great effort to move everything that’s left in 
> the old CLI to the new CLI.
> 
> Every new thing added to the old CLI moves the point where we can finally 
> remove it to the future. My proposal is to do a hard code freeze for the old 
> CLI and only add new stuff to the new one.
> 
> 
> - romcheg
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

Congrats Dmitry! Well deserved.


> On 09 Oct 2015, at 19:13, Mike Scherbakov <mscherba...@mirantis.com> wrote:
> 
> Congratulations to Dmitry!
> Now you are officially titled with PTL.
> It won't be easy, but we will support you!
> 
> 118 contributors voted. Thanks everyone! Thank you Sergey for organizing 
> elections for us.
> 
> On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov <slukja...@mirantis.com> wrote:
> Voting period ended and so we have an officially selected Fuel PTL - DB. 
> Congrats!
> 
> Poll results & details - 
> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0
> 
> Let's start proposing candidates for the component lead positions!
> 
> On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov <slukja...@mirantis.com> 
> wrote:
> Hi folks,
> 
> I've just setup the voting system and you should start receiving email with 
> topic "Poll: Fuel PTL Elections Fall 2015".
> 
> NOTE: Please, don't forward this email, it contains *personal* unique token 
> for the voting.
> 
> Thanks.
> 
> On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin <vkuk...@mirantis.com> wrote:
> +1 to Igor. Do we have voting system set up?
> 
> On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky <ikalnit...@mirantis.com> 
> wrote:
> > * 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
> <tnapier...@mirantis.com> wrote:
> >> On 18 Sep 2015, at 04:39, Sergey Lukjanov <slukja...@mirantis.com> wrote:
> >>
> >>
> >> Time line:
> >>
> >> PTL elections
> >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL position
> >> * September 29 - October 8: PTL elections
> >
> > Just a reminder that we have a deadline for candidates today.
> >
> > Regards,
> > --
> > Tomasz 'Zen' Napierala
> > Product Engineering - Poland
> >
> >
> >
> >
> >
> >
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> 
> 
> 
> -- 
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -- 
> Mike Scherbakov
> #mihgen
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q Session

[Tomasz Napierala]

Hi

That’s right, but we made slight change here:
"Define architecture direction & review majority of design specs. Rely on 
Component Leads and Core Reviewers"

So we assume that detailed architectural work will be relayed to Component Leads


> On 02 Oct 2015, at 10:12, Evgeniy L  wrote:
> 
> Hi Mike,
> 
> According to the description of the role, I wouldn't say that the role is 
> less architectural than
> political, since PTL should review designs and resolve conflicts between 
> cores (which are
> usually technical), PTL should also have strong skills in software 
> architecture, and understanding
> of what Fuel should look like.
> 
> Thanks,
> 
> On Thu, Oct 1, 2015 at 11:32 PM, Mike Scherbakov  
> wrote:
> > we may mix technical direction / tech debt roadmap and process, political, 
> > and people management work of PTL.
> sorry, of course I meant that we rather should NOT mix these things.
> 
> To make my email very short, I'd say PTL role is more political and 
> process-wise rather than architectural.
> 
> On Wed, Sep 30, 2015 at 5:48 PM Mike Scherbakov  
> wrote:
> Vladimir,
> we may mix technical direction / tech debt roadmap and process, political, 
> and people management work of PTL.
> 
> PTL definition in OpenStack [1] reflects many things which PTL becomes 
> responsible for. This applies to Fuel as well.
> 
> I'd like to reflect some things here which I'd expect PTL doing, most of 
> which will intersect with [1]:
> - Participate in cross-project initiatives & resolution of issues around it. 
> Great example is puppet-openstack vs Fuel [2]
> - Organize required processes around launchpad bugs & blueprints
> - Personal personal feedback to Fuel contributors & public suggestions when 
> needed
> - Define architecture direction & review majority of design specs. Rely on 
> Component Leads and Core Reviewers
> - Ensure that roadmap & use cases are aligned with architecture work
> - Resolve conflicts between core reviewers, component leads. Get people to 
> the same page
> - Watch for code review queues and quality of reviews. Ensure discipline of 
> code review.
> - Testing / coverage have to be at the high level
> 
> Considering all above, contributors actually have been working with all of us 
> and know who could be better handling such a hard work. I don't think special 
> Q is needed. If there are concerns / particular process/tech questions we'd 
> like to discuss - those should be just open as email threads.
> 
> [1] https://wiki.openstack.org/wiki/PTL_Guide
> [2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html
> 
> Thank you,
> 
> On Tue, Sep 29, 2015 at 3:47 AM Vladimir Kuklin  wrote:
> Folks
> 
> I think it is awesome we have three candidates for PTL position in Fuel. I 
> read all candidates' emails (including mine own several times :-) ) and I got 
> a slight thought of not being able to really differentiate the candidates 
> platforms as they are almost identical from the high-level point of view. But 
> we all know that the devil is in details. And this details will actually 
> affect project future.
> 
> Thus I thought about Q session at #fuel-dev channel in IRC. I think that 
> this will be mutually benefitial for everyone to get our platforms a little 
> bit more clear.
> 
> Let's do it before or right at the start of actual voting so that our 
> contributors can make better decisions based on this session.
> 
> I suggest the following format:
> 
> 1) 3 questions from electorate members - let's put them onto an etherpad
> 2) 2 questions from a candidate to his opponents (1 question per opponent)
> 3) external moderator - I suppose, @xarses as our weekly meeting moderator 
> could help us
> 4) time and date - Wednesday or Thursday comfortable for both timezones, e.g. 
> after 4PM UTC or right after fuel weekly meeting.
> 
> What do you think, folks?
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -- 
> Mike Scherbakov
> #mihgen


-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

> On 18 Sep 2015, at 04:39, Sergey Lukjanov  wrote:
> 
> 
> Time line:
> 
> PTL elections
> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL position
> * September 29 - October 8: PTL elections

Just a reminder that we have a deadline for candidates today.

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Tomasz Napierala]

> On 02 Sep 2015, at 01:31, Sergii Golovatiuk  wrote:
> 
> Hi,
> 
> I would like to nominate Alex Schultz to Fuel-Library Core team. He’s been 
> doing a great job in writing patches. At the same time his reviews are solid 
> with comments for further improvements. He’s #3 reviewer and #1 contributor 
> with 46 commits for last 90 days [1]. Additionally, Alex has been very active 
> in IRC providing great ideas. His ‘librarian’ blueprint [3] made a big step 
> towards to puppet community.
> 
> Fuel Library, please vote with +1/-1 for approval/objection. Voting will be 
> open until September 9th. This will go forward after voting is closed if 
> there are no objections.  
> 
> Overall contribution:
> [0] http://stackalytics.com/?user_id=alex-schultz
> Fuel library contribution for last 90 days:
> [1] http://stackalytics.com/report/contribution/fuel-library/90
> List of reviews:
> [2] 
> https://review.openstack.org/#/q/reviewer:%22Alex+Schultz%22+status:merged,n,z
> ‘Librarian activities’ in mailing list: 
> [3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/071058.html


Definitely well deserved for Alex. Outstanding technical work and really good 
community skills! My strong +1

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

> On 01 Sep 2015, at 03:43, Igor Kalnitsky  wrote:
> 
> 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?
> 

>From what I understand, it is not correct. Core reviewer will still do all 
>this activities in most cases. What we are trying to achieve, is to get core's 
>attention only to reviews, that are already reviewed by SMEs and peers. We
hope this will increase the quality of code core reviewers are getting.

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

 On 27 Aug 2015, at 07:58, Evgeniy L e...@mirantis.com wrote:
 
 Hi Mike,
 
 I have several comments.
 
  SLA should be the driver of doing timely reviews, however we can’t allow 
  to fast-track code into master suffering quality of review ...
 
 As for me the idea of SLA contradicts to qualitative reviews.

We expect cores to be less loaded after this change, so you guys should have 
more time to spend on right reviews, and not minor stuff. We hope this will 
also help keeping SLAs.

 Another thing is I got a bit confused by the difference between Core Reviewer 
 and Component Lead,
 aren't those the same persons? Shouldn't every Core Reviewer know the 
 architecture, best practises
 and participate in design architecture sessions?

Not really. You can have  many core reviewers, but there should be one 
component lead. Currently, while Fuel is monolithic, we cannot implement it in 
technical way. But if we succeed splitting Fuel into smaller projects, 
component lead will be responsible for (most likely) one repo.

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

 On 02 Jul 2015, at 06:59, Mike Scherbakov mscherba...@mirantis.com wrote:
 
 Alex - congratulations! Added you to fuel-library core.
 


Also congrats from me, well deserved!

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?

[Tomasz Napierala]

I’m -1 for it.

Considering how much time we needed to troubleshoot the problems already, I 
don’t think we have time to properly test the upgrade.


 On 29 Apr 2015, at 12:37, Sergii Golovatiuk sgolovat...@mirantis.com wrote:
 
 -1 for upgrading it in 6.1. Known devil is better than unknown angel :)
 
 In 7.0 we can try 3.5.0 with updated Erlang.
 
 ~thanks
 
 
 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser
 
 On Wed, Apr 29, 2015 at 12:20 PM, Davanum Srinivas dsrini...@mirantis.com 
 wrote:
 Bogdan,
 
 Pacemaker, corosync etc, we picked vivid packages right? So don't we test 
 what's in vivid for this too? Apparently it's 3.4.3-2 per [0].
 
 I agree, we should not do this in 6.1, However, we should start testing this 
 ASAP.
 
 Another data point, Alexander Nevenchannyy pointed out to me that 3.5.0 came 
 with an updated Erlang that has the following fix:
 OTP-11497  To prevent a race condition if there is a short communication
 
 problem when node-down and node-up events are received. They
 
 are now stored and later checked if the node came up just
 
 before mnesia flagged the node as down. (Thanks to Jonas Falkevik )
 
 which seems interesting as well.
 
 thanks,
 
 dims
 
 [0] https://launchpad.net/ubuntu/vivid/+package/rabbitmq-server
 [1] http://www.erlang.org/download/otp_src_17.0.readme
 
 On Wed, Apr 29, 2015 at 4:04 AM, Bogdan Dobrelya bdobre...@mirantis.com 
 wrote:
 Hello.
 
 There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]:
 1) At least two bugfixes related to the current high-load issue with MQ [1]:
 - 26404 prevent queue synchronisation from hanging if there is a very
 short partition just as it starts (since 3.1.0)
 - 26368 prevent autoheal from hanging when loser shuts down before the
 winner  learns it is the winner (since 3.1.0)
 2) We should as well check how the new 'pause-if-all-down' option works
 for split brain recovery.
 3) We should address the 'force_boot' recommendations from this mail
 thread [2] to speed up the MQ cluster assemble time.
 
 The question is - is it worth it to do this in the 6.1 release scope?
 I vote to postpone this for the 7.0 dev cycle as the impact of such
 changes might be unpredictable.
 
 [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt
 [1] https://bugs.launchpad.net/fuel/+bug/1447619
 [2]
 http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html
 
 --
 Best regards,
 Bogdan Dobrelya,
 Skype #bogdando_at_yahoo.com
 Irc #bogdando
 
 

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel]Format of notifications about Ubuntu repositories connectivity

[Tomasz Napierala]

 On 17 Apr 2015, at 14:35, Maciej Kwiek mkw...@mirantis.com wrote:
 
 Hi,
 
 I am currently implementing fix for 
 https://bugs.launchpad.net/fuel/+bug/1439686 .
 
 I plan to notify user about nodes which fail to connect to ubuntu 
 repositories via fuel notifications. My question is as follows: when I get 
 the list of nodes which failed repo connectivity test - do I add one 
 notification for each node, or can I add one big notification, which consists 
 of all names of all nodes that failed?

If there are no code level restrictions, IMHO one notification should be fine

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

Do you mean single node?

 On 15 Apr 2015, at 17:04, Dmitry Pyzhov dpyz...@mirantis.com wrote:
 
 FYI. We are going to disable Multi-node mode on UI even in experimental mode. 
 And we will remove related code from nailgun in 7.0.
 https://bugs.launchpad.net/fuel/+bug/1428054
 
 On Fri, Jan 30, 2015 at 1:39 PM, Aleksandr Didenko adide...@mirantis.com 
 wrote:
 What do you guys think about switching CentOS CI job [1] to HA with single 
 controller (1 controller + 1 or 2 computes)? Just to verify that our 
 replacement of Simple mode works fine.
 
 [1] 
 https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/
 
 On Fri, Jan 30, 2015 at 10:54 AM, Mike Scherbakov mscherba...@mirantis.com 
 wrote:
 Thanks Igor for the quick turn over, excellent!
 
 On Fri, Jan 30, 2015 at 1:19 AM, Igor Belikov ibeli...@mirantis.com wrote:
 Folks,
 
 Changes in CI jobs have been made, for master branch of fuel-library we are 
 running CentOS HA + Nova VLAN and Ubuntu HA + Neutron VLAN .
 Job naming schema has also been changed, so now it includes actual testgroup. 
 Current links for master branch CI jobs are [1] and [2], all other jobs can 
 be found here[3] or will show up in your gerrit reviews.
 ISO and environments have been updated to the latest ones.
 
 [1]https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/
 [2]https://fuel-jenkins.mirantis.com/job/master.fuel-library.ubuntu.ha_neutron_vlan/
 [3]https://fuel-jenkins.mirantis.com
 --
 Igor Belikov
 Fuel DevOps
 ibeli...@mirantis.com
 
 
 
 
 
 On 29 Jan 2015, at 13:42, Aleksandr Didenko adide...@mirantis.com wrote:
 
 Mike,
 
  Any objections / additional suggestions?
 
 no objections from me, and it's already covered by LP 1415116 bug [1]
 
 [1] https://bugs.launchpad.net/fuel/+bug/1415116
 
 On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov mscherba...@mirantis.com 
 wrote:
 Folks,
 one of the things we should not forget about - is out Fuel CI gating 
 jobs/tests. [1], [2].
 
 One of them is actually runs simple mode. Unfortunately, I don't see details 
 about tests ran for [1], [2], but I'm pretty sure it's same set as [3], [4].
 
 I suggest to change tests. First of all, we need to get rid of simple runs 
 (since we are deprecating it), and second - I'd like us to run Ubuntu HA + 
 Neutron VLAN for one of the tests.
 
 Any objections / additional suggestions?
 
 [1] 
 https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_centos/
 [2] 
 https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/
 [3] https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_centos/
 [4] https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_ubuntu/
 
 On Wed, Jan 28, 2015 at 2:28 PM, Sergey Vasilenko svasile...@mirantis.com 
 wrote:
 +1 to replace simple to HA with one controller
 
 /sv
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Mike Scherbakov
 #mihgen
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Mike Scherbakov
 #mihgen
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland

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

[Tomasz Napierala]

Sorry, I just mixed the names ;)

 On 15 Apr 2015, at 18:25, Igor Kalnitsky ikalnit...@mirantis.com wrote:
 
 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
 tnapier...@mirantis.com wrote:
 Do you mean single node?
 
 On 15 Apr 2015, at 17:04, Dmitry Pyzhov dpyz...@mirantis.com wrote:
 
 FYI. We are going to disable Multi-node mode on UI even in experimental 
 mode. And we will remove related code from nailgun in 7.0.
 https://bugs.launchpad.net/fuel/+bug/1428054
 
 On Fri, Jan 30, 2015 at 1:39 PM, Aleksandr Didenko adide...@mirantis.com 
 wrote:
 What do you guys think about switching CentOS CI job [1] to HA with single 
 controller (1 controller + 1 or 2 computes)? Just to verify that our 
 replacement of Simple mode works fine.
 
 [1] 
 https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/
 
 On Fri, Jan 30, 2015 at 10:54 AM, Mike Scherbakov 
 mscherba...@mirantis.com wrote:
 Thanks Igor for the quick turn over, excellent!
 
 On Fri, Jan 30, 2015 at 1:19 AM, Igor Belikov ibeli...@mirantis.com wrote:
 Folks,
 
 Changes in CI jobs have been made, for master branch of fuel-library we are 
 running CentOS HA + Nova VLAN and Ubuntu HA + Neutron VLAN .
 Job naming schema has also been changed, so now it includes actual 
 testgroup. Current links for master branch CI jobs are [1] and [2], all 
 other jobs can be found here[3] or will show up in your gerrit reviews.
 ISO and environments have been updated to the latest ones.
 
 [1]https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/
 [2]https://fuel-jenkins.mirantis.com/job/master.fuel-library.ubuntu.ha_neutron_vlan/
 [3]https://fuel-jenkins.mirantis.com
 --
 Igor Belikov
 Fuel DevOps
 ibeli...@mirantis.com
 
 
 
 
 
 On 29 Jan 2015, at 13:42, Aleksandr Didenko adide...@mirantis.com wrote:
 
 Mike,
 
 Any objections / additional suggestions?
 
 no objections from me, and it's already covered by LP 1415116 bug [1]
 
 [1] https://bugs.launchpad.net/fuel/+bug/1415116
 
 On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov 
 mscherba...@mirantis.com wrote:
 Folks,
 one of the things we should not forget about - is out Fuel CI gating 
 jobs/tests. [1], [2].
 
 One of them is actually runs simple mode. Unfortunately, I don't see 
 details about tests ran for [1], [2], but I'm pretty sure it's same set as 
 [3], [4].
 
 I suggest to change tests. First of all, we need to get rid of simple runs 
 (since we are deprecating it), and second - I'd like us to run Ubuntu HA + 
 Neutron VLAN for one of the tests.
 
 Any objections / additional suggestions?
 
 [1] 
 https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_centos/
 [2] 
 https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/
 [3] 
 https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_centos/
 [4] 
 https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_ubuntu/
 
 On Wed, Jan 28, 2015 at 2:28 PM, Sergey Vasilenko 
 svasile...@mirantis.com wrote:
 +1 to replace simple to HA with one controller
 
 /sv
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 --
 Mike Scherbakov
 #mihgen
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 --
 Mike Scherbakov
 #mihgen
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin

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

[Tomasz Napierala]

Congratulations Sebastian!

Regards

 On 15 Apr 2015, at 10:06, Igor Kalnitsky ikalnit...@mirantis.com wrote:
 
 Well, looks like there's no objections and voting is over. :)
 
 Welcome aboard, Sebastian!
 
 On Mon, Apr 13, 2015 at 4:09 PM, Sergii Golovatiuk
 sgolovat...@mirantis.com wrote:
 +1
 
 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser
 
 On Mon, Apr 13, 2015 at 1:09 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
 
 +1
 
 On Mon, Apr 13, 2015 at 2:07 PM, Evgeniy L e...@mirantis.com wrote:
 
 +1
 
 On Fri, Apr 10, 2015 at 1:35 PM, Roman Prykhodchenko m...@romcheg.me
 wrote:
 
 +1. Sebastian does great job in reviews!
 
 10 квіт. 2015 о 12:05 Igor Kalnitsky ikalnit...@mirantis.com
 написав(ла):
 
 Hi Fuelers,
 
 I'd like to nominate Sebastian Kalinowski for the both fuel-web-core
 [1] and python-fuelclient-core [2] teams. Sebastian's doing a really
 good review with detailed feedback and he's a regular participant in
 IRC. I believe that having him among the cores we will increase our
 overall performance.
 
 Fuel Cores, please reply back with +1/-1.
 
 Thanks,
 Igor
 
 [1]:
 http://stackalytics.com/?project_type=stackforgemodule=fuel-webrelease=kilo
 [2]:
 http://stackalytics.com/?project_type=stackforgemodule=python-fuelclientrelease=kilo
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

+1 definately

 On 25 Mar 2015, at 20:10, Dmitry Borodaenko dborodae...@mirantis.com wrote:
 
 Fuelers,
 
 I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
 She has contributed thousands of lines of documentation to Fuel over
 the past several months, and has been a diligent reviewer:
 
 http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs
 
 I believe it's time to grant her core reviewer rights in the fuel-docs
 repository.
 
 Core reviewer approval process definition:
 https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
 
 -- 
 Dmitry Borodaenko
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Fuel meeting participation.

[Tomasz Napierala]

 On 17 Mar 2015, at 01:12, Andrew Woodward xar...@gmail.com wrote:
 
 The last couple of meetings have been visibly low on participation. Most 
 notably anyone not involved with the planned schedule is not participating. 
 Often I find that the discussion leeds to wanting to talk with more of the 
 devs, but they are frequently not available. 
 
 Is there any reason for the low participation ( time / schedule )? Any one 
 have any thoughts as to how we can improve attendance?

I think in last couple of months quality of the meetings degraded and 
conversations switched to other channels. One of the reasons I find particulary 
annoying is last changes to agenda, often unexpected and surprising. To fix 
that we need to plan in advance. I would suggest putting things in agenda once 
they come up, e.g. during other discussions, 1on1s, etc. I also think it would 
be beneficial if we define purpose of this meeting. 

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Recent issues with our review workflow

[Tomasz Napierala]

 On 09 Mar 2015, at 18:21, Ryan Moe r...@mirantis.com wrote:
 
 Hi All,
 
 I've noticed a few times recently where reviews have been abandoned by people 
 who were not the original authors. These reviews were only days old and there 
 was no prior notice or discussion. This is both rude and discouraging to 
 contributors. Reasons for abandoning should be discussed on the review and/or 
 in email before any action is taken.

Hi Ryan,

I was trying to find any examples, and the only one I see is:
https://review.openstack.org/#/c/152674/

I spoke to Bogdan and he agreed it was not proper way to do it, but they were 
in a rush - I know, it does not explain anything really.

Do you have any other examples? I’d like to clarify them

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Cache for packages on master node

[Tomasz Napierala]

 On 10 Feb 2015, at 23:02, Andrew Woodward xar...@gmail.com wrote:
 
 previously we used squid in 3.0 and before. The main problem is that the 
 deployment would proceeded even if not all the packages where cached or even 
 available on the remote. This often lead to broken deployments that where 
 hard to debug and a waste of alot of time. This _MUST_ be resolved or we will 
 re-introduce this horrible work flow that we had placed all the packages on 
 the system for to begin with.

Anyway we need to ensure our QA is run against fresh mirror, that would prevent 
a lot of problems. We also think about how situation in the field can differ 
from our labs and QA infra - there might be differences indeed.

 I think we need to add a requirements that we need to be able to:
 a) pre-populate the cacher 
 b) we need to not start the deployment until we either have every package in 
 the chache (eiew) or at least know every package is reachable currently (or 
 allow the user to select either as a deployment criteria)

This sounds for me like creating local mirror ;) We don’t want to do this.
We are thinking about mirror verification tool, it was mentioned by eifferent 
guys already. Do you really think we should prepopulate cache? I hink first 
node deployment will fetch a lot of packages, and other nodes will be easier. 
Once we have prototype, we will see some number.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Cache for packages on master node

[Tomasz Napierala]

Hi,

We are currently redesigning our apporach to upstream distributions and 
obviusly we will need some cache system for packages on master node. It should 
work for deb and rpm packages, and be able to serve up to 200 nodes.
I know we had bad experience in the past, can you guys share your thought on 
that?
I just collected what was mentioned in other discussions:
- approx
- squid
- apt-cacher-ng
- ?

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch

[Tomasz Napierala]

Hi,

I also think, that after release we should run restrospective and actually 
analyse how much reality differs from the spec. This will help us improve 
planning in the future.


 On 03 Feb 2015, at 22:15, Andrey Danin ada...@mirantis.com wrote:
 
 I totally agree with Andrew. 
 
 On Tuesday, February 3, 2015, Andrew Woodward xar...@gmail.com wrote:
 Either we do specs, or we don't. Either every one has to land their specs 
 before code or no one does. Its that simple.
 
 What should be sorted out? It is unavoidable that people will comment and ask 
 questions during development cycle.
 I am not sure that merging spec as early as possible, and than add comments 
 and different fixes is good strategy.
 On the other hand we need to eliminate risks.. but how merging spec can help?
  
 The spec defining what has been committed already needs to be merged, and we 
 can open another review to modify the spec into another direction if 
 necessary.
 
 We can spend several month on polishing the spec, will it help
 to release feature in time? I don't think so.
 
 The spec doesn't have to be perfect, but it needs to be merged prior to code 
 describing it.
 
 I think the spec should be a synchronization point, where different
 teams can discuss details and make sure that everything is correct.
 The spec should represent the current state of the code which is
 merged and which is going to be merged. 
 
 This isn't the intent of the spec, its to document the extent, general 
 direction, and impact of a feature. As a side effect, well defined specs can 
 also serve as documentation for the feature. While the discussion is common 
 on the spec, this should be done on a merged spec. 
 
 On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L e...@mirantis.com wrote:
 Hi,
 
 +1 to Dmitriy's comment.
 We can spend several month on polishing the spec, will it help
 to release feature in time? I don't think so.
 Also with your suggestion we'll get a lot of patches over 2 thousands
 lines of code, after spec is merged. Huge patches reduce quality,
 because it's too hard to review, also such patches much harder
 to get merged.
 I think the spec should be a synchronization point, where different
 teams can discuss details and make sure that everything is correct.
 The spec should represent the current state of the code which is
 merged and which is going to be merged.
 
 Thanks,
 
 On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak dshul...@mirantis.com 
 wrote:
 Andrew,
 What should be sorted out? It is unavoidable that people will comment and ask 
 questions during development cycle.
 I am not sure that merging spec as early as possible, and than add comments 
 and different fixes is good strategy.
 On the other hand we need to eliminate risks.. but how merging spec can help?
 
 On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward xar...@gmail.com wrote:
 Vova,
 
 Its great to see so much progress on this, however it appears that we
 have started merging code prior to the spec landing [0] lets get it
 sorted ASAP.
 
 [0] https://review.openstack.org/#/c/113491/
 
 On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote:
  Hi, Fuelers and Stackers
 
  I am glad to announce that we merged initial support for granular deployment
  feature which is described here:
 
  https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks
 
  This is an important milestone for our overall deployment and operations
  architecture as well as it is going to significantly improve our testing and
  engineering process.
 
  Starting from now we can start merging code for:
 
  https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
  https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing
 
  We are still working on documentation and QA stuff, but it should be pretty
  simple for you to start trying it out. We would really appreciate your
  feedback.
 
  Existing issues are the following:
 
  1) pre and post deployment hooks are still out of the scope of main
  deployment graph
  2) there is currently only puppet task provider working reliably
  3) no developer published documentation
  4) acyclic graph testing not injected into CI
  5) there is currently no opportunity to execute particular task - only the
  whole deployment (code is being reviewed right now)
 
  --
  Yours Faithfully,
  Vladimir Kuklin,
  Fuel Library Tech Lead,
  Mirantis, Inc.
  +7 (495) 640-49-04
  +7 (926) 702-39-68
  Skype kuklinvv
  45bk3, Vorontsovskaya Str.
  Moscow, Russia,
  www.mirantis.com
  www.mirantis.ru
  vkuk...@mirantis.com
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 --
 Andrew
 Mirantis
 Ceph community
 
 On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin 

Re: [openstack-dev] [Fuel] [Puppet] Manifests for granular deploy steps and testing results against the host OS

[Tomasz Napierala]

I hope, we don’t even consider using python for that. Let’s be as close as 
possible to community and use rspec for manifests.

Regards,

 On 29 Jan 2015, at 09:50, Vladimir Kuklin vkuk...@mirantis.com wrote:
 
 Guys, could you point out where I suggested to use python for testing puppet 
 manifests?
 
 On Thu, Jan 29, 2015 at 1:28 AM, Sergii Golovatiuk sgolovat...@mirantis.com 
 wrote:
 We need to write tests in way how Puppet community writes. Though if user 
 uses salt in one stage, it's fine to use tests on python.
 
 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser
 
 On Wed, Jan 28, 2015 at 11:15 PM, Dmitriy Shulyak dshul...@mirantis.com 
 wrote:
 Guys, is it crazy idea to write tests for deployment state on node in python?
 It even can be done in unit tests fashion..
 
 I mean there is no strict dependency on tool from puppet world, what is 
 needed is access to os and shell, maybe some utils.
 
  What plans have Fuel Nailgun team for testing the results of deploy steps 
  aka tasks?
 From nailgun/orchestration point of view - verification of deployment should 
 be done as another task, or included in original.
 
 On Thu, Jan 22, 2015 at 5:44 PM, Vladimir Kuklin vkuk...@mirantis.com wrote:
 Moreover I would suggest to use server spec as beaker is already duplicating 
 part of our infrastructure automatization.
 
 On Thu, Jan 22, 2015 at 6:44 PM, Vladimir Kuklin vkuk...@mirantis.com wrote:
 Guys, I suggest that we create a blueprint how to integrate beaker with our 
 existing infrastructure to increase test coverage. My optimistic estimate is 
 that we can see its implementation in 7.0.
 
 On Thu, Jan 22, 2015 at 2:07 AM, Andrew Woodward xar...@gmail.com wrote:
 My understanding is serverspec is not going to work well / going to be
 supported. I think it was discusssed on IRC (as i cant find it in my
 email). Stackforge/puppet-ceph moved from ?(something)spec to beaker,
 as its more functional and actively developed.
 
 On Mon, Jan 12, 2015 at 6:10 AM, Sergii Golovatiuk
 sgolovat...@mirantis.com wrote:
  Hi,
 
  Puppet OpenStack community uses Beaker for acceptance testing. I would
  consider it as option [2]
 
  [2] https://github.com/puppetlabs/beaker
 
  --
  Best regards,
  Sergii Golovatiuk,
  Skype #golserge
  IRC #holser
 
  On Mon, Jan 12, 2015 at 2:53 PM, Bogdan Dobrelya bdobre...@mirantis.com
  wrote:
 
  Hello.
 
  We are working on the modularization of Openstack deployment by puppet
  manifests in Fuel library [0].
 
  Each deploy step should be post-verified with some testing framework as
  well.
 
  I believe the framework should:
  * be shipped as a part of Fuel library for puppet manifests instead of
  orchestration or Nailgun backend logic;
  * allow the deployer to verify results right in-place, at the node being
  deployed, for example, with a rake tool;
  * be compatible / easy to integrate with the existing orchestration in
  Fuel and Mistral as an option?
 
  It looks like test resources provided by Serverspec [1] are a good
  option, what do you think?
 
  What plans have Fuel Nailgun team for testing the results of deploy
  steps aka tasks? The spec for blueprint gives no a clear answer.
 
  [0]
  https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
  [1] http://serverspec.org/resource_types.html
 
  --
  Best regards,
  Bogdan Dobrelya,
  Skype #bogdando_at_yahoo.com
  Irc #bogdando
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 --
 Andrew
 Mirantis
 Ceph community
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 -- 
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 45bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com
 www.mirantis.ru
 vkuk...@mirantis.com
 
 
 
 -- 
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 45bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com
 www.mirantis.ru
 vkuk...@mirantis.com
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

[Tomasz Napierala]

Guys,

We have requests for this improvement. It will help with huge environments, we 
are talking about 5GiB of logs.
Is it on the agenda?

Regards,


 On 22 Dec 2014, at 07:28, Bartlomiej Piotrowski bpiotrow...@mirantis.com 
 wrote:
 
 FYI, xz with multithreading support (5.2 release) has been marked as stable 
 yesterday.
 
 Regards,
 Bartłomiej Piotrowski
 
 On Mon, Nov 24, 2014 at 12:32 PM, Bartłomiej Piotrowski 
 bpiotrow...@mirantis.com wrote:
 On 24 Nov 2014, at 12:25, Matthew Mosesohn mmoses...@mirantis.com wrote:
  I did this exercise over many iterations during Docker container
  packing and found that as long as the data is under 1gb, it's going to
  compress really well with xz. Over 1gb and lrzip looks more attractive
  (but only on high memory systems). In reality, we're looking at log
  footprints from OpenStack environments on the order of 500mb to 2gb.
 
  xz is very slow on single-core systems with 1.5gb of memory, but it's
  quite a bit faster if you run it on a more powerful system. I've found
  level 4 compression to be the best compromise that works well enough
  that it's still far better than gzip. If increasing compression time
  by 3-5x is too much for you guys, why not just go to bzip? You'll
  still improve compression but be able to cut back on time.
 
  Best Regards,
  Matthew Mosesohn
 
 Alpha release of xz supports multithreading via -T (or —threads) parameter.
 We could also use pbzip2 instead of regular bzip to cut some time on 
 multi-core
 systems.
 
 Regards,
 Bartłomiej Piotrowski
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

+1, long awaited


 On 27 Jan 2015, at 14:05, Aleksandr Didenko adide...@mirantis.com wrote:
 
 Hi,
 
 After starting implementing granular deployment we've faced a bunch of issues 
 that would make further development of this feature much more complicated if 
 we have to support both Simple and HA deployment modes. For example: simple 
 mode does not require cluster (corosync, pacemaker, vips, etc), so we had to 
 skip this task for Simple mode somehow - we can use conditional tasks, or 
 conditional manifests in our tasks, or create separate task graphs for 
 different deployment modes, etc - either way it's pretty much doubling the 
 amount of work for some parts of Fuel and our development cycle.
 
 At the moment, CI blocks us from further development of fuel-library 
 modularization BP [2] because we still use Simple mode in CI. So in order to 
 proceed with this BP we have two options:
 
 1) remove Simple mode from CI/QA and thus drop it completely from Fuel
 2) double our efforts to support both Simple and HA modes in granular 
 deployment
 
 We have a BP about single-controller HA [1]. HA with single controller works 
 just fine at the moment. So if you want to test Fuel on a minimum set of 
 nodes, you can do this on 3 nodes (Fuel master, controller, compute), just 
 like with Simple mode before. I suppose, it's time to finally drop support 
 for Simple mode in Fuel :)
 
 [1] https://blueprints.launchpad.net/fuel/+spec/single-controller-ha
 [2] https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
 
 --
 Regards,
 Aleksandr Didenko
 
 
 On Tue, Aug 26, 2014 at 9:25 AM, Mike Scherbakov mscherba...@mirantis.com 
 wrote:
 Definitely fuel spec is needed :)
 
 
 On Mon, Aug 25, 2014 at 8:45 PM, Evgeniy L e...@mirantis.com wrote:
 Hi Andrew, 
 
 I have some comments regarding to you action items
 
  2) Removing simple mode from the ui and tests
  3) Removing simple mode support from nailgun (maybe we leave it) and cli
 
 We shouldn't do it, because nailgun should handle both versions of cluster.
 What we have to do here is to use openstack.yaml to keep all possible modes.
 For new release there will be only ha, to manage previous releases we have
 to create data migrations in nailgun to create the filed with modes i.e. 
 multinode
 and ha.
 
 Also fixes for ui are required too, I think it mostly related to wizard, 
 'mode' tab
 where use can chose ha or non ha cluster in case of new release there should
 be only ha, and in case of old releases there should be ha and multinode.
 
 Thanks,
 
 
 
 On Mon, Aug 25, 2014 at 8:19 PM, Andrew Woodward xar...@gmail.com wrote:
 Started a new thread so that we don't hijack the older thread.
  as 
  
 Andrew, will you work on it in 6.0? What are remaining items there? Also, it 
 might affect our tests - simple mode runs faster so we use it for smoke ISO 
 test. Anastasia, please confirm that we can switch smoke to one-ha-controller 
 model, or even drop smoke at all and use BVT only (running CentOS 3 HA 
 controllers and same with Ubuntu).
 
 The primary reason that we haven't disabled single yet is was due to [0] 
 where we where having problems adding additional controllers. With the 
 changes to galera and rabbit clustering it appears that we ended up fixing it 
 already.
 
 The remaining issues are:
 1) Ensuring we have good test coverage for the cases we expect to support [1]
 2) Removing simple mode from the ui and tests
 3) Removing simple mode support from nailgun (maybe we leave it) and cli
 4) Updating documentation
 
 [0] https://bugs.launchpad.net/fuel/+bug/1350266
 [1] https://bugs.launchpad.net/fuel/+bug/1350266/comments/7
 
 -- 
 Andrew
 Mirantis
 Ceph community
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Mike Scherbakov
 #mihgen
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Proposal for nominating people to python-fuelclient-core

[Tomasz Napierala]

+1


 On 26 Jan 2015, at 11:33, Roman Prykhodchenko m...@romcheg.me wrote:
 
 Hi Guys,
 
 According to our previous thread [1] and the decision made there I’d like to 
 initiate separation of the original fuel-core group.
 
 At the first step propose the following python guys from the original 
 fuel-core group to be nominated to python-fuelclient-core group.
 
 Aleksey Kasatkin — akasatkin
 Dmitry Pyzhov — dpyzhov
 Evgeniy L — evgeniyl___
 Igor Kalnitsky — ikalnitsky
 
 The decision will be made basing on lazy consensus. Since I was in 
 python-fuelclient-core group only for technical reasons, I will remove myself 
 from there as soon as it’s populated.
 All following nominations and de-nominations will be done according to the 
 approved core-dev process [2].
 
 
 References:
 
 1. http://lists.openstack.org/pipermail/openstack-dev/2015-January/055038.html
 2. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
 
 
 - romcheg
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] 10Gbe performance issue.

[Tomasz Napierala]

 On 20 Jan 2015, at 17:14, Piotr Korthals piotr.korth...@intel.com wrote:
 
 Hi,
 
 I am facing issue with performance of 10 Gigabit Ethernet.
 
 Environment 2 hosts each:
 - 2 * Intel(R) Xeon(R) CPU E5-2690 v2
 - Intel 82599ES 10Gb Ethernet
 - 128GB RAM
 
 System:
 - Centos 6.5 delivered by fuel 6.0
 
 iperf during test of network performance over single stream report 2,5-3Gbps 
 (when using 4+ connection, cumulative transfer can hit over 9Gbps)
 
 For comparison, same test was run on official Centos 6.5 with result at 
 minimum 9,3 Gbps
 
 In both cases default MTU 1500 was set.
 
 From my analyses it looks like something is limiting i/o performance per 
 stream.
 
 Are you aware of this issue, and can you comment on it?
 
 This is critical for our deployment.

How this was measured? VM to VM? Compute to compute? In any case, what is your 
deployment configuration, especially VLAND or GRE, networking gear, etc.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

 On 14 Jan 2015, at 09:18, Przemyslaw Kaminski pkamin...@mirantis.com wrote:
 
 I just made a general remark regarding why migrating to 2.7 is
 profitable (I understood Bartek's question this way).
 
 The point about Red Hat guaranteeing security fixes to 2.6 is a good
 one. Also, it's true we don't use SSL for fuelclient so yes, if other
 OpenStack projects keep 2.6 we should stick to it also.

I have problems understanding this „SSL” case. It was just one example, and I 
mean security support in general.

For me it does not matter that RH provides security fixes. They do it, because 
with their enterprise policies they need to. We could use their fixces, but in 
our case it would also require supporting other distros (Ubuntu for now). 

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

 On 14 Jan 2015, at 08:50, Kamil Sambor ksam...@mirantis.com wrote:
 
 Tomasz we are not using ssl in our client so now we not gain anything from 
 moving to 2.7 .

I meant „security support” in terms of fixing security issues within Python 
itself. For 2.6.x line it’s over, as Przemek mentioned above:

With the 2.6.9 release, and five years after its first release, the Python 2.6 
series is now officially retired. All official maintenance for Python 2.6, 
including security patches, has ended. 

REgards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

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

This looks like final word here. We cannot provide software, that has no 
security support.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Zabbix in HA mode

[Tomasz Napierala]

Hi Andrew and all!


 On 05 Jan 2015, at 22:05, Andrew Woodward xar...@gmail.com wrote:
 
 On Tue, Nov 25, 2014 at 5:21 AM, Bartosz Kupidura
 bkupid...@mirantis.com wrote:
 
 Hello All,
 
 Im working on Zabbix implementation which include HA support.
 
 Zabbix server should be deployed on all controllers in HA mode.
 
 This needs to be discouraged as much as putting mongo-db on the controllers.

We know that, and we can use UI warning for that. For the reasons Mike provided 
our users need it. 

 
 
 When zabbix component is enabled, we will install zabbix-server on all 
 controllers
 in active-backup mode (pacemaker+haproxy).
 
 Again, not forced on controllers, this is very bad.
 
 
 Controllers:
 
 While there is development use cases to deploy monitoring on combined
 controllers, and it can make use of the already existing pacemaker
 cluster, this is the wrong direction to point users. There are many
 reasons this is bad: for one, monitoring can become quite loaded, and
 as we've seen secondary load on the controllers can collapse the
 entire control plane. Secondly running monitoring on the cluster may
 also result in the monitoring going offline if the cluster does, from
 my own experience, not being able to see your monitoring is nearly
 worse than having everything down and leads to lost precious moments
 of downtime SLA.
 
 HA Scaling:
 
 Just like with controllers, our other HA components need to support a
 scale of 1 to N. This is important as a cluster will need to scale, or
 as the operator moves from POC to Production, they can deploy more
 hardware. This also helps alleviate some of the not enough nodes
 issues mentioned in the thread already


Your concenrs are 100% valid and I agree with them. But what about small 
instalaltions, where only 4 physical machines are available? We are already 
wasting one for Fuel node, and 3 for controllers. There is hardware with 
similar setup and it seems to be very popular. This is what we are trying to 
address.


Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Bootstrap NTP sync.

[Tomasz Napierala]

 On 19 Dec 2014, at 10:00, Stanislaw Bogatkin sbogat...@mirantis.com wrote:
 
 Hi guys,
 
 We have a little concern related to Fuel bootstrap node NTP sync. Currently 
 we trying to sync time on bootstrap node with master node, but problem is 
 that NTP protocol has long convergence time, so if we just install master 
 node and right after that try to start some bootstrap node - bootstrap fails 
 to sync time with master due to that fact that master doesn't appear as 
 trust time source at that moment.
 How we can solve that problem:
 
 1. We can start bootstrap long time after master (when master will 
 convergence it's time) - seems that it's a bad idea, cause master node 
 convergence time depends on upstream NTP servers and may be quite long - user 
 shouldn't wait so long time to just start bootstrap node.
 
 2. We can use master local time as trust forcibly - actually, we already do 
 that for case when master is a bare metal node. We can do it for virtual node 
 too, it is not such bad idea as many can say, especially when master node 
 stratum will low (10-12).
 
 3. We can mask return value for bootstrap node ntpdate service such way that 
 it always will return success - it's a dirty hack, it will calm down 
 customers, but it doesn't solve problem - time will be unsynced.
 
 As for me - second option is best. What do you think about it?

Second option looks best, although it’s still against standards. I guess that 
if we provide possibility to deifne external NTP server as an alternative, we 
are hsfa here and can live with that.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

Also +1 here.
In huge envs we already have problems with parsing performance. In long long 
term we need to think about other log management solution


 On 12 Dec 2014, at 23:17, Igor Kalnitsky ikalnit...@mirantis.com wrote:
 
 +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 dpyz...@mirantis.com 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 logs in strange format with extra copy of
 timestamp and loglevel:
 == ./neutron-metadata-agent.log ==
 2014-12-12T11:00:30.098105+00:00 info: 2014-12-12 11:00:30.003 14349 INFO
 neutron.common.config [-] Logging enabled!
 
 And we have a workaround for this. We hide extra timestamp and use second
 loglevel.
 
 In Juno some of services have updated oslo.logging and now send logs in
 simple format:
 == ./nova-api.log ==
 2014-12-12T10:57:15.437488+00:00 debug: Loading app ec2 from
 /etc/nova/api-paste.ini
 
 In order to keep backward compatibility and deal with both formats we have a
 dirty workaround for our workaround:
 https://review.openstack.org/#/c/141450/
 
 As I see, our best choice here is to throw away all workarounds and show
 logs on UI as is. If service sends duplicated data - we should show
 duplicated data.
 
 Long term fix here is to update oslo.logging in all packages. We can do it
 in 6.1.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Hard Code Freeze for 6.0

[Tomasz Napierala]

Hi,

As with 5.1.x, please inform the list if you are rising priority to critical in 
any bugs targeted to 6.0.

Regards,

 On 09 Dec 2014, at 23:43, Mike Scherbakov mscherba...@mirantis.com wrote:
 
 Hi all,
 I'm glad to announce that we've reached Hard Code Freeze (HCF) [1] criteria 
 for 6.0 milestone. 
 
 stable/6.0 branches for our repos were created.
 
 Bug reporters, please do not forget to target both 6.1 (master) and 6.0 
 (stable/6.0) milestones since now. If the fix is merged to master, it has to 
 be backported to stable/6.0 to make it available in 6.0. Please ensure that 
 you do NOT merge changes to stable branch first. It always has to be a 
 backport with the same Change-ID. Please see more on this at [2].
 
 I hope Fuel DevOps team can quickly update nightly builds [3] to reflect 
 changes.
 
 [1] https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze
 [2] 
 https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series
 [3] https://fuel-jenkins.mirantis.com/view/ISO/
 
 Thanks,
 -- 
 Mike Scherbakov
 #mihgen
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

 On 24 Nov 2014, at 11:09, Sergii Golovatiuk sgolovat...@mirantis.com wrote:
 
 Hi,
 
 monasca looks overcomplicated for the purposes we need. Also it requires 
 Kafka which is Java based transport protocol.
 I am proposing Sensu. It's architecture is tiny and elegant. Also it uses 
 rabbitmq as transport so we won't need to introduce new protocol.

Do we really need such complicated stuff? Sensu is huge project, and it's 
footprint is quite large. Monit can alert using scripts, can we use it instead 
of API?

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Power management in Cobbler

[Tomasz Napierala]

 On 19 Nov 2014, at 16:10, Vladimir Kozhukalov vkozhuka...@mirantis.com 
 wrote:
 
 I am absolutely -1 for using Cobbler for that. Lastly, Ironic guys became 
 much more open for adopting new features (at least if they are implemented in 
 terms of Ironic drivers). Currently, it looks like we are  probably able to 
 deliver zero step Fuel Ironic driver by 6.1. Ironic already has working IPMI 
 stuff and they don't oppose ssh based power management any more. Personally, 
 I'd prefer to focus our efforts towards  Ironic stuff and keeping in mind 
 that Cobbler will be removed in the nearest future. 

I know that due to time constraints we would be better to go with Cobbler, but 
I also think we should be closer to the community and switch to Ironic as soon 
as possible. 

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Power management in Cobbler

[Tomasz Napierala]

 On 19 Nov 2014, at 17:56, Fox, Kevin M kevin@pnnl.gov wrote:
 
 Would net booting a minimal discovery image work? You usually can dump ipmi 
 network information from the host.
 

To boot from minimal iso (which is waht we do now) you still need to tell the 
host to do it. This is where IPMI discovery is needed I guess.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tomasz Napierala]

On 06 Nov 2014, at 12:20, Przemyslaw Kaminski 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 to document ways to clean up space. 
We could also add some kind of simple job to remove rotated logs, obsolete 
spanshots, etc., but this is out of scope for 6.0 I guess.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel]

[Tomasz Napierala]

On 12 Nov 2014, at 17:56, foss geek thefossg...@gmail.com wrote:

 
 I am reading Fuel reference-architecture documentation in the below link:
 
 http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture
 
 In the page no 2 note says:
 
 Note
 
 In environments that use vCenter as the hypervisor, the Nova-compute service 
 can run only on Controller nodes. 
 
 Is it specific to Fuel? 
 
 Let say I deployed a environment (controller + compute + storage) with KVM as 
 the hypervisor and later manually doing all the necessary configuration 
 change to make compute node with vCenter as the hypervisor.  In this case 
 does Nova-compute (running in compute-node) service work with vCenter? 
 

This is Fuel specific. We’ve just decided to put nova-compute responsible to 
control vCenter on controller nodes. You can configure it on any node you want, 
similar to any other service. You just need to take care of access to vCenter 
control plane.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Backup of information about nodes.

[Tomasz Napierala]

On 22 Oct 2014, at 21:03, Adam Lawson alaw...@aqorn.com wrote:

 What is current best practice to restore a failed Fuel node?

It’s documented here:
http://docs.mirantis.com/openstack/fuel/fuel-5.1/operations.html#restoring-fuel-master

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Tomasz Napierala]

On 10 Oct 2014, at 11:35, Vladimir Kuklin vkuk...@mirantis.com wrote:

 Hi, Fuelers
 
 As you may have noticed our project is growing continuously. And this imposes 
 a requirement of increasing amount of core reviewers. I would like to propose 
 Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core reviewers. As 
 you know, they have been participating actively in development, design and 
 code review of the majority of project components as long as being our 
 topmost reviewers and contributors (#2 and #3) [1 and 2] (not to mention 
 being just brilliant engineers and nice people).
 
 Please, reply to my message if you agree or disagree separately for Bogdan 
 and Sergii (this is mandatory for existing core-reviewers).
 
 [1] http://stackalytics.com/report/contribution/fuel-library/90 
 [2] http://stackalytics.com/report/contribution/fuel-library/180

Strong +1 for both.

-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF

[Tomasz Napierala]

On 11 Sep 2014, at 09:19, Mike Scherbakov mscherba...@mirantis.com wrote:

 Hi all,
 what about using experimental tag for experimental features?
 
 After we implemented feature groups [1], we can divide our features and for 
 complex features, or those which don't get enough QA resources in the dev 
 cycle, we can declare as experimental. It would mean that those are not 
 production ready features.
 Giving them live still in experimental mode allows early adopters to give a 
 try and bring a feedback to the development team.
 
 I think we should not count bugs for HCF criteria if they affect only 
 experimental feature(s). At the moment, we have Zabbix as experimental 
 feature, and Patching of OpenStack [2] is under consideration: if today QA 
 doesn't approve it to be as ready for production use, we have no other 
 choice. All deadlines passed, and we need to get 5.1 finally out.
 
 Any objections / other ideas?

+1

-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Re: SSL in Fuel.

[Tomasz Napierala]

On 10 Sep 2014, at 12:54, Simon Pasquier spasqu...@mirantis.com wrote:

 Hello,
 
 Lets back up a bit and list the different options for Fuel users:
 0/ The user is happy with plain HTTP.
 = Already supported :)
 1/ The user wants HTTPS but doesn't want the burden associated with 
 certificate management.
 = Fuel creates and manages the SSL certificates, be them self-signed or 
 signed by some internal CA.
 = Using an internal CA instead of multiple self-signed certificates is 
 cleaner as you explained.
 2/ The user wants HTTPS and wants to use certificates which are generated by 
 an external source (either some internal corporate PKI or some public 
 certificate authority)
 = Fuel supports certificate + key uploads
 = It should be possible to tell Fuel which entity (Fuel, OSt environment) 
 uses which certificate
 3/ The user wants HTTPS and agrees to let Fuel generating certificates on 
 behalf of some corporate PKI.
 = Fuel supports CA + key uploads
 
 I think that option 1 is the way to go for a first approach. Option 2 is 
 definitely something that end-users would need at some point. I'm less 
 convinced by option 3: if I were a PKI admin, I'll be reluctant to let Fuel 
 generate certificates on its own. Also my gut feeling tells me that 
 implementing 1  2 is already quite a lot of work.
 
 I've also added some questions/comments inline.

Regarding 
After careful consideration, I think that for 6.0 we will only be able to 
implement [2] with limited functionality. In terms of certificate management, 
we could offer uploading customer generated cert (and maybe provide shot doc on 
how to spawn CA + sign certs) or if user does not want to do it, generate 
simple self signed cert and install it on Fuel http server and let user 
download it. 

After 6.0 we can concentrate on proper implementation of CA management, and 
then allow Fuel master node part to use it.

[1] https://blueprints.launchpad.net/fuel/+spec/ca-deployment
[2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints
[3] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Blueprints process

[Tomasz Napierala]

On 06 Aug 2014, at 10:41, Sergii Golovatiuk sgolovat...@mirantis.com wrote:

 Hi,
 
 I really like what Mike proposed. It will help us to keep milestone clean and 
 accurate.

+1 for Mike’s proposal. New members will also benefit from that move: clean 
picture will make easier to pick up features to work on.

Regards,
-- 
Tomasz Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com






___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev