y, or the project with
the unit test is mocking something out poorly (like we've seen lately
with nova and python-neutronclient releases).
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not
om landing before feature freeze.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.o
On 8/18/2016 12:14 PM, Matthew Treinish wrote:
On Thu, Aug 18, 2016 at 11:33:59AM -0500, Matthew Thode wrote:
On 08/18/2016 10:00 AM, Matt Riedemann wrote:
It's that time of year again to talk about killing this job, at least
from the integrated gate (move it to experimental for people
any of those we can have a 24 hour turnaround
on getting an approved change back through the gate.
[1]
https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf
--
Thanks,
Matt Riedemann
__
OpenStack
ck.org/#/c/353018/
--
If you need anything from me before I leave please get me with in IRC
today or tomorrow.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
On 8/16/2016 9:52 PM, Matt Riedemann wrote:
My nova-net local.conf isn't working anymore apparently, neutron is
still getting installed and run rather than nova-network even though I
have this in my local.conf:
stack@novanet:~$ cat devstack/local.conf | grep enable_service
enable_se
o get nova-network running instead.
It's also nearly my bedtime and I'm being lazy, so figured I'd post this
if for nothing else a heads up that people's local configs for
nova-network might no longer work with neutron being the default.
, but the python API code with 2.36 will not be
handling a transition for you, the proxy APIs will fail with a 404 at
2.36 (but the APIs are opt-in for that microversion).
Please speak up soon if this hits you in any way because we plan to have
these changes merged this week and do a release
On 8/16/2016 12:39 AM, Afek, Ifat (Nokia - IL) wrote:
On 15/08/2016, 19:29, "Matt Riedemann" wrote:
On 8/15/2016 4:24 AM, Afek, Ifat (Nokia - IL) wrote:
Hi,
In Vitrage project[1], I would like to add an option to call nova host-evacuate
for a failed host. I noticed that t
ience CLI, it's not for a
specific API, it just takes a host, finds the instances running on that
host and evacuates each of them. You could do something similar in vitrage.
--
Thanks,
Matt Riedemann
__
OpenStack Deve
On 8/15/2016 10:37 AM, Matt Riedemann wrote:
On 8/11/2016 6:26 PM, Andrew Laski wrote:
On Thu, Aug 11, 2016, at 06:54 PM, Chris Friesen wrote:
On 08/11/2016 03:53 PM, Matt Riedemann wrote:
I wanted to bring this up for awareness since we're getting close to
feature
freeze and want cons
On 8/11/2016 6:26 PM, Andrew Laski wrote:
On Thu, Aug 11, 2016, at 06:54 PM, Chris Friesen wrote:
On 08/11/2016 03:53 PM, Matt Riedemann wrote:
I wanted to bring this up for awareness since we're getting close to feature
freeze and want consensus before it gets too late.
Ken'ichi
et the captured
stdout/stderr and decide what to do with it.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
On 8/12/2016 1:03 PM, Dean Troyer wrote:
On Fri, Aug 12, 2016 at 10:13 AM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:
Another idea is the base functional test that sets up the client
just checks the keystone service catalog for a 'network' service
ent
On 8/12/2016 8:54 AM, Matt Riedemann wrote:
On 8/12/2016 8:52 AM, Matt Riedemann wrote:
On 8/12/2016 8:24 AM, Sean McGinnis wrote:
On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote:
A devstack patch was pushed earlier this cycle around os-brick -
https://review.openstack.org/341744
novaclient/blob/232711c0ef98baf79bcf4c8bdbae4b84003c9ab9/novaclient/tests/functional/base.py#L116
Thoughts on either approach or something completely different?
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
On 8/12/2016 8:52 AM, Matt Riedemann wrote:
On 8/12/2016 8:24 AM, Sean McGinnis wrote:
On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote:
A devstack patch was pushed earlier this cycle around os-brick -
https://review.openstack.org/341744
Apparently there are some os-brick operations
ail w/o this? Vague "trust me, you need to do this or else"
release notes that impact how people deploy is not fun, so I'd like more
details before we just put this out there.
--
Thanks,
Matt Riedemann
__
ted for sure.
So I'm looking for input on that idea before we get too late, is that
difference worth the work and syntax change in how the client requests a
network when creating a server?
--
Thanks,
Matt Riedemann
_
to have to land some changes to move
novaclient itself off of the nova proxy APIs before we can land the
support for 2.36 as the default in the CLI.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing L
d.
Stop to support them after 2.35.
Thanks
Alex
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mail
+1 from me also. This will help everyone who is trying to transition to it.
On Wed, Aug 10, 2016 at 1:46 AM, Javier Pena wrote:
>
>
> - Original Message -
> > Hi,
> >
> > Today Puppet OpenStack CI is running unit and functional test jobs
> > against puppet 3 and puppet 4.
> > Unit jobs f
On 8/8/2016 4:10 PM, Clint Byrum wrote:
Excerpts from Matt Riedemann's message of 2016-08-08 14:35:12 -0500:
Not to be a major curmudgeon but I think we'd basically decided at the
midcycle (actually weeks before) that Nova wasn't doing the mascot thing.
Could you maybe summa
On 8/8/2016 3:36 PM, Chris Friesen wrote:
On 08/08/2016 01:35 PM, Matt Riedemann wrote:
Not to be a major curmudgeon but I think we'd basically decided at the
midcycle
(actually weeks before) that Nova wasn't doing the mascot thing.
What will the Foundation do if nova doesn&#
asn't doing the mascot thing.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.opensta
the host part optional (but
admin-only if specified). But the user could request the capabilities of
the cloud which would be aggregated from the host (resource provider)
capabilities.
Anyway, thanks for kicking off a separate thread on this. I think we're
going to need a sessi
On 8/3/2016 1:44 AM, Alex Xu wrote:
2016-08-03 14:40 GMT+08:00 Alex Xu mailto:sou...@gmail.com>>:
2016-08-02 22:09 GMT+08:00 Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>>:
On 8/2/2016 2:41 AM, Alex Xu wrote:
A little strange we have two API en
-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Clone the repo and checkout the icehouse-eol tag, that will put you in a
detached head state at which point you can create a branch from it.
--
Thanks,
Matt Ried
ut I think multinode is the
biggest one so that we can test resize/migrate of servers with NFV features.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
On 8/3/2016 8:18 AM, Znoinski, Waldemar wrote:
[WZ] Hi Matt, do we need, a Gerrit-style, +2 on that from someone?
Infra Team doesn't keep these settings in their puppet/config files on git -
all the Gerrit changes are done via Gerrit GUI so they rely on Cores to add CIs
to the appropria
escue a volume-backed instance:
https://review.openstack.org/#/c/270288/18/nova/compute/api.py
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-d
On 8/2/2016 9:09 AM, Matt Riedemann wrote:
On 8/2/2016 2:41 AM, Alex Xu wrote:
A little strange we have two API endpoints, one is
'/servers/{uuid}/os-interfaces', another one is
'/servers/{uuid}/os-virtual-interfaces'.
I prefer to keep os-attach-interface. Due to I think
On 8/2/2016 12:25 PM, Jim Rollenhagen wrote:
On Mon, Aug 01, 2016 at 09:15:46PM -0500, Matt Riedemann wrote:
* Placement API for resource providers
Jay's personal goal for Newton is for the resource tracker to be writing
inventory and allocation data via the placement API. We want t
le.
Thanks for hearing me out,
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/l
interface actually accept the server_id, and there is check
ensure the port belong to the server. So it shouldn't very hard to get
the vif info and tag.
And sorry for I missed that when coding patches also...let me if you
need any help at here.
--
ed
But that will break the DB archive command if you're actually using these.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
Ceph/FC to make sure these changes would be OK for them,
and to check on live migration testing (PureStorage is working on
multinode live migration test coverage for their third party CI using
iscsi/fibrechannel).
Matt Treinish also helped sort out some issues with getting a cinder
multi-bac
On 8/1/2016 4:19 PM, Matt Riedemann wrote:
It's a little late but I wanted to get a high level recap of the nova
newton midcycle written up for those that didn't make it.
First off, thanks again to Intel for hosting and especially to Cindy
Sirianni at Intel for making sure we were tak
ges for this are the REST API microversion change
(2.37):
https://review.openstack.org/#/c/316398/
Which is being tested by the Tempest test and devstack change:
https://review.openstack.org/#/c/327901/
But those should be in good shape for Newton.
* Vendor metadata reboot
We agreed that
On 8/1/2016 1:39 PM, Ken'ichi Ohmichi wrote:
2016-07-29 10:32 GMT-07:00 Sean Dague :
On 07/28/2016 05:38 PM, Matt Riedemann wrote:
On 7/28/2016 3:55 PM, Matt Riedemann wrote:
For os-attach-interfaces, we need that to attach/detach interfaces to a
server, so those actions don't go
On 7/29/2016 10:47 AM, Znoinski, Waldemar wrote:
Hi Matt et al,
Thanks for taking the time to have a chat about it in Nova meeting yesterday.
In relation to your two points below...
1. tempest-dsvm-ovsdpdk-nfv-networking job in our Intel NFV CI was broken for
about a day till we troubleshooted
On 7/29/2016 12:32 PM, Sean Dague wrote:
On 07/28/2016 05:38 PM, Matt Riedemann wrote:
On 7/28/2016 3:55 PM, Matt Riedemann wrote:
For os-attach-interfaces, we need that to attach/detach interfaces to a
server, so those actions don't go away with 2.36. We can also list and
show inter
bscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not fo
On 7/28/2016 3:55 PM, Matt Riedemann wrote:
For os-attach-interfaces, we need that to attach/detach interfaces to a
server, so those actions don't go away with 2.36. We can also list and
show interfaces (ports) which is a proxy to neutron, but in this case it
seems a tad bit necessary, el
On 7/28/2016 3:55 PM, Matt Riedemann wrote:
So I think we're OK with os-attach-interfaces (even though it does some
proxying right now), but I'm thinking we should be deprecating
os-virtual-interfaces.
Or if we don't deprecate os-virtual-interfaces, we should implement it
w to list ports via neutron CLI and filter on
device_id=server.uuid.
So I think we're OK with os-attach-interfaces (even though it does some
proxying right now), but I'm thinking we should be deprecating
os-virt
ewton+status:open
There are a ton of the mox conversion changes so I'm not going to be
-2ing all of those, just be aware we're done reviewing those for newton
and will open up again in ocata.
--
Thanks,
Matt Riedemann
_
+1 from me!
On Jul 28, 2016 9:20 AM, "Emilien Macchi" wrote:
> You might not know who Sofer is but he's actually "chem" on IRC.
> He's the guy who will find the root cause of insane bugs, in OpenStack
> in general but also in Puppet OpenStack modules.
> Sofer has been working on Puppet OpenStack
ng problem? The team worked around it for now, but it is a concern
of mine. I think at least the Xen and PowerKVM CIs also run on devstack
changes to avoid problems like this.
So please give me some details on running against devstack changes and
then I'll ack or nack the request.
--
On 7/20/2016 7:01 PM, Nikhil Komawar wrote:
Thanks Matt. The bug looked very descriptive so, I commented my thoughts
there https://bugs.launchpad.net/python-glanceclient/+bug/1596602
On 7/20/16 4:18 PM, Matt Riedemann wrote:
On 7/18/2016 4:41 AM, Erno Kuvaja wrote:
On Mon, Jul 18, 2016 at 5
On 7/26/2016 11:59 AM, Matt Riedemann wrote:
Now that the 2.36 microversion change has merged [1], we can work on the
python-novaclient changes for this microversion.
At the midcycle we agreed [2] to also return a 404 for network APIs,
including nova-network (which isn't a proxy)
://review.openstack.org/#/c/337005/
[2] https://etherpad.openstack.org/p/nova-newton-midcycle
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
On 7/22/2016 8:20 AM, Angus Lees wrote:
On Thu, 21 Jul 2016 at 09:27 Sean Dague mailto:s...@dague.net>> wrote:
On 07/12/2016 06:25 AM, Matt Riedemann wrote:
> We probably aren't doing anything while Sean Dague is on vacation.
He's
> back next wee
On 7/14/2016 4:40 PM, Matt Riedemann wrote:
On 7/14/2016 3:11 AM, GHANSHYAM MANN wrote:
1. Always add a schema change to Tempest if a microversion changes a
response.
The problem with this is we shouldn't land a schema change by itself
in tempest.
Until we have something using the sche
openstack-dev
Cinder's tox.ini on stable/liberty isn't using upper-constraints, it
should be and will fix the problem.
So cherry-pick https://review.openstack.org/#/c/312438/ and fix the
branch used in the
On 7/21/2016 10:31 AM, Matt Riedemann wrote:
There are still quite a few specs up for review in the newton directory
in the nova-specs repo. Those should be moved to the ocata directory if
you plan on pursuing those for the Ocata release (keeping in mind we're
not actively reviewing spec
an't
push up a spec to get early feedback from interested parties).
For those that don't move by August 4th are subject to being abandoned.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not
sier to use/understand than something like
testscenarios, which we're already using in Nova.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.o
On 7/18/2016 4:41 AM, Erno Kuvaja wrote:
On Mon, Jul 18, 2016 at 5:19 AM, Nikhil Komawar wrote:
Thanks Matt. I've scheduled for a release of the client this week.
On 7/16/16 4:09 AM, Matt Riedemann wrote:
This is more of a heads up than anything.
Our internal CI is running Tempest
d
and any specs? I see 'user' thrown around a lot, but there are different
kinds of users. Only admins can see host aggregates and their metadata.
And when we're talking about how these tags will be used, let's be clear
about who the ac
deletes keypairs for user_ids
that don't exist in Keystone...
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr
On 7/18/2016 9:42 AM, Matt Riedemann wrote:
On 7/18/2016 9:09 AM, Markus Zoeller wrote:
Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
Logstash counts 70 hits/h [4]. Most folks will b
603979
[4] logstash: http://goo.gl/79yFb9
This is an API change for oslo.context, why wasn't it released as 3.0.0?
Seems we should revert the upper-constraints bump and blacklist 2.6.0,
then get that released as 3.0.0.
I think we can help. Do you want us to submit patches for config option
descriptions that benefit from rewording? Also, you might want to post to
the -docs list.
On Mon, Jul 18, 2016 at 6:29 AM, Markus Zoeller wrote:
> I'd like to ask the docs team if they see the possibility to have
> reviews o
On 7/17/2016 4:13 PM, Jay Pipes wrote:
On 07/15/2016 08:36 AM, Hayes, Graham wrote:
On 14/07/2016 21:20, Matt Riedemann wrote:
And does this also include plugins within projects, like storage
backends in cinder and hypervisor drivers in nova?
This is aimed at cross project interaction. So
proxy CLI/APIs
- baremetal proxy CLI/APIs
- the --volume-service-name option
And bumps the cap on supported microversions to 2.32.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questio
bal-requirements
for Newton.
I'm not really sure why python-glanceclient even has it's own copy of
the image schema, that seems redundant and error prone given the glance
API already validates that, but it's kind of beside
Hi Jesse,
I like the idea of a water buffalo, as they're working animals used in
farming etc. This links nicely to the project as these animals 'do the
heavy lifting', so to speak. An ox, etc. could be another appropriate
mascot.
--Matt
On Fri, Jul 15, 2016 at 2:15 PM,
On 7/13/2016 10:18 PM, Ken'ichi Ohmichi wrote:
Hi Matt,
2016-07-14 11:55 GMT+09:00 Matt Riedemann :
There are several changes in Tempest right now trying to add response schema
validation for the 2.26 microversion which added server tags to the server
GET response. This is needed for any
o be updated for the other extended server
attributes in that microversion, but it's the immediate thing I want to
get fixed so we can get on with making the
gate-tempest-dsvm-neutron-full-ssh job voting.
--
Thanks,
Matt Riedemann
On 7/14/2016 11:34 AM, Paul Bourke wrote:
Hi Matt,
Here is the failure from nova_compute on trying to start an instance:
2016-07-13 18:04:12.634378 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service [req-0d77b2c1-43c8-41de-b57f-8aaa974b9807 - - - -
-] Error starting thread.
2016-07-13 18
e
backends in cinder and hypervisor drivers in nova?
Nova has been pushing for a few releases now on getting rid of plug
points since they are barriers to interoperability.
--
Thanks,
Matt Riedemann
__
OpenStack Development Ma
github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L633
Could be something patched out of the versions you're using from the
distro maybe?
The actual failure paste/trace would help.
--
Thanks,
Matt Riedemann
_
to create a server, or use
other services like glance/cinder/neutron.
mtreinish and sdague will be at the nova midcycle so hopefully they can
represent for the QA team.
--
Thanks,
Matt Riedemann
__
OpenStack D
I think we should also add a microversion to the API in Ocata to disable
the ability to create new quota classes, so that update is only update,
and a 404 for anything else.
--
Thanks,
Matt Riedemann
__
OpenStack Developm
; > The folks that contribute to the keystone guides today would still be
> very
> > welcomed to continue to contribute once/if the switch is made.
> >
> > On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara
> wrote:
> >
> >> Currently, OpenStack provides cent
t the Intel site, so
we'll be meeting at the Holiday Inn Express.
I've updated the location section and added a link for directions to the
wiki.
Let me know if there are any questions.
[1] https://wiki.openstack.org/wiki/Sprints/NovaNewtonSprin
thon-brick-cinderclient-ext.
Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
On Wed, Jun 22, 2016 at 5:47 PM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:
On 6/21/2016 10:12 PM, Angus Lees wrote:
On Wed, 22 Jun 2016 at 05:59 Matt Riedemann
mailto:mrie...@li
Inline...
On Sun, Jul 10, 2016 at 5:22 PM, Lana Brindley
wrote:
> On 09/07/16 07:02, Matt Kassawara wrote:
> > Currently, OpenStack provides central documentation (primarily in the
> openstack-manuals repository) for operators and users. The single location
> and consistent
Andreas,
I consider the API documentation and installation guide rather complex for
initial content to move to project repositories and evaluate the results.
However, we're seeing rather strong adoption of moving API documentation
which I think predicts adoption of moving operator/user documentati
All MTU changes must occur on a layer-3 device, typically a router. If a
router receives a packet with an MTU larger than the next-hop interface, it
can either fragment it or use path MTU discovery (PMTUD) to inform the
sender of the next-hop interface MTU value [1]. Fragmentation causes
performanc
e for that project?
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/ma
to mid-cycles (including ops) and
the next summit.
Matt
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org
pect most users/deployments are just running their own forks.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
On 7/6/2016 8:06 PM, Angus Lees wrote:
On Thu, 7 Jul 2016 at 03:06 Matthew Treinish mailto:mtrein...@kortar.org>> wrote:
On Wed, Jul 06, 2016 at 11:41:56AM -0500, Matt Riedemann wrote:
> I just wonder how many deployments are actually relying on this,
since as
> not
ure freeze. The ironic changes are all merged yet
either when we were going over FFE candidates. So this is going to have
to wait for Ocata.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage
eady as of today needs to wait for Ocata.
5. https://blueprints.launchpad.net/nova/+spec/rm-object-dict-compat-newton
This is now closed for Newton. We'll pick this up again in Ocata.
--
Thanks,
Matt Riedemann
__
Open
ly so we don't break people who are relying on our current
guarantees, regardless of how bad they are.
-Matt Treinish
I just wonder how many deployments are actually relying on this, since
as noted elsewhere in this thread we don't really enforce this for all
things, only what
On 7/5/2016 4:31 AM, Balázs Gibizer wrote:
-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: July 01, 2016 23:03
We're now past non-priority feature freeze. I've started going through
some blueprints and -2ing them if they still have outstandi
spec.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rt until you adjusted your
profile manually.
So we are not aiming for A, we're actually aiming much higher. But
testing, consistently, that much higher bar is a thing we can't easily
do. So the structure of the testing for our offline upgrades, with the
policy rules about what w
a separate thread in the operators list
about that.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http:/
r services like cinder
or neutron, or it hits new behavior in the virt drivers.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
We're using Designate but still on Juno. We're running puppet from around
then, summer of 2015. We'll likely try to upgrade to Mitaka at some point
but Juno Designate "just works" so it's been low priority. Look forward to
your efforts here.
On Tue, Jul 5, 2016 at 7:47 PM, David Moreau Simard wro
On 7/4/2016 11:30 AM, Ben Swartzlander wrote:
On 07/03/2016 09:19 AM, Matt Riedemann wrote:
On 7/1/2016 8:18 PM, Ravi, Goutham wrote:
Thanks Matt.
https://review.openstack.org/#/c/334220 adds the upper constraints.
--
Goutham
On 7/1/16, 5:08 PM, "Matt Riedemann" wrote:
On 7/5/2016 4:36 PM, Matt Riedemann wrote:
On 7/4/2016 8:45 AM, Matt Riedemann wrote:
On 7/4/2016 3:40 AM, Daniel P. Berrange wrote:
Won't the user provided files also get made available by the config
drive /
metadata service ? I think that's the primary reason for file
injection n
On 7/4/2016 8:45 AM, Matt Riedemann wrote:
On 7/4/2016 3:40 AM, Daniel P. Berrange wrote:
Won't the user provided files also get made available by the config
drive /
metadata service ? I think that's the primary reason for file
injection not
being a fatal problem. Oh that and the
For the record we're on 3.5.6-1.
On Jul 5, 2016 11:27 AM, "Mike Lowe" wrote:
> I was having just this problem last week. We updated to 3.6.2 from 3.5.4
> on ubuntu and stated seeing crashes due to excessive memory usage. I did
> this on each node of my rabbit cluster and haven’t had any problems
Yes! This happens often but I'd not call it a crash, just the mgmt db gets
behind then eats all the memory. We've started monitoring it and have
runbooks on how to bounce just the mgmt db. Here are my notes on that:
restart rabbitmq mgmt server - this seems to clear the memory usage.
rabbitmqctl
to fly because of config drive (which I could
check from the virt driver) and the metadata service (which I can't from
the virt driver). So I guess the best we can do is log something...
--
Thanks,
Matt Riedemann
__
Open
1201 - 1300 of 2614 matches
Mail list logo
