> On 09 Feb 2016, at 21:43, Sean M. Collins wrote:
>
> Kevin Benton wrote:
>> I agree with the mtu setting because there isn't much of a downside to
>> enabling it. However, the others do have reasons to be disabled.
>>
>> csum - requires runtime detection of support for a feature and then auto
Matt Riedemann wrote:
While reviewing the neutron 7.0.2 stable/liberty point release, I noticed
there were a lot of changes since 7.0.1. [1]
There are 48 non-merge commits by my count.
While there is no rule about how many backports should land before we cut
a point release, it would be h
I like the idea of moving it to use the OpenStack infrastructure.
On Wed, Feb 10, 2016 at 12:13 AM, Ben Nemec wrote:
> On 02/09/2016 08:05 AM, Emilien Macchi wrote:
> > Hi,
> >
> > TripleO is currently using puppet-pacemaker [1] which is a module hosted
> > & managed by Github.
> > The module wa
Hi,
You can find the meeting minutes of Vitrage meeting:
http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-02-10-09.00.html
Meeting log:
http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-02-10-09.00.log.html
See you next week,
Ifat.
Folks
I think the easiest and the best option here is to boot iPXE or pxelinux
with NFS and put master node image onto an NFS mount. This one should work
seamlessly.
On Wed, Feb 10, 2016 at 1:36 AM, Andrew Woodward
wrote:
> Unless we hope to gain some insight and specific testing by installing
Hi all,
Unfortunately today's meeting of the Telco Working Group [1] is canceled, my
apologies for the late notice!
Thanks,
Steve
[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup
__
OpenStack Development Mailing List
On Tue, 9 Feb 2016, Chris Dent wrote:
eventlet 0.18.2 has broken the nova unit tests at
'nova.tests.unit.test_wsgi.TestWSGIServerWithSSL' so the gate is
blocked.
sdague et al are working on it. Please hold off approving patches
in nova until they get it resolved.
Just in case it's not obvious
On 02/10/2016 05:54 AM, Chris Dent wrote:
> On Tue, 9 Feb 2016, Chris Dent wrote:
>
>> eventlet 0.18.2 has broken the nova unit tests at
>> 'nova.tests.unit.test_wsgi.TestWSGIServerWithSSL' so the gate is
>> blocked.
>>
>> sdague et al are working on it. Please hold off approving patches
>> in nov
Could anyone (and especially Dan, Hans, or Ryan) check my changes?
There is no new code ) only removing old code and dependency to 'boto' library.
https://review.openstack.org/#/c/266425/
--
Kind regards,
Andrey Pavlov.
__
Hello.
I've noticed once again that job
"gate-tempest-dsvm-neutron-src-oslo.concurrency-liberty" is always failing.
After looking at the failure I found that the core issue is
ContextualVersionConflict [0]. It seems that we have conflicting
requirements for oslo.utils here, and we do: in Liberty u
Hello All,
As most of you people knows the 'QoS' feature is added in neutron during
liberty release.
It will be nice to have this feature in horizon, so I have added a
'network qos' panel for the same in angularJS.
It will be very helpful if you people reviewing this patches and helping
to la
The largeops tests at this point are mostly finding out that some of our
new cloud providers are slow - http://tinyurl.com/j5u4nf5
This is fundamentally a performance test, with timings having been tuned
to pass 98% of the time on two clouds that were very predictable in
performance. We're now run
On 02/10/2016 07:33 AM, Sean Dague wrote:
The largeops tests at this point are mostly finding out that some of our
new cloud providers are slow - http://tinyurl.com/j5u4nf5
This is fundamentally a performance test, with timings having been tuned
to pass 98% of the time on two clouds that were ve
+1 from me
On Wed, Feb 10, 2016 at 7:56 AM, Jay Pipes wrote:
> On 02/10/2016 07:33 AM, Sean Dague wrote:
>>
>> The largeops tests at this point are mostly finding out that some of our
>> new cloud providers are slow - http://tinyurl.com/j5u4nf5
>>
>> This is fundamentally a performance test, with
Fuelers,
We are discussing the idea to extend the multi release packages for plugins.
Fuel plugin builder (FPB) can create one rpm-package for all supported
releases (from metadata.yaml) but we can specify only deployment scripts
and repositories per release.
Current release definition (in metad
On 10/02/16 07:33 -0500, Sean Dague wrote:
The largeops tests at this point are mostly finding out that some of our
new cloud providers are slow - http://tinyurl.com/j5u4nf5
This is fundamentally a performance test, with timings having been tuned
to pass 98% of the time on two clouds that were v
makes sense to me. thanks for concise update and tracking this.
On 10/02/2016 7:59 AM, Davanum Srinivas wrote:
> +1 from me
>
> On Wed, Feb 10, 2016 at 7:56 AM, Jay Pipes wrote:
>> On 02/10/2016 07:33 AM, Sean Dague wrote:
>>>
>>> The largeops tests at this point are mostly finding out that some
Lots of questions, I'm sorry.
Are you planning to drop them indefinitely or is it temporary ? Is it to
help alleviate the gate from it's current misery ?
Why were these tests introduced in the first place ? To find issues or
bottenecks relative to scale or amount of operations ? Was it a request
On Fri, Feb 5, 2016 at 4:46 PM, Eric LEMOINE wrote:
> Hi Kolla devs
>
> The other day inc0 said that we would like "central logging" to be
> optional in Mitaka, and still use Rsyslog and keep the current
> behavior if "central logging" is disabled.
>
> I would like to propose an alternative, where
+1, although I would like to keep them to find scale bottlenecks. Maybe when
the new infra-cloud is up (we'll have full control over it, includind hw
access), we can pin these tests just to it.
Ghe Rivero
Quoting Sean Dague (2016-02-10 13:33:44)
> The largeops tests at this point are mostly fin
Hi,
I asked eventlet dev to *not* remove a release from PyPI before they did
it, but they ignored me and removed 0.18.0 and 0.18.1 releases from PyPI :-(
0.18.0 fixed a bug in Python 3:
https://github.com/eventlet/eventlet/issues/274
But 0.18.0 introduced a regression on Python 3 in WSGI:
htt
We stopped running tests under python 2.6 a while back, and I submitted
a bunch of patches to projects that still had the python package
classifier indicating support for python 2.6. Most of those merged, but
quite a few are still open [1]. Please take a look at the list and if
you find any for you
We are delighted to announce the release of:
reno 1.5.0: RElease NOtes manager
With source available at:
http://git.openstack.org/cgit/openstack/reno
With package available at:
https://pypi.python.org/pypi/reno
Please report issues through launchpad:
http://bugs.launchpad.net/ren
Hello,
We're in the process of adding IGMP and multicast support to Dragonflow[1]. The
added feature will route multicast packets only to relevant and registered VMs,
compute nodes, and handle IGMP packets.
This feature has some configuration parameters for subnets and router
interfaces.
Some of
On 02/10/2016 08:42 AM, David Moreau Simard wrote:
> Lots of questions, I'm sorry.
>
> Are you planning to drop them indefinitely or is it temporary ? Is it to
> help alleviate the gate from it's current misery ?
>
> Why were these tests introduced in the first place ? To find issues or
> bottene
Sean Dague wrote:
The largeops tests at this point are mostly finding out that some of our
new cloud providers are slow - http://tinyurl.com/j5u4nf5
This is fundamentally a performance test, with timings having been tuned
to pass 98% of the time on two clouds that were very predictable in
perf
This is a work we are doing in Dragonflow and is relatively simple to
implement leveraging
Dragonflow current infrastructure and reactive local controller.
This will significantly reduce duplicating packets for IGMP aware VMs. and
hence
reduce multicast load.
We would love to help and bring this
The gate-manila-tempest-dsvm-hdfs jenkins job has been failing for a
long time now. It appears to be a config issue that's probably not hard
to fix, but nobody is actively maintaining this code.
Since it's a waste of resources to continue running this broken job, I
plan to disable it, and if n
Hi all,
We discussed this in our meeting[1] this week, and agreed a ML discussion
to gain consensus and give folks visibility of the outcome would be a good
idea.
In summary, we adopted a more permissive "release branch" policy[2] for our
stable/liberty branches, where feature backports would be
Chris Dent wrote:
[...]
Observing this thread and "the trouble with names"[1] one I get
concerned that we're trending in the direction of expecting
projects/servers/APIs to be done and perfect before they will ever
be OpenStack. This, of course, runs entirely contrary to the spirit
of open source
It changes mostly nothing for case of furious plugin development when big
parts of code changed from one release to another.
You will have 6 different deployment_tasks directories and 30 a little bit
different files in root directory of plugin. Also you forgot about
repositories directory (+6 at l
Hi,
I'm doing a university project in OpenStack. The aim is to monitor virtual
routers per tenant with Monasca(which according to my knowledge hasn't been
implemented yet). The initial features would include monitoring of in/out
traffic per interface. I'm writing a plugin in Monasca for that purpo
Excerpts from Thierry Carrez's message of 2016-02-10 08:35:19 -0800:
> Chris Dent wrote:
> > [...]
> > Observing this thread and "the trouble with names"[1] one I get
> > concerned that we're trending in the direction of expecting
> > projects/servers/APIs to be done and perfect before they will ev
On 1/29/2016 12:08 AM, Renat Akhmerov wrote:
On 28 Jan 2016, at 17:40, Matt Riedemann wrote:
With regards to the trove 'plugin' stuff, it adds a new dependency on
python-troveclient which was not in sahara 1.0.0 in liberty GA, so IMO it's not
valid to release that in 1.0.1 and expect peop
Colleagues,
Centos bootstrap image (that we used to build together with the ISO) code
has been removed from fuel-main. Now the only available option is the
Ubuntu based bootstrap image that is built on the master node in run time.
>From this moment we are ready to get rid of building Fuel packages
Ihar Hrachyshka wrote:
> UPD: seems like enforcing instance mtu to 1400 indeed makes us pass forward
> into tempest:
>
> http://logs.openstack.org/59/265759/3/experimental/gate-grenade-dsvm-neutron-multinode/a167a59/console.html
>
> And there are only three failures there:
>
> http://logs.openst
Sean M. Collins wrote:
Ihar Hrachyshka wrote:
UPD: seems like enforcing instance mtu to 1400 indeed makes us pass
forward
into tempest:
http://logs.openstack.org/59/265759/3/experimental/gate-grenade-dsvm-neutron-multinode/a167a59/console.html
And there are only three failures there:
http
Excerpts from Sean Dague's message of 2016-02-10 04:33:44 -0800:
> The largeops tests at this point are mostly finding out that some of our
> new cloud providers are slow - http://tinyurl.com/j5u4nf5
>
> This is fundamentally a performance test, with timings having been tuned
> to pass 98% of the
Ihar Hrachyshka wrote:
> Actually, we already have 1450 for network_device_mtu for the job since:
>
> https://review.openstack.org/#/c/267847/4/devstack-vm-gate.sh
>
Ah! Forgot about that one. Cool.
> Also, I added some interface state dump for worlddump, and here is how the
> main node network
Hi,
I noticed that the coverage script is enforcing a hard limit of 4 on
the number of extra missing lines introduced. We have a requirement
that new drivers have 90% unit test coverage, which the ceph driver
meets[1], but it's tripping up on that absolute 4 line limit.
What do folks think about
On Wed, Feb 10, 2016 at 4:57 PM, Steven Hardy wrote:
> Hi all,
>
> We discussed this in our meeting[1] this week, and agreed a ML discussion
> to gain consensus and give folks visibility of the outcome would be a good
> idea.
>
> In summary, we adopted a more permissive "release branch" policy[2]
On 10/02/16 18:48, "Clint Byrum" wrote:
>Excerpts from Sean Dague's message of 2016-02-10 04:33:44 -0800:
>> The largeops tests at this point are mostly finding out that some of our
>> new cloud providers are slow - http://tinyurl.com/j5u4nf5
>>
>> This is fundamentally a performance test, with
On 2016-02-09 01:32:12 +0800 (+0800), Thomas Goirand wrote:
> While it is a good idea to enhance the current Ubuntu image, at the same
> time, I'd like to draw your attention that we need review for adding the
> Debian image too:
> https://review.openstack.org/#/c/264726
>
> Igor Belikov did an am
Hi, John. This is but one reason the coverage job doesn¹t vote; it has
other known issues. It is primarily a convenience tool that lets core
reviewers know if they should look more deeply into unit test coverage.
For a new driver such as yours, I typically pull the code and check
coverage for eac
Hi,
I'm doing a university project in OpenStack. The aim is to monitor virtual
routers per tenant with Monasca(which according to my knowledge hasn't been
implemented yet). The initial features would include monitoring of in/out
traffic per interface. I'm writing a plugin in Monasca for that purpo
Hello, John
Note, that digit "4" defines amount of "python code blocks", not "python
code lines". So, you can have uncovered some log message that consists of
100 lines. But it will be counted as just 1.
Who "we" have requirement that new drivers have 90% unit test coverage?
And, Manila CI coverag
Hi,
I accidentally ran the meeting early, due to not having re-downloaded a
fresh iCal export. So I had the wrong time.
For background:
https://github.com/openstack-infra/yaml2ical/commit/4def663a8d5259962d5c2239266ebfaa19082bf6
So anyway, please ensure that your calendar is updated with a fres
Hi,
the pep8 target is our usual target to include style and lint checks and
thus is used besides pep8 also for doc8, bashate, bandit, etc as
documented in the PTI (=Python Test Interface,
http://governance.openstack.org/reference/cti/python_cti.html).
We've had some discussions to introduce a ne
On 02/04/2016 06:38 AM, Sean Dague wrote:
> 2) Have a registry of "common" names.
>
> Upside, we can safely use common names everywhere and not fear collision
> down the road.
>
> Downside, yet another contention point.
>
> A registry would clearly be under TC administration, though all the
> he
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/05/2016 01:27 PM, Mike Perez wrote:
>>> So while Poppy may not fully qualify for the open core label,
>>> it still fails some of the tests that we want to see, such as a
>>> usable open source implementation.
>> From a QA perspective in gate,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/05/2016 01:16 PM, Sean Dague wrote:
> Whether or not it is, I'm not sure how it is part of a Ubiquitous
> Open Source Cloud Platform. Because it only enables the use of
> commerical services.
>
> It's fine that it's open source software. I ju
Devstack has some half baked support for keystone templated service
catalog. In an effort to clean up parts of devstack, we're dropping that
- https://review.openstack.org/#/c/278333
However... this unfortunately led to some cargo culting, and everyone's
devstack plugin is going to fail if we remo
On Tue, Feb 9, 2016 at 1:21 PM, Kevin Benton wrote:
> If you see any issues, either propose a patch directly or file a bug against
> https://bugs.launchpad.net/openstack-manuals/+filebug with the tag
> 'seg-guide'
Did you want 'sec-guide'? That would seem more intuitive to me.
Carl
___
On 10/02/2016 11:35 AM, Thierry Carrez wrote:
> Chris Dent wrote:
>> [...]
>> Observing this thread and "the trouble with names"[1] one I get
>> concerned that we're trending in the direction of expecting
>> projects/servers/APIs to be done and perfect before they will ever
>> be OpenStack. This,
There's two main types of services in openstack. Those that are a multitenant
aware implementation of some kind of data plane protocol with an "openstack"
api. Swift/radosgw, Zaqar, MagnetoDB, etc. I think we can ignore these in this
discussion.
Then there's what I consider the more "Operating
On Mon, Feb 8, 2016 at 9:40 AM, Assaf Muller wrote:
> As for DVR, I'm searching for someone to pick up the gauntlet and
> contribute some L3 fullstack tests. I'd be more than happy to review
> it! I even have an abandoned patch that gets the ball rolling (The
> idea is to test L3 east/west, north/
Yes, sorry.
On Feb 10, 2016 12:52, "Carl Baldwin" wrote:
> On Tue, Feb 9, 2016 at 1:21 PM, Kevin Benton wrote:
> > If you see any issues, either propose a patch directly or file a bug
> against
> > https://bugs.launchpad.net/openstack-manuals/+filebug with the tag
> > 'seg-guide'
>
> Did you wan
On 10/02/16 21:53, "gordon chung" wrote:
>
>
>On 10/02/2016 11:35 AM, Thierry Carrez wrote:
>> Chris Dent wrote:
>>> [...]
>>> Observing this thread and "the trouble with names"[1] one I get
>>> concerned that we're trending in the direction of expecting
>>> projects/servers/APIs to be done and
On 02/10/2016 03:03 PM, Sean Dague wrote:
On 02/04/2016 06:38 AM, Sean Dague wrote:
2) Have a registry of "common" names.
Upside, we can safely use common names everywhere and not fear collision
down the road.
Downside, yet another contention point.
A registry would clearly be under TC admini
+1 to Stas, supplanting VCS branches with code duplication is a path to
madness and despair. The dubious benefits of a cross-release backwards
compatible plugin binary are not worth the code and infra technical debt
that such approach would accrue over time.
On Wed, Feb 10, 2016 at 07:36:30PM +030
On Tue, Feb 9, 2016 at 3:23 PM, Ildikó Váncsa
wrote:
> Hi Walt,
>
> > -Original Message-
> > From: Walter A. Boring IV [mailto:walter.bor...@hpe.com]
> > Sent: February 09, 2016 23:15
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, d
On Wed, Feb 10, 2016 at 03:30:42PM -0700, John Griffith wrote:
> On Tue, Feb 9, 2016 at 3:23 PM, Ildikó Váncsa
> wrote:
>
> >
> This may still be in fact the easiest way to handle this. The only other
> thing I am still somewhat torn on here is that maybe Nova should be doing
> ref-counting WRT
Jim,
I've had this reply queued up for a week now. Sorry for the delay.
The problem that I run in to when I work with multiple dependent
changes doesn't seem to be covered by your description.
For me, the trouble with this workflow comes when there is more than
one contributor working on a chain
On Wed, Feb 10, 2016 at 3:59 PM, Sean McGinnis
wrote:
> On Wed, Feb 10, 2016 at 03:30:42PM -0700, John Griffith wrote:
> > On Tue, Feb 9, 2016 at 3:23 PM, Ildikó Váncsa <
> ildiko.van...@ericsson.com>
> > wrote:
> >
> > >
> > This may still be in fact the easiest way to handle this. The only
>
On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote:
> as for c) I think it's a little late to make pluggable ipam default in
> Mitaka; I'd rather switch defaults early in the cycle (depending on the
> entity of the config) and this one seems serious enough that I'd rather have
> enough exercising in
I think part of the issue is whether to count or not is cinder driver specific
and only cinder knows if it should be done or not.
But if cinder told nova that particular multiattach endpoints must be
refcounted, that might resolve the issue?
Thanks,
Kevin
___
On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote:
> Technically we can make this as sophisticated and seamless as we want, but
> this is a one-off, once it's done the pain goes away, and we won't be doing
> another migration like this ever again. So I wouldn't over engineer it.
Frankly, I was wor
On Wed, Feb 10, 2016 at 11:16:28PM +, Fox, Kevin M wrote:
> I think part of the issue is whether to count or not is cinder driver
> specific and only cinder knows if it should be done or not.
>
> But if cinder told nova that particular multiattach endpoints must be
> refcounted, that might r
On 10/02/2016 4:28 PM, Tim Bell wrote:
>
> On 10/02/16 21:53, "gordon chung" wrote:
>
>> apologies if this was asked somewhere else in thread, but should we try
>> to define "production" scale or can we even? based on the last survey,
>> the vast majority of deployments are under 100nodes[1]. th
On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko
wrote:
> +1 to Stas, supplanting VCS branches with code duplication is a path to
> madness and despair. The dubious benefits of a cross-release backwards
> compatible plugin binary are not worth the code and infra technical debt
> that such approa
Was a bug ever filed for this? It's still not on the landing page
On Thu, Feb 4, 2016 at 4:19 AM Ivan Kolodyazhny wrote:
> Thanks, Igor.
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Thu, Feb 4, 2016 at 1:21 PM, Igor Belikov
> wrote:
>
>> Hi Ivan,
>>
>> I think this counts as
But the issue is, when told to detach, some of the drivers do bad things. then,
is it the driver's issue to refcount to fix the issue, or is it nova's to
refcount so that it doesn't call the release before all users are done with it?
I think solving it in the middle, in cinder's probably not the
On 10/02/16 18:05, James Slagle wrote:
On Wed, Feb 10, 2016 at 4:57 PM, Steven Hardy mailto:sha...@redhat.com>> wrote:
Hi all,
We discussed this in our meeting[1] this week, and agreed a ML
discussion
to gain consensus and give folks visibility of the outcome would be
a
Hi Heat team,
As mentioned in IRC, magnum gate broke with bug 1544227 . Rabi submitted on a
fix (https://review.openstack.org/#/c/278576/), but it doesn't seem to be
enough to unlock the broken gate. In particular, it seems templates with
SoftwareDeploymentGroup resource failed to complete (I h
Hey everybody,
tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and
APT repos with additional wheel repos containing pre-built wheels for
all the modules in global-requirements
We've just rolled out a new change that you should mostly never notice -
except that jobs should
Hi All,
I confess up front that I'm pretty green in the is area and there is a lot
of history that I just don't have. That wont stop me from asking/opening the
discussion.
As I ask in $subject: why do we install with --upgrade in our tox environments?
Are there issues this is fixing/hiding?
w00t! thanks infra team
On Wed, Feb 10, 2016 at 7:45 PM, Monty Taylor wrote:
> Hey everybody,
>
> tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and APT
> repos with additional wheel repos containing pre-built wheels for all the
> modules in global-requirements
>
> We've just
Hey Andreas,
Why not keep pep8 as an alias for the new linters target? Would this allow
for a transition path while work on updating the PTI is done?
Cheers,
Josh
On Thu, Feb 11, 2016 at 6:55 AM, Andreas Jaeger wrote:
> Hi,
>
> the pep8 target is our usual target to include style and lint chec
On Wed, Feb 10, 2016 at 06:45:25PM -0600, Monty Taylor wrote:
> Hey everybody,
>
> tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and APT
> repos with additional wheel repos containing pre-built wheels for all the
> modules in global-requirements
Woot!
I do have a couple of
We've just had a mass gate breakage due to
https://review.openstack.org/#/c/268945/ go through, so I thought I'd
try to get ahead of anyone trying this again.
unittest.mock in the stdlib is not static, it evolves over time. We're
currently writing to - and depending on - the unittest.mock version
On Wed, Feb 10, 2016, at 06:02 PM, Tony Breeds wrote:
> On Wed, Feb 10, 2016 at 06:45:25PM -0600, Monty Taylor wrote:
> > Hey everybody,
> >
> > tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and APT
> > repos with additional wheel repos containing pre-built wheels for all the
On Wed, Feb 10, 2016, at 05:46 PM, Tony Breeds wrote:
> Hi All,
> I confess up front that I'm pretty green in the is area and there is
> a lot
> of history that I just don't have. That wont stop me from asking/opening
> the
> discussion.
>
> As I ask in $subject: why do we install with --
We have a fix for one of the most egregious bugs in the history of
Keystone: https://bugs.launchpad.net/keystone/+bug/968696 The only
problem is, it requires a configuration file change. A deployer needs to
set the values:
CONF.resource.admin_project_name
CONF.resource.admin_domain_name
How
I've fast tracked the revert - https://review.openstack.org/#/c/278814/
On Wed, Feb 10, 2016 at 9:38 PM, Robert Collins
wrote:
> We've just had a mass gate breakage due to
> https://review.openstack.org/#/c/268945/ go through, so I thought I'd
> try to get ahead of anyone trying this again.
>
> u
On Wed, Feb 10, 2016 at 07:07:22PM -0800, Clark Boylan wrote:
> On Wed, Feb 10, 2016, at 06:02 PM, Tony Breeds wrote:
> > On Wed, Feb 10, 2016 at 06:45:25PM -0600, Monty Taylor wrote:
> > > Hey everybody,
> > >
> > > tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and
> > > AP
On Wed, Feb 10, 2016 at 5:12 PM, Fox, Kevin M wrote:
> But the issue is, when told to detach, some of the drivers do bad things.
> then, is it the driver's issue to refcount to fix the issue, or is it
> nova's to refcount so that it doesn't call the release before all users are
> done with it? I
On 2016-02-11 14:41:03 +1100 (+1100), Tony Breeds wrote:
[...]
> Okay We'll need to think about that one as the contrainst in
> stable/kilo can be bogus, sometime we have a version in contraints
> that isn't valid compared to g-r
[...]
Oh, right since there's an upper-constraints.txt in stable/kil
Hi,
We did some analysis of the issue you are facing.
One of the issues from heat side is, we convert None(singleton) resource
references
to 'None'(string) and the translation logic is not ignoring them. Though we
don't
apply translation rules to resource references[1].We don't see this issue
Right now master (targeting 9.0) is still deploying liberty and there is
active work going on to support both Kilo and Mitaka. On the review queue
are changes that would make fuel-library in-compatible with the prior
(liberty) openstack release. However I think if we extend a little bit of
effort w
On Thu, Feb 11, 2016 at 04:46:39AM +, Jeremy Stanley wrote:
> On 2016-02-11 14:41:03 +1100 (+1100), Tony Breeds wrote:
> [...]
> > Okay We'll need to think about that one as the contrainst in
> > stable/kilo can be bogus, sometime we have a version in contraints
> > that isn't valid compared to
I think Sean and John are in the right direction. Nova and Cinder need to
be more decoupled in the area of volume attachments.
I think some of the mess here is due to different Cinder backend behavior -
with some Cinder backends you actually attach volumes to a host (e.g., FC,
iSCSI), with some y
I started noticing more of the Trove gate jobs failing in the last 24 hours
and I think i've tracked it down to this mirror specifically.
http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/
It looks like its missing the python-software-properties package and
causing our gate job to fail. I fou
I agree with Stas, one rpm - one version.
But plugin builder allows to specify several releases as compatible. The
deployment tasks and repositories can be specified per release, at the same
time the deployment graph is one for all releases.
Currently it looks like half-implemented feature. Can
Sean Dague wrote:
[...]
3) This be a dedicated repository 'openstack/service-registry'. The API
WG will have votes on it (I would also suggest the folks that have been
working on Service Catalog TNG - myself, Anne Gentle, Brant Knudson, and
Chris Dent be added to this). The actual registry will b
On 11/02/16 00:33, "gordon chung" wrote:
>
>
>On 10/02/2016 4:28 PM, Tim Bell wrote:
>>
>> On 10/02/16 21:53, "gordon chung" wrote:
>>
>>> apologies if this was asked somewhere else in thread, but should we try
>>> to define "production" scale or can we even? based on the last survey,
>>> the v
95 matches
Mail list logo