On 07/23/2015 10:45 AM, Lance Bragstad wrote:
On Wed, Jul 22, 2015 at 10:06 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 07/22/2015 05:39 PM, Adam Young wrote:
On 07/22/2015 03:41 PM, Morgan Fainberg wrote:
This is an indicator that the bottleneck is not
+1
On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
+1
On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com
wrote:
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
At the moment we have several core reviewers for
I'm against getting rid of fuelmenu. As Alex wrote - we need to remember
who are the people that we are targeting.
We are adding multiple dialog windows with confirmations, warnings and
special way to do dangerous actions
(like environment deletion or reset), but in the same time we want to force
+1
2015-07-23 19:23 GMT+02:00 Dmitry Borodaenko dborodae...@mirantis.com:
+1
On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
+1
On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com
wrote:
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov
On Thu, Jul 16, 2015 at 04:23:29PM -0400, Mathieu Gagné wrote:
Hi,
I stubble on this review [1] which proposes adding info about provider
networks in network_data.json.
snip
[1] https://review.openstack.org/#/c/152703/5
Just to loop back on this - we talked about it a bit at the Nova
On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote:
Hi all!
Currently _spawn_worker in the conductor manager raises
NoFreeConductorWorker if pool is already full. That's not very user friendly
(potential source of retries in client) and does not map well on common
async worker
On 07/23/2015 01:04 PM, Kevin L. Mitchell wrote:
On Thu, 2015-07-23 at 11:41 -0500, Sean Dague wrote:
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
In case you missed it, feature freeze is today and in the rush to merge
things, you may have had issues with getting everything landed.
For those that are not familiar with the process, to request a feature
freeze exception (FFE):
* You will need to raise the request to the ML here and in such
I'd like to say a few comments about topics which we didn't have time for:
* ubuntu based bootstrap has been merged, needs thorough testing
(kozhukalov)
great work, thanks Alexei Sheplyakov for working days and nights to get
this done. Thanks kozhukalov for helping him out and getting it into
Mike, thanks for the important points you've provided.
My main argument for this FFE is the following: we've already got a
confirmation from SME for this patch. But also got some not critical
comments at the last minute before we were going to merge it and have to
handle it now. But it looks that
While implementing my composition module, I've realized that
Swift_${type}_config resources should be applied AFTER
Concat['/etc/swift/${type}-server.conf'], otherwise the content defined in
the resource is overwritten by concat::fragment template.
It's my first time contributing and I still have
Thanks Andrew.
I'd like to add that after there is an announcement about FF, all core
reviewers should stop getting patches into master which are parts of
features or extensions. We expect only bugfixes. If there is anything else,
we need to be very transparent about it, and have them in public
On Thu, 2015-07-23 at 13:50 -0500, Sean Dague wrote:
Maybe a directory is fine, especially if module mapped to [subsection].
nova/config/
default.py
glance.py
...
which makes it reasonably discoverable and mappable back and forth from
config file to files.
I like that division
Hi all,
Log Working Group has been running weekly meetings Wednesdays at 20:00 UTC.
There were queries while back to adjust the meeting time to facilitate EMEA/APJ
folks bit better.
Current regular participants are fine with the time we're having the meeting
now, but we wanted to probe the
Yep, forgot to include the topics i referred to
Topics not covered in todays meeting, but requested in the agenda
* ubuntu based bootstrap has been merged, needs thorough testing
(kozhukalov)
* Let's switch keystone under Apache right after FF (adidenko)
* Separate services from controller
Agreed, everyone should do what they love - so I wish you the best of
luck with the Magnum crew Daneyon!
Op 22-07-15 om 22:47 schreef Steven Dake (stdake):
Fellow Kolla developers,
Daneyon has been instrumental in getting Kolla rolling and keeping our
project alive. He even found me a new
This is great news! I can see our two projects working close together since
we have aligned but not entirely overlapping goals.
Antoni, please reach out on IRC at any time. #kolla is active almost 24/7
due to all of our different timezones. There is usually two cores talking
at any given time. I
-1
My concerns are the following:
1. This feature is of a High priority, not Essential [1]
2. We already had to give exception for flexible networking CLI part
[2], as it is essential one. So basically that means we have a conflict of
focus for SMEs in the area.
3. Just by working
Alexander,
as this is purely Fuel related thing, please send a new one with right
subject. It has to be [fuel] in subject, and that's it. No MOS,
fuel-library, FFE please, we don't use any of those tags. No need to spam
Keystone team too, as it's configuration related to Fuel only at this point
of
As a courtesy to anyone who may have worked on it, I wanted to notify
the list that I'm going to delete [1] from wiki page [2]. I may actually
delete [2] completely. I'm going to update the content on [3] to
reference the new SFC API spec that has just been merged. Currently [3]
links to [2]
We ran in to this long ago.
What are some other examples? We've be good about keeping the network L2
only. Segments, VLAN transparency, and other properties of the network are
all L2.
The example you gave about needing the network to see the grouping of
subnets isn't the network leaking into L3,
+1
On Thu, Jul 23, 2015 at 10:50 AM Evgeniy L e...@mirantis.com wrote:
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
At the moment we have several core reviewers for the fuel-main project.
Roman Vyalov is responsible for merging of infrastructure-related
Colleagues,
I would like to request an exception from the Feature Freeze for Fernet
tokens support added to the fuel-library in the following CR:
https://review.openstack.org/#/c/201029/
Keystone part of the feature is implemented in the upstream and the change
impacts setup configuration only.
That's my fault, I asked him to send it as I thought it also required
review for FFE.
On Jul 23, 2015 1:45 PM, Mike Scherbakov mscherba...@mirantis.com wrote:
Alexander,
as this is purely Fuel related thing, please send a new one with right
subject. It has to be [fuel] in subject, and that's
I was referring to the HTML reports that the karma-coverage plugin creates for
now. From my experience with it, it’s fairly relaxed about what counts as
something being tested, hence the 100% aim. For example, often just checking
that a value is defined is enough for it to be “tested”, and this
Hi Julia,
I'm ok with FF exception for CLI part. I don't think it can somehow
decrease product quality, so as a core I'll help to land it.
Thanks,
Igor
On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich
jkirnos...@mirantis.com wrote:
Team,
I would like to request an exception from the Feature
-- Forwarded message --
From: Alexander Makarov amaka...@mirantis.com
Date: Thu, Jul 23, 2015 at 5:30 PM
Subject: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for
Fernet tokens support.
To: Vitaly Sedelnik vsedel...@mirantis.com, Eugene Bogdanov
Hi,
The patch into Nailgun requires additional work to do, but as far as I can
see
it doesn't affect any other parts of the system, also it's implemented as an
extension, which means if the feature will introduce bugs which we won't
be able to fix in a required time, it can be easily disabled
Morgan asked me to post some of my numbers here. From my staging
environment:
With 0 revocations:
Requests per second:104.67 [#/sec] (mean)
Time per request: 191.071 [ms] (mean)
With 500 revocations:
Requests per second:52.48 [#/sec] (mean)
Time per request: 381.103 [ms]
On Thu, 2015-07-23 at 11:41 -0500, Sean Dague wrote:
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing
For my low-orbit perspective (I would have lied if I said 10,000 or 30,000
ft!) Kuryr's ultimate goal is to provide:
1) a container-oriented set of neutron plugins and drivers (you know the
ML2 driver, a l3 svc plugin, a lbaas driver, etc. etc.)
2) possibly (I'm not sure if that's the case)
Today's meeting was a little hectic, if you have a topic on the agenda,
ensure you are present and ready to speak, or move your topic lower in the
agenda. When possible, pre-type you main points of discussion and copy and
paste it into the channel when your topic comes up. This tends to save a
bit
+1 for Monday
On Wed, Jul 22, 2015 at 10:29 PM, Mohammad Banikazemi m...@us.ibm.com wrote:
Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I
realize there are several networking related weekly meetings, but I would
like to see if we can find a different time. I suggest
I let the creators of the project speak for themselves but here is my take
on project Kuryr.
The goal is not to containerize Neutron or other OpenStack services. The
main objective is to use Neutron as a networking backend option for Docker.
The original proposal was to do so in the context of
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
At the moment we have several core reviewers for the fuel-main project.
Roman Vyalov is responsible for merging of infrastructure-related
variables and for the lists of packages.
I am responsible for merges in
+1 for this FFE as it's important to have this functionality covered in CLI
2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com:
Hi Julia,
I'm ok with FF exception for CLI part. I don't think it can somehow
decrease product quality, so as a core I'll help to land it.
Thanks,
2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com:
Hi,
can we just add all needed functionality from old fuel client that fuel2
needs, then say that old fuel-client is deprecated now and will not support
some new features, then add new features to fuel2 only? It seems like
On 07/23/2015 01:11 PM, melanie witt wrote:
On Jul 23, 2015, at 7:35, Adam Young ayo...@redhat.com wrote:
What this means is the if a user is assigned admin on any project, they are
assigned admin for everything.
Fixing this is going to require a change to how we write policy.
Each policy
Oleg,
considering that your feature is essential for the release, sounds like
there is no way we can't give an exception.
I'm glad that it's perceived by low risk by core reviewer from Nailgun team
(Evgeny). If there are no concerns from other, then we are giving FF
exception. However, I'd like
On Thu, Jul 23, 2015 at 7:35 PM, Mohammad Banikazemi m...@us.ibm.com wrote:
I let the creators of the project speak for themselves but here is my take
on project Kuryr.
The goal is not to containerize Neutron or other OpenStack services. The
main objective is to use Neutron as a networking
Looks like the only CLI part left: https://review.openstack.org/#/c/204321/,
and you guys did a great job finishing the other two.
Looks like we'd need to give FF exception, as this is essential feature.
It's glad that we merged all other thousands lines of code. This is the
most complex feature,
Hello,
After a discussion in our weekly meeting[1] and in a ML thread[2] we have
decided to retire the heat-coe-templates[3] repository and move it to
openstack-attic[4].
Initially this repository was intended to replace heat-kubernetes[5] and the
templates in the Magnum repo. However the
Dmitry Tantsur wrote:
Jim,
I'm redirecting your question to oslo folks, as I'm afraid my answer can
be wrong.
On 07/23/2015 01:55 PM, Jim Rollenhagen wrote:
On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote:
Hi all!
Currently _spawn_worker in the conductor manager raises
+1
On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com wrote:
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
At the moment we have several core reviewers for the fuel-main project.
Roman Vyalov is responsible for merging of
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing those per-package (per backend,
per driver, etc), rather than
The topic is NOT 'get rid of validation' but rather 'get rid of
semi-graphical ncurses based interface'. It is not so hard to adopt every
piece of validation we currently have in fuelmenu and implement even more
including syntax validation using, for example, PLY and logic validation.
My idea is
John Belamaric made a good point that the closest thing that we have to
representing an L3 domain right now is a subnet pool.
This is actually a really good point. If you take the example of a L3 network
that spans segments, you could put something like a /16 into a subnet pool.
That /16
On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton blak...@gmail.com wrote:
I proposed the port scheduling RFE to deal with the part about selecting a
network that is appropriate for the port based on provided hints and
host_id. [1]
Thanks for the pointer. I hadn't paid much attention to this RFE
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing those per-package (per backend,
per driver, etc), rather than per Python module to reduce the number
of possible
On 07/23/2015 12:13 PM, Jay Pipes wrote:
On 07/23/2015 10:53 AM, Bunting, Niall wrote:
Hi,
Currently when a body is passed to an API operation that explicitly
does not allow bodies Glance throws a 500.
Such as in this bug report:
https://bugs.launchpad.net/glance/+bug/1475647 This is an
On 07/23/2015 11:41 AM, Sean Dague wrote:
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing those per-package (per
Because of a faulty test, we've been merging some bad requirements
changes. Please do not approve any more changes until the fixes for the
tests have been merged:
https://review.openstack.org/#/c/204181
https://review.openstack.org/#/c/204198
Thanks,
Doug
For this to be consumable by end-users, a config file and editor (vim
seriously?) is terrible UX. We need to remember who we are targeting to
consume this functionality as it may not be an expert or even someone
absolutely familiar with the linux tool set. While the existing thing may
be
Hi all,
I have some thoughts about congress dse improvement after having read the code
for several days.
Please refer to
bp/rpc-for-dsehttps://blueprints.launchpad.net/congress/+spec/rpc-for-dse,
its idea is to implement RPC in deepsix. Congress can benefit from
lower-coupling between dse
See below
On 21/07/15 20:29, Derek Higgins wrote:
Hi All,
Something we discussed at the summit was to switch the focus of
tripleo's deployment method to deploy using instack using images built
with tripleo-puppet-elements. Up to now all the instack work has been
done downstream of tripleo
Hi,
We had a question from our OSS team about the level of support of BPMN in
Mistral,
Is there any plan to include that support? Did you heard from other people on
the community around the need for that?
Thanks,
Noy
__
Congratulations Cedric. ☺
From: Miguel Lavalle [mailto:mig...@mlavalle.com]
Sent: Wednesday, July 22, 2015 10:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron
Core Reviewer Team
Congrats Cedric!
Hi, all
The Jenkins jobs submitted by zuul are always pending—Waiting for next
available executor .
And Jenkins log shows the following:
Jul 24, 2015 11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl
submitFunction
WARNING: Worker _exec-0 exception while executing function
Interesting, It would be great to know what causes the crash if you can
identify it.
What was previously between the designate components and qpid? Simple
router? Stateful firewall? Something else?
Thanks,
Kiall
On 22/07/15 10:53, Jaime Fernández wrote:
I moved the virtual machine where
Hello, all,
Welcome to review and comment on the open design of tricircle, the first BP
https://blueprints.launchpad.net/tricircle/+spec/new-design
Detailed discussion can also be found on the weekly meeting log:
https://wiki.openstack.org/wiki/Meetings/Tricircle
Best Regards
Chaoyi Huang (
Hi Yingxin,
I think moving Congress from dse to rpc is a good idea.
Congress team will discuss its scalability in mid cycle sprint[1], [2].
I guess using rpc is one of key item for congress to get the ability.
Why don't you join the meetup?
[1]
Hi folks,
For a some time in python-fuelclient we have two CLI apps: `fuel` and
`fuel2`. It was done as an implementation of blueprint [1].
Right now there is a situation where some new features are added just to
old `fuel`, some to just `fuel2`, some to both. We cannot simply switch
completely
101 - 162 of 162 matches
Mail list logo
