On 10 Sep 2014, at 12:54, Simon Pasquier 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.
> =>
On 11 Sep 2014, at 09:19, Mike Scherbakov 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 c
> On 19 Nov 2014, at 16:10, Vladimir Kozhukalov
> 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
> On 19 Nov 2014, at 17:56, Fox, Kevin M 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
> On 21 Nov 2014, at 17:15, Aleksandr Didenko wrote:
>
> Hi,
>
> following our docs/workflow plus writing rspec tests for every new option we
> add/modify in our manifests could help with regressions. For example:
> • we add new keystone config option in openstack::keystone class -
> ke
> On 21 Nov 2014, at 16:55, Dmitry Pyzhov wrote:
>
> We have a request for change compression from gz to xz. This simple change
> halfs our snapshots. Does anyone has any objections? Otherwise we will
> include this change in 6.0 release.
I agree with the change, but it shouldn’t be high
Reg
> On 24 Nov 2014, at 11:09, Sergii Golovatiuk 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 w
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 wrote:
>
> Hi all,
> I'm glad to announce that we've reached Hard Code Freeze (HCF) [1] criteria
> for 6.0 milestone.
>
> stabl
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 wrote:
>
> +1 to stop parsing logs on UI and show them "as is". I think it's more
> than enough for al
> On 19 Dec 2014, at 10:00, Stanislaw Bogatkin 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 m
Hi Andrew and all!
> On 05 Jan 2015, at 22:05, Andrew Woodward wrote:
>
> On Tue, Nov 25, 2014 at 5:21 AM, Bartosz Kupidura
> wrote:
>>
>> Hello All,
>>
>> Im working on Zabbix implementation which include HA support.
>>
>> Zabbix server should be deployed on all controllers in HA mode.
>
> On 13 Jan 2015, at 10:51, Przemyslaw Kaminski 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 SS
> On 14 Jan 2015, at 08:50, Kamil Sambor 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
> On 14 Jan 2015, at 09:18, Przemyslaw Kaminski 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
> On 20 Jan 2015, at 17:14, Piotr Korthals 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
>
> ip
+1
> On 26 Jan 2015, at 11:33, Roman Prykhodchenko 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-cor
On 10 Oct 2014, at 11:35, Vladimir Kuklin 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 rev
On 22 Oct 2014, at 21:03, Adam Lawson 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...@miranti
On 06 Nov 2014, at 12:20, Przemyslaw Kaminski 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 rem
On 12 Nov 2014, at 17:56, foss geek 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 enviro
s 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
> 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 - tha
> 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 accou
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 F
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 ag
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:
> On 27 Aug 2015, at 07:58, Evgeniy L 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 r
> 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
> *
> 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 contribut
> 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'
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
set up?
>
> On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky
> 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
> wrote:
> >
+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
> On 02 Jul 2015, at 06:59, Mike Scherbakov wrote:
>
> Alex - congratulations! Added you to fuel-library core.
>
Also congrats from me, well deserved!
Regards,
--
Tomasz 'Zen' Napierala
Product Engineering - Poland
_
> 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
+1, long awaited
> On 27 Jan 2015, at 14:05, Aleksandr Didenko 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 mo
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 wrote:
>
> Guys, could you point out where I suggested to use python for testing puppet
> manifests?
>
> On Thu,
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
> wrote:
>
> FYI, xz with multithreading support (5.2 release) has been marked as stable
> y
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 wrote:
>
> I totally agree with Andrew.
>
> On Tuesday, February 3, 2015
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 though
> On 10 Feb 2015, at 23:02, Andrew Woodward 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
> On 09 Mar 2015, at 18:21, Ryan Moe 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
> On 17 Mar 2015, at 01:12, Andrew Woodward 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, bu
+1 definately
> On 25 Mar 2015, at 20:10, Dmitry Borodaenko 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:
Congratulations Sebastian!
Regards
> On 15 Apr 2015, at 10:06, Igor Kalnitsky 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
> wrote:
>> +1
>>
>> --
>> Best regards,
>> Sergii Gol
Do you mean single node?
> On 15 Apr 2015, at 17:04, Dmitry Pyzhov 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,
gt;
> On Wed, Apr 15, 2015 at 6:38 PM, Tomasz Napierala
> wrote:
>> Do you mean single node?
>>
>>> On 15 Apr 2015, at 17:04, Dmitry Pyzhov wrote:
>>>
>>> FYI. We are going to disable Multi-node mode on UI even in experimental
>>&
> On 17 Apr 2015, at 14:35, Maciej Kwiek 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
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 wrote:
>
> -1 for upgrading it in 6.1. Known devil is better than unknown angel :)
>
> In 7.0 we can
49 matches
Mail list logo
