Hi all,
We are proposing a change to move bridge name generator (creating bridge name
from net-id or reading integration bridge name from nova.conf) from Nova to
Neutron. The followings are BPs in Nova and Neutron.
https://blueprints.launchpad.net/nova/+spec/neutron-vif-bridge-details
tox -e pep8 usually takes several minutes on my test server, actually I
only changes one file and I knew something might wrong there
anyway to only check that file? Thanks a lot
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet:
Le 15/12/2014 10:04, Chen CH Ji a écrit :
tox -e pep8 usually takes several minutes on my test server, actually
I only changes one file and I knew something might wrong there
anyway to only check that file? Thanks a lot
That's really non necessary to check all the files if you only modified
Le 15/12/2014 10:27, Sylvain Bauza a écrit :
Le 15/12/2014 10:04, Chen CH Ji a écrit :
tox -e pep8 usually takes several minutes on my test server, actually
I only changes one file and I knew something might wrong there
anyway to only check that file? Thanks a lot
That's really non
On Mon, Dec 15, 2014 at 05:04:59PM +0800, Chen CH Ji wrote:
tox -e pep8 usually takes several minutes on my test server, actually I
only changes one file and I knew something might wrong there
anyway to only check that file? Thanks a lot
Use
./run_tests.sh -8
That will only check pep8
Hi,
Here is the doc with suggestions on specification for for-each feature.
You are free to comment and ask questions.
https://docs.google.com/document/d/1iw0OgQcU0LV_i3Lnbax9NqAJ397zSYA3PMvl6F_uqm0/edit?usp=sharing
--
Best Regards,
Nikolay
___
Hi Ryan,
We have been working on similar Use cases to announce /32 with the
Bagpipe BGPSpeaker that supports EVPN.
Please have a look at use case B in [1][2].
Note also that the L2population Mechanism driver for ML2, that is
compatible with OVS, Linuxbridge and ryu ofagent, is inspired by EVPN,
Hey Ryota,
A better way of describing it would be that the bridge name is, at present,
generated in *both* Nova *and* Neutron, and the VIF type semantics define
how it's calculated. I think you're right that in both cases it would make
more sense for Neutron to tell Nova what the connection
On Mon, Dec 15, 2014 at 11:15:56AM +0100, Ian Wells wrote:
Hey Ryota,
A better way of describing it would be that the bridge name is, at present,
generated in *both* Nova *and* Neutron, and the VIF type semantics define
how it's calculated. I think you're right that in both cases it would
Daniel P. Berrange berra...@redhat.com writes:
Failing that though, I could see a way to accomplish a similar thing
without a Neutron launched agent. If one of the VIF type binding
parameters were the name of a script, we could run that script on
plug unplug. So we'd have a finite number of
My experience with building Fuel plugins with UI part is following. To
build a ui-less plugin, it takes 3 seconds and those commands:
git clone https://github.com/AlgoTrader/test-plugin.git
cd ./test-plugin
fpb --build ./
When UI added, build start to look like this and takes many minutes:
git
On Mon, Dec 15, 2014 at 09:37:23AM +, Daniel P. Berrange wrote:
On Mon, Dec 15, 2014 at 05:04:59PM +0800, Chen CH Ji wrote:
tox -e pep8 usually takes several minutes on my test server, actually I
only changes one file and I knew something might wrong there
anyway to only check that
Mathieua,
I have been thinking of Starting MPLS right from CN for L2VPN/EVPN
scenario also.
Below are my queries w.r.t supporting MPLS from OVS :
1. MPLS will be used even for VM-VM traffic across CNs
generated by OVS ?
2. MPLS will be originated
On Mon, Dec 15, 2014 at 10:36:59AM +, Neil Jerram wrote:
Daniel P. Berrange berra...@redhat.com writes:
Failing that though, I could see a way to accomplish a similar thing
without a Neutron launched agent. If one of the VIF type binding
parameters were the name of a script, we could
Hi Joe,
Joe Gordon joe.gord...@gmail.com writes:
In preparation, I put together a nova-specs dashboard:
https://review.openstack.org/141137
Looking at all comments it seems that existing change is reasonable. I will
update it with link to this thread.
Thanks!
Regards,
Ann Kamyshnikova
On Sat, Dec 13, 2014 at 1:15 AM, Rochelle Grober rochelle.gro...@huawei.com
wrote:
Morgan Fainberg [mailto:morgan.fainb...@gmail.com] *on*
Let me write a spec and see what you both think. I have a couple of things
we could address here and while it's a bit late it wouldn't be a dramatic
thing to fix and it might be acceptable.
On 15 December 2014 at 11:28, Daniel P. Berrange berra...@redhat.com
wrote:
On Mon, Dec 15, 2014 at
Travis,
That said, I can see a few ways that we could use the same REST decorator
code and provide direct access to the API. We’d simply provide a class
where the url_regex maps to the desired path and gives direct passthrough.
Maybe that kind of passthrough could always be provided for ease
First of all, compiling of statics shouldn't be a required step. No one
does this during development.
For production-ready plugins, the compiled files should already be
included in the GitHub repos and installation of plugin should just be a
matter of downloading it. The API should then take
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
Hi,
It looked good and I began to write down the summary:
https://etherpad.openstack.org/p/mistral-global-context
https://etherpad.openstack.org/p/mistral-global-context
Thanks, I left my comments in there.
What problems are we trying to solve:
1) reduce passing the same parameters over
On 12/11/2014 12:03 PM, Anita Kuno wrote:
On 12/11/2014 09:36 AM, Jon Bernard wrote:
Heya, quick Ceph CI status update. Once the test_volume_boot_pattern
was marked as skipped, only the revert_resize test was failing. I have
submitted a patch to nova for this [1], and that yields an all
Hi David,
Please add as per the Irena suggestion
FYI: refer the below configuration
http://pastebin.com/DGmW7ZEg
Thanks
-Murali
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Hi,
I’m just reminding about another team meeting we have today at 16.00 UTC
#openstack-meeting channel.
Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Release Kilo-1 progress
for-each spec
Discuss scoping (global, local etc.)
Open discussion
(see
Ian and Daniel,
Thanks for the comments.
I have neutron spec here and planned to start from Neutron side to expose
bridge name via port-binding API.
https://review.openstack.org/#/c/131342/
Thanks,
Ryota
-Original Message-
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Hi Zane,
We have been going through this chain for quite some time now and we still feel
a disconnect in our understanding.
Can you put up a etherpad where we can understand your approach. For example:
for storing resource dependencies,
Are you storing its name, version tuple or just its ID.
+1 to show as is. We don't get benefits from parsing now (like filtering
by value of particular parameter, date/time intervals). It only adds
complexity.
Aleksey Kasatkin
On Mon, Dec 15, 2014 at 1:40 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:
Also +1 here.
In huge envs we already
Hello, Morgan,
The keystone is global service for cascading OpenStack and cascaded OpenStacks,
just like it works for multi-region. PKI token/UUID token should be workable
for multi-region first, if there is some security issues, we need to fix it, no
matter cascading introduced or not.
Hi Mike,
Sorry to delay so long. Now we have added a mapping in
cinder/volume/manager.pyhttps://review.openstack.org/#/c/133193/25/cinder/volume/manager.py
and add a file named
The building of the UI plugin has several things I do not like
1) I need to extract the UI part of the plugin and copy/symlink it to
fuel-web
2) I have to run grunt build on the whole fuel-web
3) I have to copy files back to original location to pack them
4) I cannot easily switch between
On 12/15/2014 02:26 PM, Anton Zemlyanov wrote:
The building of the UI plugin has several things I do not like
1) I need to extract the UI part of the plugin and copy/symlink it to
fuel-web
This is required, the UI part should live somewhere in statics/js. This
directory is served by nginx
Swati Shukla1 swati.shuk...@tcs.com wrote on 12/14/2014 11:29:19 PM:
From: Swati Shukla1 swati.shuk...@tcs.com
To: openstack-dev@lists.openstack.org
Date: 12/14/2014 11:34 PM
Subject: [openstack-dev] #PERSONAL# : Facing problem in installing
new python dependencies for Horizon- Pls help
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
the question arose recently in one of reviews for neutron-*aas repos
to remove all oslo-incubator code from those repos since it's
duplicated in neutron main repo. (You can find the link to the review
at the end of the email.)
Brief
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 15/12/14 15:15, Ihar Hrachyshka wrote:
- it's a delusion that there will be no neutron-main syncs that
will break neutron-*aas repos ever.
OK, I've just decided to check whether my (non-native speaker)
understanding of the meaning of the word
Hi,
The only thing I don't really like is that we need fuel-web code to build
plugin. But we have can do nothing with it, as typical UI plugin by design
is tightly coupled with the core. If plugin want to reuse core libraries,
utils, controls then it has to declare them as dependencies and if
On 12-Dec-14 06:29, Zane Bitter wrote:
On 11/12/14 01:14, Anant Patil wrote:
On 04-Dec-14 10:49, Zane Bitter wrote:
On 01/12/14 02:02, Anant Patil wrote:
On GitHub:https://github.com/anantpatil/heat-convergence-poc
I'm trying to review this code at the moment, and finding some stuff I
don't
Hi folks!
In most productions environments I’ve seen bare logs as they are shown now in
Fuel web UI were pretty useless. If someone has an infrastructure that consists
of more that 5 servers and 5 services running on them they are most likely to
use logstash, loggly or any other log management
We talked about this last week at the Oslo meeting [1], but I also promised to
send an email for a broader audience.
We have recently had a couple of issues when we released a library where we
broke unit tests running in other projects. We test the source tree of the
libraries against the
On 13-Dec-14 05:42, Zane Bitter wrote:
On 12/12/14 05:29, Murugan, Visnusaran wrote:
-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com]
Sent: Friday, December 12, 2014 6:37 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Convergence
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 14/12/14 09:45, Thomas Goirand wrote:
Hi,
As I am slowing fixing all systemd issues for the daemons of
OpenStack in Debian (and hopefully, have this ready before the
freeze of Jessie), I was wondering what kind of Type= directive to
put on
On 12/09/2014 11:55 AM, Anita Kuno wrote:
On 12/09/2014 08:32 AM, Kurt Taylor wrote:
All of the feedback so far has supported moving the existing IRC
Third-party CI meeting to better fit a worldwide audience.
The consensus is that we will have only 1 meeting per week at alternating
times.
On 12/15/2014 07:11 AM, Russell Bryant wrote:
On 12/11/2014 12:03 PM, Anita Kuno wrote:
On 12/11/2014 09:36 AM, Jon Bernard wrote:
Heya, quick Ceph CI status update. Once the test_volume_boot_pattern
was marked as skipped, only the revert_resize test was failing. I have
submitted a patch to
Anita, please, creating yet another meeting time without input from anyone
just confuses the issue.
The work group has agreed unanimously on alternating weekly meeting times,
and are currently voting on the best for everyone. (
https://www.google.com/moderator/#16/e=21b93c 14 voters so far,
Excerpts from Ihar Hrachyshka's message of 2014-12-15 07:21:04 -0800:
Hash: SHA512
On 14/12/14 09:45, Thomas Goirand wrote:
Hi,
As I am slowing fixing all systemd issues for the daemons of
OpenStack in Debian (and hopefully, have this ready before the
freeze of Jessie), I was
On Saturday, December 13, Setuptools 8.0 released implementing the
new PEP 440[1] version specification and dropping support for a
variety of previously somewhat-supported versioning syntaxes. This
is impacting us in several ways...
Multiple range expressions in requirements are no longer
Hi,
Some files in neutron are common infrastructure to the VMWare neutron L2/L3
plugin, and the services plugins.
These files wrap VMWare NSX and provide a python API to some NSX services.
This code is common to:
- VMWare L2/L3 plugin, which after the split should be held outside of
openstack
Hi Ihar,
I’m actually in favor of option 2, but it implies a few things about your
time, and I wanted to chat with you before presuming.
Maintenance can not involve breaking changes. At this point, the co-gate
will block it. Also, oslo graduation changes will have to be made in the
services
On 12/15/2014 10:55 AM, Kurt Taylor wrote:
Anita, please, creating yet another meeting time without input from anyone
just confuses the issue.
When I ask people to attend meetings to reduce noise on the mailing
list, there had better be some meetings.
I am grateful for the time you have spent
On 12/15/2014 11:20 AM, Kobi Samoray wrote:
3. Add these components to oslo.vmware project: oslo.vmware contains, as of
now, a wrapper to vCenter API. The components in discussion wrap NSX API,
which is out of vCenter scope. Therefore it’s not really a part of
oslo.vmware scope as it is
On 12/15/14, 8:20 AM, Kobi Samoray ksamo...@vmware.com wrote:
Hi,
Some files in neutron are common infrastructure to the VMWare neutron
L2/L3 plugin, and the services plugins.
These files wrap VMWare NSX and provide a python API to some NSX services.
This code is common to:
- VMWare L2/L3
It shouldn’t drag any additional dependencies - it’s REST API wrapper so
nothing beyond XML/JSON/HTTP/threads should be used in these components.
On Dec 15, 2014, at 18:23, Russell Bryant rbry...@redhat.com wrote:
On 12/15/2014 11:20 AM, Kobi Samoray wrote:
3. Add these components to
On 12/15/2014 12:54 PM, Neil Jerram wrote:
My Nova spec (https://review.openstack.org/#/c/130732/) does not appear
on this dashboard, even though I believe it's in good standing and - I
hope - close to approval. Do you know why - does it mean that I've set
some metadata field somewhere wrongly?
The Oslo team is pleased to announce the release of
oslo.db 1.3.0: oslo.db library
This release is primarily meant to update the SQLAlchemy dependency
to resolve the issue with the new version of setuptools changing
how it evaluates version range specifications.
For more details, please see the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I was (rightfully) asked to share my comments on the matter that I
left in gerrit here. See below.
On 12/12/14 22:40, Sean Dague wrote:
On 12/12/2014 01:05 PM, Maru Newby wrote:
On Dec 11, 2014, at 2:27 PM, Sean Dague s...@dague.net wrote:
On 2014-12-15 11:53:07 -0500 (-0500), Doug Hellmann wrote:
[...]
This release is primarily meant to update the SQLAlchemy dependency
to resolve the issue with the new version of setuptools changing
how it evaluates version range specifications.
[...]
However note that I'm in the middle of
When I try to follow the instalation guide I'm having some issues (
http://docs.openstack.org/developer/ironic/deploy/install-guide.html )
I installed the devstack with ironic and did worked. Now, having a single
machine running devstack, I want to deploy the Ironic on it. So, I'll have
a machine
Thanks for joining our team meeting today!
Meeting minutes:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-12-15-16.01.html
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-12-15-16.01.html
Full log:
- Original Message -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I was (rightfully) asked to share my comments on the matter that I
left in gerrit here. See below.
On 12/12/14 22:40, Sean Dague wrote:
On 12/12/2014 01:05 PM, Maru Newby wrote:
On Dec 11, 2014, at 2:27
On Mon, Dec 15, 2014 at 8:46 AM, Radoslav Gerganov rgerga...@vmware.com
wrote:
On 12/15/2014 12:54 PM, Neil Jerram wrote:
My Nova spec (https://review.openstack.org/#/c/130732/) does not appear
on this dashboard, even though I believe it's in good standing and - I
hope - close to approval.
Hi all,
Ihar and I discussed this on IRC, and are going forward with option 2
unless someone has a big problem with it.
Thanks,
Doug
On 12/15/14, 8:22 AM, Doug Wiegley do...@a10networks.com wrote:
Hi Ihar,
I’m actually in favor of option 2, but it implies a few things about your
time, and I
On Mon, Dec 15, 2014 at 9:14 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Mon, Dec 15, 2014 at 8:46 AM, Radoslav Gerganov rgerga...@vmware.com
wrote:
On 12/15/2014 12:54 PM, Neil Jerram wrote:
My Nova spec (https://review.openstack.org/#/c/130732/) does not appear
on this dashboard,
Joe Gordon joe.gord...@gmail.com writes:
On Mon, Dec 15, 2014 at 8:46 AM, Radoslav Gerganov
rgerga...@vmware.com wrote:
On 12/15/2014 12:54 PM, Neil Jerram wrote:
My Nova spec (https://review.openstack.org/#/c/130732/) does not
appear
on this dashboard, even
Option 2 works for me, thanks for figuring this out Ihar and Doug!
On Mon, Dec 15, 2014 at 11:16 AM, Doug Wiegley do...@a10networks.com
wrote:
Hi all,
Ihar and I discussed this on IRC, and are going forward with option 2
unless someone has a big problem with it.
Thanks,
Doug
On
On Mon, Dec 15, 2014 at 10:24 AM, Anita Kuno ante...@anteaya.info wrote:
On 12/15/2014 10:55 AM, Kurt Taylor wrote:
Anita, please, creating yet another meeting time without input from
anyone
just confuses the issue.
When I ask people to attend meetings to reduce noise on the mailing
list,
Hi all,
Following the approval for Neutron vendor code decomposition
(https://review.openstack.org/#/c/134680/), I just wanted to comment
that it appears to work fine to have an ML2 mechanism driver _entirely_
out of tree, so long as the vendor repository that provides the ML2
mechanism driver
All,
I'm happy to say that the Swift 2.2.1 release candidate is available.
http://tarballs.openstack.org/swift/swift-2.2.1c1.tar.gz
Please take a look, and if nothing is found, we'll release this as the final
2.2.1 version at the end of the week.
This release includes a lot of great
There may be a similar problem managing dependencies on libraries that live
outside of either tree. I assume you already decided how to handle that. Are
you doing the same thing, and adding the requirements to neutron’s lists?
On Dec 15, 2014, at 12:16 PM, Doug Wiegley do...@a10networks.com
You are invited to participate in an online card sort activity sponsored by the
Horizon team. The purpose of this activity is to help us evaluate the current
information architecture and find ways to improve it. We are specifically
interested in individuals who use cloud services as a
On 12/15/2014 10:16 AM, Jeremy Stanley wrote:
On Saturday, December 13, Setuptools 8.0 released implementing the
new PEP 440[1] version specification and dropping support for a
variety of previously somewhat-supported versioning syntaxes. This
is impacting us in several ways...
Multiple range
Hi everyone,
The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting on Tuesday December 16th, at 19:00 UTC in #openstack-meeting
Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)
Everyone
On 12/15/2014 12:01 PM, Jeremy Stanley wrote:
On 2014-12-15 11:53:07 -0500 (-0500), Doug Hellmann wrote:
[...]
This release is primarily meant to update the SQLAlchemy dependency
to resolve the issue with the new version of setuptools changing
how it evaluates version range specifications.
On 12/09/2014 04:11 PM, by wrote:
[vad] how about the documentation in this case?... bcos it needs some
place to document (a short desc and a link to vendor page) or list these
kind of out-of-tree plugins/drivers... just to make the user aware of
the availability of such plugins/driers which
On Dec 15, 2014, at 1:50 PM, Sean Dague s...@dague.net wrote:
On 12/15/2014 12:01 PM, Jeremy Stanley wrote:
On 2014-12-15 11:53:07 -0500 (-0500), Doug Hellmann wrote:
[...]
This release is primarily meant to update the SQLAlchemy dependency
to resolve the issue with the new version of
On 12/15/2014 01:53 PM, Donald Stufft wrote:
On Dec 15, 2014, at 1:50 PM, Sean Dague s...@dague.net wrote:
On 12/15/2014 12:01 PM, Jeremy Stanley wrote:
On 2014-12-15 11:53:07 -0500 (-0500), Doug Hellmann wrote:
[...]
This release is primarily meant to update the SQLAlchemy dependency
to
On Dec 15, 2014, at 1:57 PM, Sean Dague s...@dague.net wrote:
On 12/15/2014 01:53 PM, Donald Stufft wrote:
On Dec 15, 2014, at 1:50 PM, Sean Dague s...@dague.net wrote:
On 12/15/2014 12:01 PM, Jeremy Stanley wrote:
On 2014-12-15 11:53:07 -0500 (-0500), Doug Hellmann wrote:
[...]
This
On Dec 15, 2014, at 2:02 PM, Donald Stufft don...@stufft.io wrote:
On Dec 15, 2014, at 1:57 PM, Sean Dague s...@dague.net wrote:
On 12/15/2014 01:53 PM, Donald Stufft wrote:
On Dec 15, 2014, at 1:50 PM, Sean Dague s...@dague.net wrote:
On 12/15/2014 12:01 PM, Jeremy Stanley wrote:
On Mon, Dec 15, 2014, at 11:09 AM, Doug Hellmann wrote:
On Dec 15, 2014, at 2:02 PM, Donald Stufft don...@stufft.io wrote:
On Dec 15, 2014, at 1:57 PM, Sean Dague s...@dague.net wrote:
On 12/15/2014 01:53 PM, Donald Stufft wrote:
On Dec 15, 2014, at 1:50 PM, Sean Dague
Excerpts from Anant Patil's message of 2014-12-15 07:15:30 -0800:
On 13-Dec-14 05:42, Zane Bitter wrote:
On 12/12/14 05:29, Murugan, Visnusaran wrote:
-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com]
Sent: Friday, December 12, 2014 6:37 AM
To:
Hi,
I've been bitten by a couple bugs lately on DevStack installs that have
been long lived. One is a built by Vagrant, and the other is bare metal
hardware.
https://bugs.launchpad.net/devstack/+bug/1395776
In this instance, a commit was made to rollback the introduction of
MariaDB in ubuntu,
On 12/15/2014 02:33 PM, Collins, Sean wrote:
Hi,
I've been bitten by a couple bugs lately on DevStack installs that have
been long lived. One is a built by Vagrant, and the other is bare metal
hardware.
https://bugs.launchpad.net/devstack/+bug/1395776
In this instance, a commit was
The issue with stable/juno jobs failing because of the difference in the
SQLAlchemy requirements between the older applications and the newer oslo.db is
being addressed with a new release of the 1.2.x series. We will then cap the
requirements for stable/juno to 1.2.1. We decided we did not need
Hi there,
I'm new to the list, and trying to get more information about the following
issue:
https://bugs.launchpad.net/heat/+bug/1353670
Is there anyone on the list who can explain under what conditions a user might
hit this? Workarounds? ETA for a fix?
Thanks!
- Ari
On Monday,
On Dec 12, 2014, at 1:40 PM, Sean Dague s...@dague.net wrote:
On 12/12/2014 01:05 PM, Maru Newby wrote:
On Dec 11, 2014, at 2:27 PM, Sean Dague s...@dague.net wrote:
On 12/11/2014 04:16 PM, Jay Pipes wrote:
On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:
On Dec 11, 2014, at 1:04 PM,
I think the point made is that the behaviour is currently inconsistent and
not user friendly.
Regardless of that, I would like to point that technically this kind of
change is backward incompatible and so it should not be simply approved by
popular acclamation.
I will seek input from the API WG
On Dec 15, 2014, at 9:13 AM, Assaf Muller amul...@redhat.com wrote:
- Original Message -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I was (rightfully) asked to share my comments on the matter that I
left in gerrit here. See below.
On 12/12/14 22:40, Sean Dague wrote:
On Fri, Dec 12, 2014 at 3:16 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Fri, Dec 12, 2014 at 03:05:28PM +0100, Maxime Leroy wrote:
On Fri, Dec 12, 2014 at 10:46 AM, Daniel P. Berrange
berra...@redhat.com wrote:
On Fri, Dec 12, 2014 at 01:21:36PM +0900, Ryu Ishimoto wrote:
On Thu,
The abandon sweep has been finished. Here is the list of the reviews that were
abandoned.
Keystone:
https://review.openstack.org/#/c/73907/
https://review.openstack.org/#/c/111312/
https://review.openstack.org/#/c/93480/
https://review.openstack.org/#/c/123862/
On Dec 15, 2014, at 3:21 PM, Doug Hellmann d...@doughellmann.com wrote:
The issue with stable/juno jobs failing because of the difference in the
SQLAlchemy requirements between the older applications and the newer oslo.db
is being addressed with a new release of the 1.2.x series. We will
I suspect you are actually failing due to not having enough room in your cloud
instead of not having enough quota.
You will need to make instance sizes with less cpus/ram/disk or change your
allocation ratios in the scheduler.
Vish
On Dec 13, 2014, at 8:43 AM, Danny Choi (dannchoi)
I have seen deadlocks in libvirt that could cause this. When you are in this
state, check to see if you can do a virsh list on the node. If not, libvirt is
deadlocked, and ubuntu may need to pull in a fix/newer version.
Vish
On Dec 12, 2014, at 2:12 PM, pcrews glee...@gmail.com wrote:
On
Hi openstack-dev,
The Barbican team is planning to have a mid-cycle sprint in Austin, TX on
February 16-18, 2015. We’ll be meeting at Capital Factory, a co-working space
in downtown Austin.
For more details and RSVP, please see:
https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint
Excerpts from Ari Rubenstein's message of 2014-12-15 12:32:08 -0800:
Hi there,
I'm new to the list, and trying to get more information about the following
issue:
https://bugs.launchpad.net/heat/+bug/1353670
Is there anyone on the list who can explain under what conditions a user
might
Murano agent is required as long as you deploy applications that use it.
You can take (write) application that uses Heat Software Configuration
instead of Murano agent and use image without agent
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis
sla...@mirantis.com
On Mon, Dec
On 12/05/2014 07:08 AM, Kurt Taylor wrote:
1. Meeting content: Having 2 meetings per week is more than is needed at
this stage of the working group. There just isn't enough meeting content
to justify having two meetings every week.
I'd like to discuss this further: the stated objectives of the
On Tue, Dec 16, 2014 at 1:53 AM, Neil Jerram neil.jer...@metaswitch.com wrote:
Hi all,
Following the approval for Neutron vendor code decomposition
(https://review.openstack.org/#/c/134680/), I just wanted to comment
that it appears to work fine to have an ML2 mechanism driver _entirely_
out
I had a short user feedback sessions with Patrick and James, the short summary
is:
1) simplify the syntax to optimize for the most common use case
2) 'concurrency' is the best word - but bring it out of for-each to task level,
or task/policies
3) all-permutation - relatively rare case, either
Yes Ryan, that's exactly what I'm thinking. Glad to know that we have the same
opinion :)
BR
Kurt
-邮件原件-
发件人: Ryan Brown [mailto:rybr...@redhat.com]
发送时间: 2014年12月12日 23:30
收件人: openstack-dev@lists.openstack.org
主题: Re: [openstack-dev] [Openstack] [Ceilometer] [API] Batch alarm
On Mon, Dec 15, 2014 at 2:03 PM, Sean Dague s...@dague.net wrote:
On 12/15/2014 02:33 PM, Collins, Sean wrote:
It'd be great to somehow make a long lived dsvm node and job where
DevStack is continually deployed to it and restacked, to check for these
kinds of errors?
I want to be careful
Hi,
I know nova has such day around Dec. 18, is there a similar day in Cinder
project? thanks!
Best Regards,
Dave Chen
smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Dave,
Yes, we are not taking new specs/blueprints after 12/18.
Jay
On Dec 15, 2014 9:18 PM, Chen, Wei D wei.d.c...@intel.com wrote:
Hi,
I know nova has such day around Dec. 18, is there a similar day in Cinder
project? thanks!
Best Regards,
Dave Chen
1 - 100 of 117 matches
Mail list logo
