On 5/29/14 8:52 AM, James E. Blair wrote:
Devananda van der Veen devananda@gmail.com writes:
Hi all!
This is a follow-up to several summit discussions on
how-do-we-deprecate-baremetal, a summary of the plan forward, a call to
raise awareness of the project's status, and hopefully gain
Thanks for putting this together Jaromir!
August 1 may be a problem for those of us from Australia - it's the day of
the OpenStack miniconf at Pycon-AU.
I don't know if any of us intended to go to that, but if we did we'd need
to leave no later than the 4:40pm flight on July 30 in order to make
Hi Gabriel,
thanks for joining the conversation. It is a quite old discussion that was
also discussed at the Atlanta design summit, and it seems that the moment
this to happen had finally come. It is always nice to hear the opinion of a
real Django core developer.
Just a follow-up from the
On 28/05/14 17:57, Kyle Mestery wrote:
On Wed, May 28, 2014 at 12:41 AM, mar...@redhat.com mandr...@redhat.com
wrote:
On 27/05/14 17:14, Kyle Mestery wrote:
Hi Neutron developers:
I've spent some time cleaning up the BPs for Juno-1, and they are
documented at the link below [1]. There are
Is there any wiggle room on those dates? As James Polley says, PyCon
AU (and the Openstack miniconf, which I'm organising with JHesketh)
overlap significantly - and I can't be in two places at once.
However July 21-25th would be totally doable :)
-Rob
On 28 May 2014 23:05, Jaromir Coufal
Just chiming in with a side-note.
I always liked the idea of Postern for things like this though the crypto
geek in me always worries about making key retrieval too easy for
developers, bad things happen down that road.
The OSSG can help with overall secure design and would be happy to consult
Hi All,
The reason I ask this question in openstack-dev is there is a lot of
confusion going around other projects moving to keystone v3. Would it be a
problem if I use keystone v3 api for authenticating and point other
services to use keystone v2 with keystone v3 token? The main issue here is
On 28/05/14 17:01 +, Kurt Griffiths wrote:
Crew, as discussed in the last team meeting, I have updated the API v1.1 spec
to remove the ability to get one or more messages by ID. This was done to
remove unnecessary complexity from the API, and to make it easier to support
different types of
Could we replace the refresh from the period task with a timestamp in the
network cache of when it was last updated so that we refresh it only when it’s
accessed if older that X ?
From: Aaron Rosen [mailto:aaronoro...@gmail.com]
Sent: 29 May 2014 01:47
To: Assaf Muller
Cc: OpenStack Development
On 05/27/14 16:44, Bartosz Kupidura wrote:
Hello,
Responses inline.
Wiadomość napisana przez Vladimir Kuklin vkuk...@mirantis.com w dniu 27 maj
2014, o godz. 15:12:
Hi, Bartosz
First of all, we are using openstack-dev for such discussions.
Second, there is also Percona's RA for
Hi, stackers
if i define provider when creating network, but no segmentation_id,
net-create fail. why not allocate segmentation_id automatically?
~$ neutron net-create test --provider:network_type=vlan --provider:physical_
network=default
Invalid input for operation: segmentation_id required for
Hey Mainn,
mostly it is driven by following requirements:
https://etherpad.openstack.org/p/ironic-ui
plus what you already know from Tuskar point of view - which is simply
monitoring, monitoring, monitoring :)
Hope it helps
-- Jarda
On 2014/29/05 05:51, Tzu-Mainn Chen wrote:
Hi Jarda,
Hi everyone,
Recently, wrapt was added as a dependency. The Python module suffers
from obvious design issues, like for example:
- Lack of Python 3.4 support
- Broken with Python 3.2
- Upstream sources in src instead of wrapt so then running py.test
doesn't work unless you do ln -s src wrapt, and
Sean Dague wrote:
I honestly just think we might want to also use it as a time to rethink
our program concept. Because all our programs that include projects that
are part of the integrated release are 1 big source tree, and maybe a
couple of little trees that orbit it (client and now specs
Hi James,
that's a good point. I just restructured the etherpad so that there are
3 sections: one is for July 28 - Aug 1, second is for July 21-25 and
third one is for those who want to attend but can't make it within
suggested dates. So I would like to encourage everybody who is willing
to
On Thu, May 29, 2014 at 04:29:34AM +, Tracy Jones wrote:
Hi Folks - I spoke with Michael at the summit about bug management for
Juno. Other than tagging the untagged bugs each week,
I'm try to do that (and some triage/root-cause analysis for
libvirt/QEMU/KVM-based bugs and would like to
Hi, Folks,
When we configure VXLAN range [1,16M], neutron-server service costs long
time and cpu rate is very high(100%) when initiation. One test base on
postgresql has been verified: more than 1h when VXLAN range is [1, 1M].
So, any good solution about this performance issue?
Thanks,
Xurong
On 05/29/2014 05:26 AM, Thierry Carrez wrote:
Sean Dague wrote:
I honestly just think we might want to also use it as a time to rethink
our program concept. Because all our programs that include projects that
are part of the integrated release are 1 big source tree, and maybe a
couple of
On 05/28/2014 10:03 PM, Gabriel Hurley wrote:
It's sort of a silly point, but as someone who would likely consume the
split-off package outside of the OpenStack context, please give it a
proper
name instead of django_horizon. The module only works in Django, the
name
adds both clutter and
may be the problem is that you are using liftetime crm attributes instead
of 'reboot' ones. shadow/commit is used by us because we need transactional
behaviour in some cases. if you turn crm_shadow off, then you will
experience problems with multi-state resources and
location/colocation/order
Hi,
vxlan network are inserted/verified in DB one by one, which could explain
the time required
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vxlan.py#L138-L172
Cédric
On Thu, May 29, 2014 at 12:01 PM, Xurong Yang ido...@gmail.com wrote:
Hi, Folks,
Hi,
Just a reminder that the weekly Nova API meeting is being held tomorrow
Friday UTC .
We encourage cloud operators and those who use the REST API such as
SDK developers and others who and are interested in the future of the
API to participate.
In other timezones the meeting is at:
EST
On Wed, May 28, 2014 at 10:18 PM, Jaromir Coufal jcou...@redhat.com wrote:
Hi All,
There is a lot of tags in the subject of this e-mail but believe me that all
listed projects (and even more) are relevant for the designs which I am
sending out.
Nodes management section in Horizon is being
Hello,
Wiadomość napisana przez Vladimir Kuklin vkuk...@mirantis.com w dniu 29 maj
2014, o godz. 12:09:
may be the problem is that you are using liftetime crm attributes instead of
'reboot' ones. shadow/commit is used by us because we need transactional
behaviour in some cases. if you
Comment inline at bottom of message...
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: 06 May 2014 18:44
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Question about addit log in nova-compute.log
On 05/06/2014 01:37 PM, Jiang, Yunhong
On 5/29/2014 4:41 AM, Xurong Yang wrote:
Hi, stackers
if i define provider when creating network, but no segmentation_id,
net-create fail. why not allocate segmentation_id automatically?
~$ neutron net-create test --provider:network_type=vlan
--provider:physical_network=default
Invalid
On 28 May 2014, at 20:02, Sergey Lukjanov slukja...@mirantis.com wrote:
Hey folks,
it's a small wrap-up for the topic Sahara subprojects releasing and
versioning that was discussed partially on summit and requires some
more discussions. You can find details in [0].
common
We'll
On 05/28/2014 12:37 PM, Dat Tran wrote:
Hi everyone,
I have a idea for new project: Mahout-as-a-service.
Main idea of this project:
- Install OpenStack
- Deploying OpenStack Sahara source
- Deploying Mahout on Sahara OpenStack system.
- Construction of the API.
Through web or mobile interface,
On 05/29/2014 07:23 AM, Alexander Ignatov wrote:
On 28 May 2014, at 20:02, Sergey Lukjanov slukja...@mirantis.com wrote:
sahara-image-elements
We're agreed that some common parts should be merged into the
diskimage-builder repo (like java support, ssh, etc.). The main issue
of keeping
On 28 May 2014, at 17:14, Sergey Lukjanov slukja...@mirantis.com wrote:
1. How should we handle addition of new functionality to the API,
should we bump minor version and just add new endpoints?
Agree with most of folks. No new versions on adding new endpoints.
Semantic changes require new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 28/05/14 23:03, Nachi Ueno wrote:
Hi folks
OK, so it looks like this is consensus in the community,
Link bug or bp for most of commit Exception for not linking bug:
(1) Infra sync (2) minor fix. (typo, small code refactor, fix doc
On 29/05/14 00:48, Eugene Nikanorov wrote:
Hi,
I have two questions that previously were briefly discussed. Both of them
still cause discussions within advanced services community, so I'd like to
make final clarification in this email thread.
1. Usage of Service Type Framework
I think
+1 to Carlos.
In addition, there should be possible for LBaaS (It might only be just the
LBaaS drivers) to get the information including the private key back so that
the backend can use it.
This means that a trusted communication channel between the driver and
Barbican needs to be established
From: Kieran Spear [mailto:kisp...@gmail.com]
Sent: 28 May 2014 06:05
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] nova default quotas
Hi Joe,
On 28/05/2014, at 11:21 AM, Joe Gordon
joe.gord...@gmail.commailto:joe.gord...@gmail.com
On Thu, 2014-05-29 at 11:26 +0200, Thierry Carrez wrote:
Back to the topic, the tension here is because DNS is seen as a
network thing and therefore it sounds like it makes sense under
Networking. But programs are not categories or themes. They are
teams aligned on a mission statement. If the
On Thu, 2014-05-29 at 08:00 +0930, Michael Davies wrote:
On Thu, May 29, 2014 at 4:22 AM, Sean Dague s...@dague.net wrote:
I would agree this doesn't make sense in Neutron.
I do wonder if it makes sense in the Network program. I'm getting
suspicious of the programs for projects model if
Bunch of responses/thoughts:
API
I'm ok that semantics additions could be done in one API version w/o
increasing minor version. I like the idea to keep only major API
versions starting from the next API version.
RE backward compat period, for now 1-2 cycles is ok.
Images
Agreed that we
Re sahara-image-elements we found a bunch of issues that we should
solve and that's why I think that keeping current releasing is still
the best option.
- we should test it better and depend on stable diskimage-builder version
The dib is now published to pypi, so, we could make
On 05/29/2014 09:59 AM, Trevor McKay wrote:
below, sahara-extra
sahara-extra
Keep it as is, no need to stop releasing, because we're not publishing
anything to pypi. No real need for tags.
Even if we keep the repo for now, I think we could simplify a little
bit. The edp-examples could be
Hi,
The blueprint let admins provide some provider attributes and let neutron
the remaining attributes.
The blueprint specification and associated implementation are under
reviews[1].
[1]
https://review.openstack.org/#/q/topic:bp/provider-network-partial-specs,n,z
On Thu, May 29, 2014 at 1:23
client
We have separated launchpad project for client and we're publishing
client releases to it.
extra
I'm neutral about moving job examples and API samples between sahara and extra
ui tests
if we'll be able to remove sahara-dashboard before good integration
tests for our pages will be
below, sahara-extra
On Wed, 2014-05-28 at 20:02 +0400, Sergey Lukjanov wrote:
Hey folks,
it's a small wrap-up for the topic Sahara subprojects releasing and
versioning that was discussed partially on summit and requires some
more discussions. You can find details in [0].
common
We'll
- Original Message -
sahara-extra
Keep it as is, no need to stop releasing, because we're not publishing
anything to pypi. No real need for tags.
Even if we keep the repo for now, I think we could simplify a little
bit. The edp-examples could be moved to the Sahara repo.
- Original Message -
Re sahara-image-elements we found a bunch of issues that we should
solve and that's why I think that keeping current releasing is still
the best option.
- we should test it better and depend on stable diskimage-builder version
The dib is now published to pypi,
So, it looks like we have an agreement on all question.
There is only one technical question - keeping release images means
that we need to keep the whole matrix of images: plugin X version X
OSy [X root-passwdord]. I'll take a look on total size of them and
ability to publish them on OS infra.
On 05/29/2014 10:15 AM, Michael McCune wrote:
- Original Message -
Re sahara-image-elements we found a bunch of issues that we should
solve and that's why I think that keeping current releasing is still
the best option.
- we should test it better and depend on stable
- Original Message -
the image-elements is too unstable to be used by anyone but an expert at
this point. imho we should make sure the experts produce working images
first, it's what our users will need in the first place, then make the
image generation more stable.
+1
mike
On 05/29/2014 10:22 AM, Sergey Lukjanov wrote:
So, it looks like we have an agreement on all question.
There is only one technical question - keeping release images means
that we need to keep the whole matrix of images: plugin X version X
OSy [X root-passwdord]. I'll take a look on total size
Hello Neutron core team,
We have three specs[1][2][3] submitted last week, for which have gotten +1s
from non core contributors.
It would be great if core devs could review them and give us some feedback.
(I noticed that I didn't include links to gerrit reviews in launchpad BPs
and just fixed
On 29 May 2014, at 18:43, Matthew Farrellee m...@redhat.com wrote:
i do not think we should release any images that have a root password set
(essentially a backdoor).
for K we should deprecate the hadoop1 versions and thus significantly cut the
size of the new image artifact.
Agree
Hi, Marios,
STF stands for 'service type framework'. It's the current way to dispatch
calls to different drivers based on 'provider' attribute of the LBaaS
service instance. Firewall and VPN implementations were not upstreamed as
we want to move to Flavor Framework.
I think the flavor framework
I agree with this. No real sense in leaving image generation up to novice
users at this point.
+1
- Original Message -
From: Michael McCune mimcc...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Thursday, May 29,
Well, for my specific error, it was an intermittent ssl handshake error
before the request was ever sent to the
neutron-server. In our case, we saw that 4 out of 5 resize operations
worked, the fifth failed with this ssl
handshake error in neutronclient.
I certainly think a GET is safe to
On Tue, May 27, 2014 at 6:07 PM, James E. Blair jebl...@openstack.orgwrote:
I wonder if it would
be possible to detect them based on the presence of a Verified vote?
Not all CIs always add a vote. Only 3 or so of over 9000 Neutron's CIs put
their +/-1s on the change.
--
Kind regards,
Hello,
During the last Summit the use of AngularJS in Horizon was discussed and there
is the intention to do a better use of it in the dashboards.
I think this blueprint could help
https://blueprints.launchpad.net/horizon/+spec/django-angular-integration,
since it proposes the integration of
On Wed, May 28, 2014 at 3:54 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno na...@ntti3.com wrote:
(2) Avoid duplication of works
I have several experience of this. Anyway, we should encourage people
to check listed bug before
writing patches.
I think this falls inline with other items we are working toward in
Horizon, namely more pluggable components on panels.
I think creating a directory in openstack_dashboard for these reusable
components makes a lot of sense. And usage should eventually moved to
there.
I would suggest something as
We are in the process of removing the redundancy between Project and Admin
by using RBAC to allow sharing of one code base for multiple roles. This
is a WIP.
David
On 5/28/14, 1:53 PM, Tzu-Mainn Chen tzuma...@redhat.com wrote:
Hi Doug,
Thanks for the response! I agree with you in the cases
Ryan Brady rbr...@redhat.com writes:
Would you want to merge the patches that simply remove the unneeded
lines and then let me followup with patches that remove © along with
the then unnecessary coding lines?
If I was in your position, I'd update the patches that remove lines to
include all
Hi Everyone,
So we'd like to announce to everyone that we're going to be doing a combined
Infra and QA program mid-cycle meet-up. It will be the week of July 14th in
Darmstadt, Germany at Deutsche Telekom who has graciously offered to sponsor the
event. The plan is to use the week as both a time
I like the idea
2014-05-29 8:33 GMT-07:00 Yuriy Taraday yorik@gmail.com:
On Wed, May 28, 2014 at 3:54 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno na...@ntti3.com wrote:
(2) Avoid duplication of works
I have several experience of this. Anyway,
I will take them!
Edgar
From: Tomoe Sugihara to...@midokura.commailto:to...@midokura.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 29, 2014 at 7:57 AM
To: OpenStack
as per discussions on l3 subteem meeting today, i started
a bgp speakers comparison wiki page for this bp.
https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison
Artem, can you add other requirements as columns?
as one of ryu developers, i'm naturally biased to ryu bgp.
i appreciate if
Hi Paul,
Just out of curiosity, I am assuming you are using the client that
still relies on httplib2. Patch [1] replaced httplib2 with requests,
but I believe that a new client that incorporates this change has not
yet been published. I wonder if the failures you are referring to
manifest
On 29/05/14 05:26, Thierry Carrez wrote:
Sean Dague wrote:
I honestly just think we might want to also use it as a time to rethink
our program concept. Because all our programs that include projects that
are part of the integrated release are 1 big source tree, and maybe a
couple of little
jebl...@openstack.org (James E. Blair) writes:
Nikita Konovalov has been reviewing changes to both storyboard and
storyboard-webclient for some time. He is the second most active
storyboard reviewer and is very familiar with the codebase (having
written a significant amount of the server
I agree that there is room for improvement on the Federation design within
Keystone. I would like to re-iterate what Adam said that we are already seeing
efforts to fully integrate further protocol support (OpenID Connect, etc)
within the current system. Lets be sure that whatever redesign work
jebl...@openstack.org (James E. Blair) writes:
The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access). Read all about it here:
jebl...@openstack.org (James E. Blair) writes:
The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access). Read all about it here:
Yes, we're still on a code level that uses httplib2. I noticed that as
well, but wasn't sure if that would really
help here as it seems like an ssl thing itself. But... who knows?? I'm
not sure how consistently we can
recreate this, but if we can, I'll try using that patch to use requests and
On Wed, May 28, 2014 at 11:42 PM, Robert Collins
robe...@robertcollins.netwrote:
Is there any wiggle room on those dates? As James Polley says, PyCon
AU (and the Openstack miniconf, which I'm organising with JHesketh)
overlap significantly - and I can't be in two places at once.
However July
Hi Jaromir,
I agree that the midcycle meetup with TripleO and Ironic was very
beneficial last cycle, but this cycle, Ironic is co-locating its sprint
with Nova. Our focus needs to be working with them to merge the
nova.virt.ironic driver. Details will be forthcoming as we work out the
exact
Devananda van der Veen devananda@gmail.com wrote on 05/29/2014
01:26:12 PM:
Hi Jaromir,
I agree that the midcycle meetup with TripleO and Ironic was very
beneficial last cycle, but this cycle, Ironic is co-locating its
sprint with Nova. Our focus needs to be working with them to
+1! Excellent summary and analysis Morgan!
--Brad
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Morgan Fainberg morgan.fainb...@gmail.com
To: OpenStack Development Mailing List
On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh
joshua.hesk...@rackspace.com wrote:
On 5/29/14 8:52 AM, James E. Blair wrote:
Devananda van der Veen devananda@gmail.com writes:
Hi all!
This is a follow-up to several summit discussions on
how-do-we-deprecate-baremetal, a summary of
Hi thomas,
Since I'm the one that added wrapt to the requirements list I thought it
would be appropriate for me to respond :)
So looking over the pull request it seems like there was agreement that
the issues will be fixed and the adjustments will occur (that seems to be
the case last time I
On 5/27/2014 4:44 PM, Vishvananda Ishaya wrote:
I’m not sure that this is the right approach. We really have to add the old
extension back for compatibility, so it might be best to simply keep that
extension instead of adding a new way to do it.
Vish
On May 27, 2014, at 1:31 PM, Cazzolato,
And /me is no longer the new guy :)
On Thu, May 29, 2014 at 9:05 PM, James E. Blair jebl...@openstack.org wrote:
jebl...@openstack.org (James E. Blair) writes:
The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2
A further vote to maintain compatibility . One of the key parts to a good
federation design is to be using it in the field and encountering real life
problems.
Production sites expect stability of interfaces and functions. If this cannot
be reasonably ensured, the federation function
mishandling of SSL was the very reason why I brought that change
forward; so I wouldn't rule it out completely ;)
A.
On 29 May 2014 19:15, Paul Ward wpw...@us.ibm.com wrote:
Yes, we're still on a code level that uses httplib2. I noticed that as
well, but wasn't sure if that would really
help
On Thu, May 29, 2014 at 12:59 PM, Tim Bell tim.b...@cern.ch wrote:
A further vote to maintain compatibility . One of the key parts to a good
federation design is to be using it in the field and encountering real life
problems.
Production sites expect stability of interfaces and
Hi there!
Recently we've changed the way application packages are paginated in
murano-dashboard (AppCatalog and Package Definitions panels) -
adopting the Glance approach with generators and 'next_marker'
property. This change concerns all 3 murano components - murano-api
[1], python-muranoclient
On 29/05/14 13:33, Mike Spreitzer wrote:
Devananda van der Veen devananda@gmail.com wrote on 05/29/2014
01:26:12 PM:
Hi Jaromir,
I agree that the midcycle meetup with TripleO and Ironic was very
beneficial last cycle, but this cycle, Ironic is co-locating its
sprint with Nova. Our
I just bent Jay's ear on IRC about this for a bit...
On 21 May 2014 05:07, Jay Pipes jaypi...@gmail.com wrote:
We are one of those operators that use Galera for replicating our mysql
databases. We used to see issues with deadlocks when having multiple
mysql writers in our mysql cluster. As a
On 05/28/2014 08:54 AM, Radomir Dopieralski wrote:
Hello,
we plan to finally do the split in this cycle, and I started some
preparations for that. I also started to prepare a detailed plan for the
whole operation, as it seems to be a rather big endeavor.
You can view and amend the plan at
Before solving everything, I would like first to itemize the things we should
solve/consider.
So pleas focus first on what is it that we need to pay attention for and less
on how to solve such issues.
Follows the list of items:
· Provisioning status/state
o Should it only be on the
Forgive me if I'm misunderstanding, but those all look like repositories that
are strictly tracking upstreams. They're not maintained by the
Horizon/OpenStack developers whatsoever. Is this intentional/necessary?
- Gabriel
-Original Message-
From: Anita Kuno
On 05/29/2014 03:45 PM, Gabriel Hurley wrote:
Forgive me if I'm misunderstanding, but those all look like repositories that
are strictly tracking upstreams. They're not maintained by the
Horizon/OpenStack developers whatsoever. Is this intentional/necessary?
- Gabriel
The permissions
Hello Barbican devs. I was wondering if we could get some of you to weigh in on
a couple of reviews for adding Barbican support in Heat. We seem to be churning
a bit around current and future features supported by the resources and could
use some expert opinions.
Blueprint:
Hello Randall,
We'll take a look at these CRs for sure, thanks.
Thanks,
John
From: Randall Burt [randall.b...@rackspace.com]
Sent: Thursday, May 29, 2014 3:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev]
Httplib2 does very little directly with ssl other than a wrap_socket call.
Unless requests has special ssl error handling and retry logic, it will be
exposed to the same set of underlying errors from the ssl library so a
retry that at least catches socket and ssl errors is a good idea.
On May 29,
The idea here is to decouple 3rd party static files from being embedded in
the Horizon repo. There are several reasons for this move. With embedded
3rd party static files upgrading the static files is cumbersome, versions
can be difficult to track and updates can be difficult to synchronize.
This
On 05/29/2014 04:55 PM, Lyle, David wrote:
The idea here is to decouple 3rd party static files from being embedded in
the Horizon repo. There are several reasons for this move. With embedded
3rd party static files upgrading the static files is cumbersome, versions
can be difficult to track and
Keshava,
How much of a problem is routing prefix fragmentation for you?
Fragmentation causes routing table bloat and may reduce the performance of
the routing table. It also increases the amount of information traded by
the routing protocol. Which aspect(s) is (are) affecting you? Can you
Hello everyone!
At the summit in Atlanta we demonstrated the Graffiti project concepts. We
received very positive feedback from members of multiple dev projects as well
as numerous operators. We were specifically asked multiple times about getting
the Graffiti metadata catalog concepts into
Hello!
I am writing to get some brainstorming started on how we might mitigate
some of the issues we've seen while deploying large stacks on Heat. I am
sending this to the dev list because it may involve landing fixes rather
than just using different strategies. The problems outlined here are
Hi folks
Today, we are can change allow overlapping ips or not by configuration.
This has impact of database design, and actually, this flag complicate the
implementations.
Whey we have this flag is a historical reason. This was needed when many OS
don't support namespaces, however Most of OS
On Thu, May 29, 2014 at 12:25 PM, Anita Kuno ante...@anteaya.info wrote:
As I was reviewing this patch today:
https://review.openstack.org/#/c/96160/
It occurred to me that the tuskar project is part of the tripleo
program:
Clint Byrum cl...@fewbar.com wrote on 05/29/2014 07:52:07 PM:
I am writing to get some brainstorming started on how we might mitigate
some of the issues we've seen while deploying large stacks on Heat. I am
sending this to the dev list because it may involve landing fixes rather
than just
Hi, the HP1 tripleo test cloud region has been systematically failing
and rather than flogging it along we're going to strip it down and
bring it back up with some of the improvements that have happened over
the last $months, as well as changing the undercloud to deploy via
Ironic and other
1 - 100 of 139 matches
Mail list logo