[openstack-dev] [Manila]Question about the usage of "connect_share_server_to_tenant_network"

Hi list, For generic driver, there is a flag named "connect_share_server_to_tenant_network" in manila/share/drivers/service_instance.py. When it set to True, share-server(nova instance) would be created directly on the "share-network". When it set to False, the subnet within share-network must

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

I proposed an alternative to adjusting the lease time early on the in the thread. By specifying the renewal time (DHCP option 58), we can have the benefits of a long lease time (resiliency to long DHCP server outages) while having a frequent renewal interval to check for IP changes. I favored this

Re: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance benchmarking

You can try with httperf[1], or ab[2] for http workloads. If you will use overlay, make sure your network MTU is correctly configured to handle the extra size of the overlay (GRE / VXLAN packets) otherwise you will be introducing fragmentation overhead on the tenant networks. [1] http://ww

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

On Wed, Feb 04, 2015 at 08:59:54, Kevin Benton wrote: > I proposed an alternative to adjusting the lease time early on the in > the thread. By specifying the renewal time (DHCP option 58), we can > have > the benefits of a long lease time (resiliency to long DHCP server > outages) while having a fr

Re: [openstack-dev] [Neutron] [ML2] [arp] [l2pop] arp responding for vlan network

Hi henry, It looks great and quite simple thanks to the work done by the ofagent team. This kind of work might be used also for DVR which now support VLAN networks [3]. I have some concerns about the patch submitted in [1], so let's review! [3]https://review.openstack.org/#/c/129884/ On Wed, F

Re: [openstack-dev] [Manila]Questions about using not handle share-servers drivers with "Flat network"

Hi, Thanks very much for the reply. Really sorry for the late response. In your case if you have a driver that doesn't handle share servers, then the network is complete out of scope for Manila. Drivers that don't manage share servers have neither flat not segment networking in Manila, they hav

Re: [openstack-dev] [Neutron] XenAPI questions

Hi, The next meeting will be tomorrow @ 15:00 UTC - We'd love to see you there and we can talk about the CI and Terry's work. We're currently meeting fortnightly and skipped one due to travel, which is why there haven't been minutes recently. Thanks, Bob > -Original Message- > From:

Re: [openstack-dev] django-openstack-auth and stable/icehouse

> Bumping minimal oslo.config version due to the issue in > django-openstack-auth seems like a wrong way to do it. Dependencies in requirements.txt do not seem to be used in stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows: ... oslo.config==1.6.0 # git sha 99e530e django-ope

[openstack-dev] [Nova] log request-id mappings implementation

Hi All, I have submitted a patch in Nova [1] to log request-id mappings between cross projects which is a prerequisite for cinder-spec 'Return request ID to caller' [2] to be completed. This patch will extract cinder's request-id returned from cinder-client's response headers and will log it w

[openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

Heya, I noticed a ping (but couldn't respond in time) on #openstack-nova IRC about turning on logging in libvirt to capture Nova failures. This was discussed on this list previously by Daniel Berrange, just spelling it out here for reference and completness' sake. (1) To see the interactions be

Re: [openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

On Wed, Feb 04, 2015 at 11:23:34AM +0100, Kashyap Chamarthy wrote: > Heya, > > I noticed a ping (but couldn't respond in time) on #openstack-nova IRC > about turning on logging in libvirt to capture Nova failures. > > This was discussed on this list previously by Daniel Berrange, just > spelling

Re: [openstack-dev] [nova][ec2-api] Tagging functionality in nova's EC2 API

The conclusion seems fine ATM, like cleanup, fixing bugs, etc. But we should review the spec(s) for EC2 tags and if the spec design looks fine, then we can review the EC2 Tags patch. If the spec design itself is not feasible, then we should revisit the spec and blueprint. Thanks Swami On Tue, Feb

Re: [openstack-dev] [Neutron] XenAPI questions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/12/2014 07:43 AM, YAMAMOTO Takashi wrote: > hi, > > good to hear. do you have any estimate when it will be available? > will it cover dom0 side of the code found in > neutron/plugins/openvswitch/agent/xenapi? We also have rootwrap script just

Re: [openstack-dev] django-openstack-auth and stable/icehouse

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2015 11:20 AM, Alan Pevec wrote: >> Bumping minimal oslo.config version due to the issue in >> django-openstack-auth seems like a wrong way to do it. > > Dependencies in requirements.txt do not seem to be used in > stable/icehouse gate jobs

[openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

Hi, This is the follow-up of the discussion we started yesterday on rootwrap usage at the cross-project meeting. A bit of history to stage this story first. OpenStack nodes sometimes need to run things with elevated privileges. Nova started out as calling sudo shell commands to execute those, whi

Re: [openstack-dev] django-openstack-auth and stable/icehouse

>> Dependencies in requirements.txt do not seem to be used in >> stable/icehouse gate jobs, recent pip freeze in stable/icehouse >> shows: ... oslo.config==1.6.0 # git sha 99e530e >> django-openstack-auth==1.1.9 # git sha 2079383 > > It's because of this: > > 2015-01-27 19:33:44.152 | Collecting os

[openstack-dev] [sahara] team meeting Feb 5 1800 UTC

Hi folks, We'll be having the Sahara team meeting in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20150205T18 -- Sincerely yours, Sergey Lukjanov Sahara Te

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

4) Write a small daemon that runs as root, accepting commands over a unix domain socket or similar. Easier to audit, less code running as root. On 4 February 2015 at 12:58, Thierry Carrez wrote: > Hi, > > This is the follow-up of the discussion we started yesterday on rootwrap > usage at the cro

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

Miguel Ángel Ajo On Wednesday, 4 de February de 2015 at 10:41, Cory Benfield wrote: > On Wed, Feb 04, 2015 at 08:59:54, Kevin Benton wrote: > > I proposed an alternative to adjusting the lease time early on the in > > the thread. By specifying the renewal time (DHCP option 58), we can > > have

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote: > The first one is performance -- each call would spawn a Python > interpreter which would then call the system command. This was fine when > there were just a few calls here and there, not so much when it's called > a hundred times in

[openstack-dev] [Monasca][Monasca-agent] Logfile format to send matrices

Hello, In Monasca-agent README here It mentioned: "Retrieving metrics from log files written in a specific format. " Can anyone please point to such a format?Any such pointer would be good. If I understand it correctly, if I point the m

Re: [openstack-dev] django-openstack-auth and stable/icehouse

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2015 12:03 PM, Alan Pevec wrote: >>> Dependencies in requirements.txt do not seem to be used in >>> stable/icehouse gate jobs, recent pip freeze in >>> stable/icehouse shows: ... oslo.config==1.6.0 # git sha >>> 99e530e django-openstack-auth=

Re: [openstack-dev] [Neutron] XenAPI questions

hi, i added an item to the agenda. https://wiki.openstack.org/wiki/Meetings/XenAPI#Next_meeting YAMAMOTO Takashi > Hi, > > The next meeting will be tomorrow @ 15:00 UTC - We'd love to see you there > and we can talk about the CI and Terry's work. > > We're currently meeting fortnightly and sk

Re: [openstack-dev] [nova][ec2-api] Tagging functionality in nova's EC2 API

Thanks Alex for your detailed inspection of my work. Comments inline.. On 3 February 2015 at 21:32, Alexandre Levine wrote: > I'm writing this in regard to several reviews concering tagging > functionality for EC2 API in nova. > The list of the reviews concerned is here: > > https://review.open

[openstack-dev] [horizon] JavaScript docs?

In python we have a style to document methods, classes, and so forth. But, I don't see any guidance on how JavaScript should be documented. I was looking for something like jsdoc or ngdoc (an extension of jsdoc). Is there any guidance on how JavaScript should be documented? For anyone who doesn't

Re: [openstack-dev] [tc] do we really need project tags in the governance repository?

On Tue, Feb 3, 2015 at 8:04 PM, Joe Gordon wrote: > > > On Tue, Jan 27, 2015 at 10:15 AM, Clint Byrum wrote: > >> Excerpts from Thierry Carrez's message of 2015-01-27 02:46:03 -0800: >> > Doug Hellmann wrote: >> > > On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote: >> > > [...] >> > >> I'

Re: [openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

On Wed, Feb 04, 2015 at 10:27:34AM +, Daniel P. Berrange wrote: > On Wed, Feb 04, 2015 at 11:23:34AM +0100, Kashyap Chamarthy wrote: > > Heya, > > > > I noticed a ping (but couldn't respond in time) on #openstack-nova IRC > > about turning on logging in libvirt to capture Nova failures. > > >

Re: [openstack-dev] [nova][ec2-api] Tagging functionality in nova's EC2 API

Rushi, Thank you for the response. I totally understand the effort and your problems with getting it through at the time. Your design is completely inline with what's currently present in Nova for EC2, no doubt about that. I did whatever I could to review your patches and consider if it's wor

Re: [openstack-dev] [api] API Definition Formats

On Mon, 2 Feb 2015, Chris Dent wrote: On Thu, 29 Jan 2015, michael mccune wrote: in a similar vein, i started to work on marking up the sahara and barbican code bases to produce swagger. for sahara this was a little easier as flask makes it simple to query the paths. for barbican i started a

Re: [openstack-dev] [oslo.messaging][zmq] Redundant zmq.Context creation

Any news here? Per-socket solution is a conservative solution that makes zeromq driver work for multiple-workers. Neutron-server has api-worker and rpc-worker. I'm not sure per-driver is applicable. I will try to figure it out soon. On Fri, Jan 23, 2015 at 7:53 PM, Oleksii Zamiatin wrote: > 23.01

[openstack-dev] No dvr meeting this week.

Hi folks, No dvr meeting today. Thanks Swami __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On 02/04/2015 06:57 AM, Daniel P. Berrange wrote: > On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote: >> The first one is performance -- each call would spawn a Python >> interpreter which would then call the system command. This was fine when >> there were just a few calls here and t

[openstack-dev] [nova] stuck patches at the nova IRC meeting

As there has been a bunch of concern around patches getting lost or stuck, I wanted to re-announce the fact that we've got a dedicated slot at the weekly Nova meeting for just those sorts of things. https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting The "Stuck reviews" time blo

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

I suppose that the security argument against running the whole of nova-compute as root is that a remote exploit in the service is much better constrained when the thing isn't running as root - e.g. some input validation fails and allows arbitrary shell in some (currently none-root) command via an e

Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch

Hi, I also think, that after release we should run restrospective and actually analyse how much reality differs from the spec. This will help us improve planning in the future. > On 03 Feb 2015, at 22:15, Andrey Danin wrote: > > I totally agree with Andrew. > > On Tuesday, February 3, 2015

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

Monty Taylor wrote: >> On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote: >>> (2) bite the bullet and accept that some types of nodes actually need >>> root rights for so many different things, they should just run as root >>> anyway. I know a few distributions which won't be very plea

Re: [openstack-dev] ZeroMQ topic object.

Sorry for the late reply. Your proposal is interesting. According to the previous discussion of works on zeromq driver, we should first make zeromq driver completed for all the OpenStack projects and CI. During these days, lots of patches are submitted to upstream. But some critical ones are still

Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py

Bump. Also, added to CC Alex Xu and Chris Yeoh. Cheers! Claudiu Belu From: Claudiu Belu [[email protected]] Sent: Tuesday, February 03, 2015 12:51 AM To: [email protected] Subject: [openstack-dev] [nova][api] How to handle API changes i

Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch

>> The spec doesn't have to be perfect, but it needs to be merged prior to code describing it. Currently the spec has to be perfect and detailed enough, otherwise you will have to merge the spec with -1 from reviewers, also if you postpone the details, you won't be able to track, if these details

Re: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance benchmarking

At Rackspace we have been working on automated testing with Ansible and Tsung, but I don’t know if that code ever made it to a public repository… We found Tsung to be very useful for parallel testing though! :) --Adam https://keybase.io/rm_you From: Varun Lodaya mailto:[email protected]

Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py

I have failed to add Chris Yeoh. Hope it's fine now.. From: Claudiu Belu [[email protected]] Sent: Wednesday, February 04, 2015 5:10 PM To: OpenStack Development Mailing List (not for usage questions) Cc: [email protected] Subject: Re: [openstack-

Re: [openstack-dev] ZeroMQ topic object.

Hi, This week I've tried to install devstack with zmq. So small status update: The main problem is that Neutron fails with "redis connection refused". Maybe [1] and [2] will fix this. Smaller ones (I've managed them locally): [6] No redis, pyzmq in requirements.txt - https://bugs.launchpad.

[openstack-dev] Request for OpenStack Discussion Mailinglist in Chinese

I have submitted a patch to create a mailinglist for discussions in Chinese. Could infra and other folks please review it? https://review.openstack.org/#/c/152947/ Thanks! __ OpenStack Development Mailing List (not for usag

Re: [openstack-dev] [tc] do we really need project tags in the governance repository?

On 2015-02-03 22:12:09 -0500 (-0500), Jay Pipes wrote: > On 01/27/2015 01:15 PM, Clint Byrum wrote: [...] > > I agree with your statement that summary reference metadata is > > useful. I agree with Doug that it is inappropriate for the TC to > > assign it. [...] > Originally, I proposed that the ta

Re: [openstack-dev] [cinder][nova] Cinder Brick pypi library?

On 2015-02-03 21:41:02 -0800 (-0800), Walter A. Boring IV wrote: [...] > So the question I have is, does Nova have an interest in using the > code in a pypi brick library? [...] It'll probably need a different/more specific name since "brick" is already taken on PyPI: https://pypi.python.org/pypi/

Re: [openstack-dev] django-openstack-auth and stable/icehouse

On 2015-02-04 12:03:14 +0100 (+0100), Alan Pevec wrote: [...] > > > oslo.config==1.6.0 # git sha 99e530e > > > django-openstack-auth==1.1.9 # git sha 2079383 [...] > Clients are capped in stable/icehouse requirements but devstack in > gate seems to be installing them from git master (note # git sha

[openstack-dev] [Trove] No weekly Trove IRC meeting this week

Hello folks: Since we are having the Trove Mid-Cycle meetup this week (Feb 3-5), there will be no weekly Trove IRC meeting on Feb 4. We'll resume our weekly IRC meeting next week, on Feb 11th. Thanks, Nikhil __ OpenStack Dev

Re: [openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

Daniel, Kashyap, One question that came up on IRC was, how/where to configure say a directory where core dumps from qemu would end up. Sean was seeing a scenario where he noticed a core dump from qemu in dmesg/syslog and was wondering how to specify a directory to capture a core dump if/when it oc

Re: [openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

On Wed, Feb 04, 2015 at 11:15:18AM -0500, Davanum Srinivas wrote: > Daniel, Kashyap, > > One question that came up on IRC was, how/where to configure say a > directory where core dumps from qemu would end up. Sean was seeing a > scenario where he noticed a core dump from qemu in dmesg/syslog and >

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

Ideally there would need to be a way to replicate errors.openstack.org and switch the url, for none-internet connected deployments, but TBH sites with that sort of requirement are used to weird breakages, so not a huge issue of it can't easily be done On 3 February 2015 at 00:35, Jay Pipes wrote:

[openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

I've spent a few hours today reading about Galera, a clustering solution for MySQL. Galera provides multi-master 'virtually synchronous' replication between multiple mysql nodes. i.e. I can create a cluster of 3 mysql dbs and read and write from any of them with certain consistency guarantees. I a

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

The downside of numbers rather than camel-case text is that they are less likely to stick in the memory of regular users. Not a huge think, but a reduction in usability, I think. On the other hand they might lead to less guessing about the error with insufficient info, I suppose. To make the globa

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On 2015-02-04 13:40:29 +0200 (+0200), Duncan Thomas wrote: > 4) Write a small daemon that runs as root, accepting commands over > a unix domain socket or similar. Easier to audit, less code > running as root. http://git.openstack.org/cgit/openstack/oslo.rootwrap/tree/oslo_rootwrap/daemon.py -- J

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

If I'm reading that correctly, it does not help with the filtering issues at all, since it needs exactly the same kind of filter. Daniel explained the concept far better than I. On 4 February 2015 at 18:33, Jeremy Stanley wrote: > On 2015-02-04 13:40:29 +0200 (+0200), Duncan Thomas wrote: > > 4)

[openstack-dev] [stable][neutron] 2014.2.2 exceptions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'd like to ask grant for exception for the following patches: - - https://review.openstack.org/#/c/149818/ (FIPs are messed up and/or not working after L3 HA failover; makes L3 HA feature unusable) - - https://review.openstack.org/152841 (i

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On 2015-02-04 11:58:03 +0100 (+0100), Thierry Carrez wrote: [...] > The second problem is the quality of the filter definitions. Rootwrap is > a framework to enable isolation. It's only as good as the filters each > project defines. Most of them rely on CommandFilters that do not check > any argume

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On Wed, Feb 04, 2015 at 06:38:16PM +0200, Duncan Thomas wrote: > If I'm reading that correctly, it does not help with the filtering issues > at all, since it needs exactly the same kind of filter. Daniel explained > the concept far better than I. Yep, the only thing rootwrap daemon mode does is to

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On 2015-02-04 18:38:16 +0200 (+0200), Duncan Thomas wrote: > If I'm reading that correctly, it does not help with the filtering issues at > all, since it needs exactly the same kind of filter. Daniel explained the > concept far better than I. I didn't mean to imply that it does, merely that it fit

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

Here are my 2¢. > > >> (1) we could get our act together and audit and fix those filter > > >> definitions. Remove superfluous usage of root rights, make use of > > >> advanced filters for where we actually need them. We have been preaching > > >> for that at many many design summits. This is a lo

Re: [openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

Daniel, The last tip on this page possibly? http://wiki.stoney-cloud.org/wiki/Debugging_Qemu -- dims On Wed, Feb 4, 2015 at 11:18 AM, Daniel P. Berrange wrote: > On Wed, Feb 04, 2015 at 11:15:18AM -0500, Davanum Srinivas wrote: >> Daniel, Kashyap, >> >> One question that came up on IRC was, how

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On Wed, Feb 04, 2015 at 05:52:12PM +0100, Philipp Marek wrote: > Here are my 2¢. > > > > >> (1) we could get our act together and audit and fix those filter > > > >> definitions. Remove superfluous usage of root rights, make use of > > > >> advanced filters for where we actually need them. We have

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On 02/04/2015 06:57 AM, Daniel P. Berrange wrote: > On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote: >> What solutions do we have ? >> >> (1) we could get our act together and audit and fix those filter >> definitions. Remove superfluous usage of root rights, make use of >> advanced

Re: [openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

On Wed, Feb 04, 2015 at 11:57:56AM -0500, Davanum Srinivas wrote: > Daniel, > > The last tip on this page possibly? > http://wiki.stoney-cloud.org/wiki/Debugging_Qemu Note that "tip" is not merely affecting QEMU processes - the recommended change is affecting core dumps for everything on the enti

Re: [openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

Aha, thanks Daniel. On Wed, Feb 4, 2015 at 12:01 PM, Daniel P. Berrange wrote: > On Wed, Feb 04, 2015 at 11:57:56AM -0500, Davanum Srinivas wrote: >> Daniel, >> >> The last tip on this page possibly? >> http://wiki.stoney-cloud.org/wiki/Debugging_Qemu > > Note that "tip" is not merely affecting Q

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote: > I've spent a few hours today reading about Galera, a clustering solution > for MySQL. Galera provides multi-master 'virtually synchronous' > replication between multiple mysql nodes. i.e. I can create a cluster of > 3 mysql dbs and re

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

Thierry Carrez writes: > You make a good point when you mention "traditional distro" here. I > would argue that containers are slightly changing the rules of the > don't-run-as-root game. > > Solution (2) aligns pretty well with container-powered OpenStack > deployments -- running compute nodes a

Re: [openstack-dev] [horizon] JavaScript docs?

As we're moving toward Angular, might make sense for us to adopt ngdoc as well.-Matthew Farina wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: Matthew Farina Date: 02/04/2015 05:42AMSubject: [openstack-dev] [horizon] _javascript_ docs?In python we have a st

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

> > > (4) I think that ultimately we need to ditch rootwrap and provide a proper > > > privilege separated, formal RPC mechanism for each project. > > ... > > > we should have a nova-compute-worker daemon running as root, that accepts > > > an RPC command from nova-compute running unprivileged. eg

[openstack-dev] [oslo][nova][cinder] removing request_utils from oslo-incubator

About 12 hours ago in #openstack-oslo ankit_ag asked about the request_utils module that was removed from oslo-incubator and how to proceed to get it into nova. The module was deleted a few days ago [1] because nothing was actually using it and it appeared to be related to a nova blueprint [2],

Re: [openstack-dev] [stable][neutron] 2014.2.2 exceptions

On Wed, Feb 4, 2015 at 10:43 AM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > I'd like to ask grant for exception for the following patches: > > - - https://review.openstack.org/#/c/149818/ (FIPs are messed up and/or > not working after L3 HA failover;

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On Wed, Feb 04, 2015 at 06:05:16PM +0100, Philipp Marek wrote: > > > > (4) I think that ultimately we need to ditch rootwrap and provide a > > > > proper > > > > privilege separated, formal RPC mechanism for each project. > > > ... > > > > we should have a nova-compute-worker daemon running as ro

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On Wed, Feb 04, 2015 at 09:10:06AM -0800, James E. Blair wrote: > Thierry Carrez writes: > > > You make a good point when you mention "traditional distro" here. I > > would argue that containers are slightly changing the rules of the > > don't-run-as-root game. > > > > Solution (2) aligns pretty

Re: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance benchmarking

Thanks Baptiste. I will try that tool. I worked with ab and was seeing really low results. But let me give httpress a shot :) Thanks, Varun On 2/3/15, 7:01 PM, "Baptiste" wrote: >On Wed, Feb 4, 2015 at 1:58 AM, Varun Lodaya >wrote: >> Hi, >> >> We were trying to use haproxy as our LBaaS soluti

Re: [openstack-dev] [stable][neutron] 2014.2.2 exceptions

Ihar Hrachyshka wrote: > I'd like to ask grant for exception for the following patches: > > - https://review.openstack.org/#/c/149818/ (FIPs are messed up and/or > not working after L3 HA failover; makes L3 HA feature unusable) > > - https://review.openstack.org/152841 (ipv6: router does not adve

Re: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance benchmarking

Thanks Miguel. From: Miguel Ángel Ajo mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]>> Date: Wednesday, February 4, 2015 at 1:10 AM To: "OpenStack Development Mailing List (not for usage questions)" m

Re: [openstack-dev] [Manila]Question about the usage of "connect_share_server_to_tenant_network"

On 02/04/2015 03:04 AM, Li, Chen wrote: Hi list, For generic driver, there is a flag named “connect_share_server_to_tenant_network” in manila/share/drivers/service_instance.py. When it set to True, share-server(nova instance) would be created directly on the “share-network”. When it set

[openstack-dev] Report on virtual sprinting

Hi everyone, This cycle, the OpenStack Infrastructure team forewent having an in-person midcycle sprint and has instead taken advantage of the new #openstack-sprint channel for specific sprint topics we wished to cover. So far there have been 3 such virtual sprints. Two were completed by the Infr

Re: [openstack-dev] [horizon] JavaScript docs?

I agree. StoryBoard's storyboard-webclient project has a lot of existing code already that's pretty well documented, but without knowing what documentation system we were going to settle on we never put any rule enforcement in place. If someone wants to take a stab at putting together a javascript

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

Excerpts from Tristan Cacqueray's message of 2015-02-04 09:02:19 -0800: > On 02/04/2015 06:57 AM, Daniel P. Berrange wrote: > > On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote: > >> What solutions do we have ? > >> > >> (1) we could get our act together and audit and fix those filter

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

Excerpts from Daniel P. Berrange's message of 2015-02-04 03:57:53 -0800: > On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote: > > The first one is performance -- each call would spawn a Python > > interpreter which would then call the system command. This was fine when > > there were j

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

Thanks Doug. My apologies for the delayed reply. The change is merged, so replying here. It is a welcome change in one way, there is always a root entity now in perspective while creating any entity. Listener is created with loadbalancer and pool is created with listener. The problem itself is

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

Matthew Booth wrote: > A: start transaction; > B: start transaction; > A: insert into foo values(1); > B: insert into foo values(1); <-- 'regular' DB would block here, and > report an error on A's commit > A: commit; <-- success > B: commit; <-- KABOOM > > Conf

[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday 4th February 2015 @ 2200 UTC in #openstack-meeting

Hi all, Just a quick (belated) reminder that there is an OpenStack Telco Working group meeting in #openstack-meeting today @ 2200 UTC. I'm currently updating the agenda, please review and add any items here: https://etherpad.openstack.org/p/nfv-meeting-agenda Thanks, Steve __

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

Matthew Booth wrote: > This means that even for 'synchronous' slaves, if a client makes an RPC > call which writes a row to write master A, then another RPC call which > expects to read that row from synchronous slave node B, there's no > default guarantee that it'll be there. Can I get some

Re: [openstack-dev] [QA] Prototype of the script for Tempest auto-configuration

On 01/26/2015 09:39 AM, Timur Nurlygayanov wrote: Hi, Sorry for the late reply. Was on vacation. *Yaroslav*,thank you for raising the question, I realy like this feature, I discussed this script with several people during the OpenStack summit in Paris and heard many the same things - we need

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

On 02/04/2015 12:05 PM, Sahid Orentino Ferdjaoui wrote: On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote: I've spent a few hours today reading about Galera, a clustering solution for MySQL. Galera provides multi-master 'virtually synchronous' replication between multiple mysql nodes

Re: [openstack-dev] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova

On Wed, Feb 04, 2015 at 11:15:18AM -0500, Davanum Srinivas wrote: > Daniel, Kashyap, > > One question that came up on IRC was, how/where to configure say a > directory where core dumps from qemu would end up. Sean was seeing a > scenario where he noticed a core dump from qemu in dmesg/syslog If

Re: [openstack-dev] [cinder][nova] Cinder Brick pypi library?

On Tue, Feb 3, 2015 at 9:41 PM, Walter A. Boring IV wrote: > Hey folks, >I wanted to get some feedback from the Nova folks on using Cinder's > Brick library. As some of you > may or may not know, Cinder has an internal module called Brick. It's used > for discovering and removing > volumes a

[openstack-dev] [QA] Meeting Thursday February 5th at 22:00 UTC

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, February 5th at 22:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item t

[openstack-dev] [horizon][keystone]

Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects d

Re: [openstack-dev] [horizon] JavaScript docs?

On 02/04/2015 12:48 PM, Michael Krotscheck wrote: > I agree. StoryBoard's storyboard-webclient project has a lot of existing > code already that's pretty well documented, but without knowing what > documentation system we were going to settle on we never put any rule > enforcement in place. If some

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

Matthew Booth wrote: > A: start transaction; > A: insert into foo values(1) > A: commit; > B: select * from foo; <-- May not contain the value we inserted above[3] I’ve confirmed in my own testing that this is accurate. the wsrep_causal_reads flag does resolve this, and it is settable on a per

Re: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance benchmarking

Well, low results on ab or on haproxy??? Can you define "low" ? you should test your server without any openstack stuff on it, then apply the same test with openstack installation. There may be some negative impacts because of software installed by neutron (mainly iptables). Baptiste On Wed, Fe

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

How interesting, Why are people using galera if it behaves like this? :-/ Are the people that are using it know/aware that this happens? :-/ Scary Mike Bayer wrote: Matthew Booth wrote: A: start transaction; A: insert into foo values(1) A: commit; B: select * from foo;<-- May not cont

Re: [openstack-dev] [oslo][nova][cinder] removing request_utils from oslo-incubator

Doug, So the ball is in the Nova core(s) court? -- dims On Wed, Feb 4, 2015 at 12:16 PM, Doug Hellmann wrote: > About 12 hours ago in #openstack-oslo ankit_ag asked about the request_utils > module that was removed from oslo-incubator and how to proceed to get it into > nova. > > The module w

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

Excerpts from Matthew Booth's message of 2015-02-04 08:30:32 -0800: > * Write followed by read on a different node can return stale data > > During a commit, Galera replicates a transaction out to all other db > nodes. Due to its design, Galera knows these transactions will be > successfully commi

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

On 5 February 2015 at 10:24, Joshua Harlow wrote: > How interesting, > > Why are people using galera if it behaves like this? :-/ Because its actually fairly normal. In fact its an instance of point 7 on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our oldest wiki pages :). In more

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

Excerpts from Joshua Harlow's message of 2015-02-04 13:24:20 -0800: > How interesting, > > Why are people using galera if it behaves like this? :-/ > Note that any true MVCC database will roll back transactions on conflicts. One must always have a deadlock detection algorithm of some kind. Gale

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

On 5 February 2015 at 03:33, Monty Taylor wrote: > On 02/04/2015 06:57 AM, Daniel P. Berrange wrote: > to manage VMs on a laptop - you're going to use virtualbox or > virt-manager. You're going to use nova-compute to manage compute hosts > in a cloud - and in almost all circumstances the only

Re: [openstack-dev] [oslo][nova][cinder] removing request_utils from oslo-incubator

I was primarily trying to explain what happened for ankit_ag, since we don't seem to overlap on IRC. If someone cares about the feature, they should get the cross-project spec going because I don't think this is something only nova cores should be deciding. On Wed, Feb 4, 2015, at 04:34 PM, Davan

  1   2   >