Re: [openstack-dev] [Swift]After the X-Container-Read how to get the list of readable container
On Thu, Jul 4, 2013 at 2:43 AM, Hajime Takase tak...@axlbit.net wrote: I have successfully figure out to grant read only permission or write permission to non operator users(operator is defined in /etc/swift/proxy.conf) but I found out that those users can't get the account info of the tenant using get_account() or GET,or they won't know the list of the readable or writable containers. This is not supported at this time, David Hadas is working on account ACL : https://blueprints.launchpad.net/swift/+spec/account-acls which I believe should solve that particular problem. Chmouel I was thinking to store those additional data in local databases,but since I want to use PC client as well,I would rather prefer using the server side command to get the list of readable or writable containers.Is there any way to do this using the API? Hajime ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] volume affinity filter for nova scheduler
On Wed 03 Jul 2013 (18:24), Alexey Ovchinnikov wrote: Hi everyone, Hi Alexey. for some time I have been working on an implementation of a filter that would allow to force instances to hosts which contain specific volumes. A blueprint can be found here: https://blueprints.launchpad.net/nova/+spec/volume-affinity-filter and an implementation here: https://review.openstack.org/#/c/29343/ This is something we were eager to see and that we were also aiming to implement in the future, so, great job! The filter works for LVM driver and now it picks either a host containing specified volume or nothing (thus effectively failing instance scheduling). Now it fails primarily when it can't find the volume. It has been pointed to me that sometimes it may be desirable not to fail instance scheduling but to run it anyway. However this softer behaviour fits better for weighter function. Thus I have registered a blueprint for the weighter function: https://blueprints.launchpad.net/nova/+spec/volume-affinity-weighter-function I was thinking about both the filter and the weighter working together. The former could be used in cases when we strongly need storage space associated with an instance and need them placed on the same host. The latter could be used when storage space is nice to have and preferably on the same host with an instance, but not so crucial as to have the instance running. During reviewing a question appeared whether we need the filter and wouldn't things be better if we removed it and had only the weighter function instead. I am not yet convinced that the filter is useless and needs to be replaced with the weighter, so I am asking for your opinion on this matter. Do you see usecases for the filter, or the weighter will answer all needs? I'd go with the weigher. We have some use cases for this volume affinity, but they always require to access to their data rather than failing. Moreover, the filter implies that the user has some knowledge on the infrastructure (i.e. that volumes and instances can be coallocated) and it is only available for LVM drivers, whereas the weigher should work transparently in all situations. Cheers, -- Álvaro López García al...@ifca.unican.es Instituto de Física de Cantabria http://alvarolopez.github.io Ed. Juan Jordá, Campus UC tel: (+34) 942 200 969 Avda. de los Castros s/n 39005 Santander (SPAIN) _ If you haven't used grep, you've missed one of the simple pleasures of life. -- Brian Kernighan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS
Hi folks, While working on agent scheduling for LBaaS reference implementation ( https://review.openstack.org/#/c/32137/) I thought that it would be useful to unify existing agent to make it suite any vendor who wants to use async mechanism and agent scheduling. I filed a blueprint on this - https://blueprints.launchpad.net/neutron/+spec/lbaas-common-agent-driver So what do you guys think? Wishes/suggestions are welcome. Thanks, Oleg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS
I think the design should be documented on the wiki. Major part of such agent should be corresponding RPC API which then is shared between services. That needs to be thought out and discussed. Thanks, Eugene. On Thu, Jul 4, 2013 at 12:27 PM, Oleg Bondarev obonda...@mirantis.comwrote: Hi folks, While working on agent scheduling for LBaaS reference implementation ( https://review.openstack.org/#/c/32137/) I thought that it would be useful to unify existing agent to make it suite any vendor who wants to use async mechanism and agent scheduling. I filed a blueprint on this - https://blueprints.launchpad.net/neutron/+spec/lbaas-common-agent-driver So what do you guys think? Wishes/suggestions are welcome. Thanks, Oleg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS
Hi Eugene, ...RPC API which then is shared between services. Did you mean device drivers rather than services? Thanks, Oleg On Thu, Jul 4, 2013 at 12:42 PM, Eugene Nikanorov enikano...@mirantis.comwrote: I think the design should be documented on the wiki. Major part of such agent should be corresponding RPC API which then is shared between services. That needs to be thought out and discussed. Thanks, Eugene. On Thu, Jul 4, 2013 at 12:27 PM, Oleg Bondarev obonda...@mirantis.comwrote: Hi folks, While working on agent scheduling for LBaaS reference implementation ( https://review.openstack.org/#/c/32137/) I thought that it would be useful to unify existing agent to make it suite any vendor who wants to use async mechanism and agent scheduling. I filed a blueprint on this - https://blueprints.launchpad.net/neutron/+spec/lbaas-common-agent-driver So what do you guys think? Wishes/suggestions are welcome. Thanks, Oleg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] too many tokens
Thanks Matt for the pointers. I was already aware of this cache mechanism. However my approach is different: I do not want to cache clients, but simply update the context with the token that was obtained. And if the same context is reused, no new token will be generated. Ala 2013/7/3 Matt Riedemann mrie...@us.ibm.com For some history, there was an attempt at consolidating some of this here: * https://github.com/openstack/nova/commit/dd9c27f999221001bae9faa03571645824d2a681 *https://github.com/openstack/nova/commit/dd9c27f999221001bae9faa03571645824d2a681 But that caused some issues and was reverted here: https://github.com/openstack/nova/commit/ee5d9ae8d376e41e852b06488e922400cf69b4ac Thanks, *MATT RIEDEMANN* Advisory Software Engineer Cloud Solutions and OpenStack Development -- *Phone:* 1-507-253-7622 | *Mobile:* 1-507-990-1889* E-mail:* *mrie...@us.ibm.com* mrie...@us.ibm.com [image: IBM] 3605 Hwy 52 N Rochester, MN 55901-1407 United States From:Ala Rezmerita ala.rezmer...@cloudwatt.com To:OpenStack Development Mailing List openstack-dev@lists.openstack.org, Cc:gong...@unitedstack.com, hrushikesh.gan...@hp.com Date:07/03/2013 11:26 AM Subject:[openstack-dev] [Nova] too many tokens -- Hi everyone, I have a question regarding too many token generation in nova when using quantumclient (also related to bug reports * https://bugs.launchpad.net/nova/+bug/1192383*https://bugs.launchpad.net/nova/+bug/1192383+ *https://bugs.launchpad.net/nova-project/+bug/1191159*https://bugs.launchpad.net/nova-project/+bug/1191159) For instance during the periodic task *heal_instance_info_cache* (every 60s) nova calls quantum API method get_instance_nw_info that calls _build_network_info_model (backtrace at the end of the mail). During the execution of this method, 4 quantum clients intances are created (all of them use the same context object) and for each of them a new token is generated. Is it possible to change this behavior by updating the context.auth_token property the first time a quantumclient for a given context is created (so that the same token will be reused among the 4 client instances) ? Is there some security issue that can appear? Thanks Ala Rezmerita Cloudwatt The backtrace : /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py(194)main() - result = function(*args, **kwargs) /opt/stack/nova/nova/openstack/common/loopingcall.py(125)_inner() - idle = self.f(*self.args, ***self.kw* http://self.kw/ ) /opt/stack/nova/nova/service.py(283)periodic_tasks() - return self.manager.periodic_tasks(ctxt, raise_on_error=raise_on_error) /opt/stack/nova/nova/manager.py(100)periodic_tasks() - return self.run_periodic_tasks(context, raise_on_error=raise_on_error) /opt/stack/nova/nova/openstack/common/periodic_task.py(179)run_periodic_tasks() - task(self, context) /opt/stack/nova/nova/compute/manager.py(3654)_heal_instance_info_cache() - self._get_instance_nw_info(context, instance) /opt/stack/nova/nova/compute/manager.py(767)_get_instance_nw_info() - instance, conductor_api=self.conductor_api) /opt/stack/nova/nova/network/quantumv2/api.py(367)get_instance_nw_info() - result = self._get_instance_nw_info(context, instance, networks) /opt/stack/nova/nova/network/quantumv2/api.py(375)_get_instance_nw_info() - nw_info = self._build_network_info_model(context, instance, networks) /opt/stack/nova/nova/network/quantumv2/api.py(840)_build_network_info_model() - client = quantumv2.get_client(context, admin=True) /opt/stack/nova/nova/network/quantumv2/__init__.py(67)get_client() ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ala Rezmerita Software Engineer CloudWatt Tel : (+33) 06 77 43 23 91 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal for including fake implementations in python-client packages
On Wed, Jul 3, 2013 at 6:19 PM, Christopher Armstrong chris.armstr...@rackspace.com wrote: On Tue, Jul 2, 2013 at 11:38 PM, Robert Collins robe...@robertcollins.net wrote: Radix points out I missed the naunce that you're targeting the users of python-novaclient, for instance, rather than python-novaclient's own tests. On 3 July 2013 16:29, Robert Collins robe...@robertcollins.net wrote: What I'd like is for each client library, in addition to the actual implementation, is that they ship a fake, in-memory, version of the API. The fake implementations should take the same arguments, have the same return values, raise the same exceptions, and otherwise be identical, besides the fact that they are entirely in memory and never make network requests. So, +1 on shipping a fake reference copy of the API. -1 on shipping it in the client. The server that defines the API should have two implementations - the production one, and a testing fake. The server tests should exercise *both* code paths [e.g. using testscenarios] to ensure there is no skew between them. Then the client tests can be fast and efficient but not subject to implementation skew between fake and prod implementations. Back on Launchpad I designed a similar thing, but with language neutrality as a goal : https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements#Test_fake And in fact, I think that that design would work well here, because we have multiple language bindings - Python, Ruby, PHP, Java, Go etc, and all of them will benefit from a low(ms or less)-latency test fake. So taking the aspect I missed into account I'm much happier with the idea of shipping a fake in the client, but... AFAICT many of our client behaviours are only well defined in the presence of a server anyhow. So it seems to me that a fast server fake can be used in tests of python-novaclient, *and* in tests of code using python-novaclient (including for instance, heat itself), and we get to write it just once per server, rather than once per server per language binding. -Rob I want to make sure I understond you. Let's say I have a program named cool-cloud-tool, and it uses python-novaclient, python-keystoneclient, and three other clients for OpenStack services. You're suggesting that its test suite should start up instances of all those OpenStack services with in-memory or otherwise localized backends, and communicate with them using standard python-*client functionality? I can imagine that being a useful thing, if it's very easy to do, and won't increase my test execution time too much. The easiest way to do this would be to set up a devstack instance to run your tests against, but that would increase test execution time by at least a few minutes. So although something like this would not work well for unit tests it could be useful for integration tests. Also I do not know of anyone using this for this type of testing yet, but someone always has to be first. -- IRC: radix Christopher Armstrong Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
Hi, Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Changing pollster/pipeline parameters
Hi Phil,
Some more thoughts inline ...
A couple of related questions on managing CM pollster behavior via config
type files:
1. I'm trying to make some modifications to the timing of the Glance
(image)
polling in a default CM install. It looks like the pipeline interval fields
are the way to do it, and that I should tweak it using a yaml config file,
but I can't seem to verify based on a read-through of the code. Can anyone
confirm?
Yep, the configured interval in the /etc/ceilometer/pipeline.yaml is the way
to go.
For example:
$ sed -i 's/interval: .*$/interval: 10/' /etc/ceilometer/pipeline.yaml
$ # restart ceilometer-agent-central
$ ceilometer sample-list -m image.size | tail -5
| df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B
| | 2013-07-03T21:40:15|
| df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B
| | 2013-07-03T21:40:25|
| df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B
| | 2013-07-03T21:40:35|
| df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B
| | 2013-07-03T21:40:45|
+--++---++--++
As you see the meter is now being collected at a 10s cadence.
This timing is pulled in via the AgentManager base class:
https://github.com/openstack/ceilometer/blob/master/ceilometer/agent.py#L90
I should have been more explicit here, in the sense of pointing out that:
(a) this pipeline config can be made specific to the central agent
(i.e. the agent responsible for polling glance among other things)
by adding the line:
pipeline_cfg_file = pipeline-central.yaml
to the ceilometer.conf picked up by the central agent (so that the
central agent pipeline is independent of the pipeline used by the
other agents)
(b) multiple pipelines can be defined in a single yaml file, with different
polling intervals for different groups of meters.
For example, to make only the glance polling interval 120s while keeping
the other central agent polling cycles at 60s, use something like the
following in the appropriate pipeline.yaml file:
---
-
name: meter_pipeline
interval: 60
counters:
- *
- !image
- !image.size
transformers:
publishers:
- rpc://
-
name: image_pipeline
interval: 120
counters:
- image
- image.size
transformers:
publishers:
- rpc://
2. Similarly, it looks like disabling pollsters is done via the oslo.cfg
logic in the agent manager. I'd like to populate that using a config
fileis there logic already to do that that I haven't come across yet?
Well the way I'd disable a pollster is simply by configuring the counters
exclusion in the pipeline.yaml.
For example to disable the pollster providing the image.size meter referred
to above, the following will do the trick:
counters:
- *
- !image.size
i.e. allow everything but the image.size meter.
Confirm as before using:
$ # restart ceilometer-agent-central
$ ceilometer sample-list -m image.size | tail -5
It also occurred to me that you may have been thinking of the now-obsolete
disabled_{central|compute|...}_pollsters config options, which are no longer
supported as they've been superceeded by the newer pipeline config.
Hope this helps clarify things for you.
Cheers,
Eoghan
Cheers,
Eoghan
- Phil
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
Hi Thomas, Thomas Goirand z...@debian.org wrote: Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Why is Selenium considered non-free? The code is Apache-licensed, including the Python bindings. FWIW only a few of the unit tests use Selenium (and those that do, need to), and they're not run by default unless you set a flag to do so. Julie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 04/07/13 11:27, Thomas Goirand wrote: Hi, Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Thank you for the heads-up. Selenium is used for tests during development, it is not a runtime requirement at all. Would that still make it non-free for Debian? How did Horizon went into Debian packages at all, since the situation in this front is unchanged for at least a year (just curious). Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On Thu, Jul 04 2013, Julie Pichon wrote: Thomas Goirand z...@debian.org wrote: Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Why is Selenium considered non-free? The code is Apache-licensed, including the Python bindings. FWIW only a few of the unit tests use Selenium (and those that do, need to), and they're not run by default unless you set a flag to do so. Yes, that seems like a mistake from the Debian packager as far as I can tell. There's nothing that requires it to be in non-free. (Cc'ing Sascha, the maintainer) -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Metrics][Nova] Using Bicho database to get stats about code review
On 07/03/2013 06:14 PM, Jesus M. Gonzalez-Barahona wrote: Bicho [1] now has a Gerrit backend, which has been tested with OpenStack's Gerrit. We have used it to produce the MySQL database dump available at [2] ( gerrit.mysql.7z ). You can use it to compute the metrics mentioned in the previous threads about code review, and some others. [1] https://github.com/MetricsGrimoire/Bicho [2] http://activity.openstack.org/dash/browser/data/db/ Nice job, Jesus, thank you. /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 07/04/2013 02:34 PM, Sascha Peilicke wrote: On 07/04/2013 12:03 PM, Matthias Runge wrote: On 04/07/13 11:27, Thomas Goirand wrote: Hi, Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Thank you for the heads-up. Selenium is used for tests during development, it is not a runtime requirement at all. Would that still make it non-free for Debian? BTW. this is identical for openSUSE. How did Horizon went into Debian packages at all, since the situation in this front is unchanged for at least a year (just curious). At least here, our horizon test package just doesn't depend on selenium. This could help: https://review.openstack.org/#/c/35649/ -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
Hi Sascha, Sascha Peilicke speili...@suse.com wrote: On 07/04/2013 02:34 PM, Sascha Peilicke wrote: On 07/04/2013 12:03 PM, Matthias Runge wrote: On 04/07/13 11:27, Thomas Goirand wrote: Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Thank you for the heads-up. Selenium is used for tests during development, it is not a runtime requirement at all. Would that still make it non-free for Debian? BTW. this is identical for openSUSE. How did Horizon went into Debian packages at all, since the situation in this front is unchanged for at least a year (just curious). At least here, our horizon test package just doesn't depend on selenium. This could help: https://review.openstack.org/#/c/35649/ Could you explain why Selenium is considered to be non-free? Thanks, Julie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On Thu, Jul 04 2013, Daniel P. Berrange wrote: Assuming you're referring to the 'python-selenum' package in Debian, Google throws up this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 the package ships some files which are not yet built from source. Whether this is still accurate or not, is another matter, since that bz is 2 years old... And the debian/copyright file doesn't mention that, so that seems somehow a policy violation to me. -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 07/04/2013 06:10 PM, Julien Danjou wrote: On Thu, Jul 04 2013, Julie Pichon wrote: Thomas Goirand z...@debian.org wrote: Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Why is Selenium considered non-free? The code is Apache-licensed, including the Python bindings. FWIW only a few of the unit tests use Selenium (and those that do, need to), and they're not run by default unless you set a flag to do so. Yes, that seems like a mistake from the Debian packager as far as I can tell. There's nothing that requires it to be in non-free. (Cc'ing Sascha, the maintainer) Well, see this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 There are files not built from source. Also, when looking at the package, it seems that it isn't maintained as good as it deserves. #700061 was opened in 08 Feb 2013, and there's no answer at all from Sascha to this bug (which is RC). That well may have been the reason why this package was removed from testing on the 6th of march (according to the Debian pts). IMO, the maintainer should have at least answered to the bug. Anyway, what isn't explained in #636677, is what is non-free. So I had a look. To me, what is not built from source is what is in py/selenium/webdriver: there is a webdriver.xpi in the firefox folder. Though the maintainer should have write about it, so we don't have to double-guess (it should be clearly documented in debian/copyright). Which part of Selenium is in use in the unit testings of Horizon? Could we imagine that this part of the unit testing be made optional? Like for example, only if python-selenium is installed, or else the tests are gracefully skipped? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 04/07/13 15:55, Daniel P. Berrange wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 the package ships some files which are not yet built from source. Whether this is still accurate or not, is another matter, since that bz is 2 years old... I remember that I filed a bug, because selenium shipped a binary web driver adapter for firefox. E.g there are prebuilt files checked into seleniums svn: http://selenium.googlecode.com/svn/tags/selenium-2.28.0/cpp/prebuilt/ which are/were required to build the whole thing. That was the point where I stopped packaging it for Fedora. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 07/04/2013 03:55 PM, Daniel P. Berrange wrote: On Thu, Jul 04, 2013 at 09:34:01AM -0400, Julie Pichon wrote: Hi Sascha, Sascha Peilicke speili...@suse.com wrote: On 07/04/2013 02:34 PM, Sascha Peilicke wrote: On 07/04/2013 12:03 PM, Matthias Runge wrote: On 04/07/13 11:27, Thomas Goirand wrote: Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Thank you for the heads-up. Selenium is used for tests during development, it is not a runtime requirement at all. Would that still make it non-free for Debian? BTW. this is identical for openSUSE. How did Horizon went into Debian packages at all, since the situation in this front is unchanged for at least a year (just curious). At least here, our horizon test package just doesn't depend on selenium. This could help: https://review.openstack.org/#/c/35649/ Could you explain why Selenium is considered to be non-free? Assuming you're referring to the 'python-selenum' package in Debian, Google throws up this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 the package ships some files which are not yet built from source. This also matches our (as in openSUSE's) definition, python-selenium ships: /usr/lib/python2.7/site-packages/selenium/webdriver/firefox/amd64/x_ignore_nofocus.so /usr/lib/python2.7/site-packages/selenium/webdriver/firefox/x86/x_ignore_nofocus.so /usr/lib/python2.7/site-packages/selenium/webdriver/firefox/webdriver.xpi While in theory they could be build from source, it's simply too much effort. Also, it depends on selenium (the Java thing) which to my knowledge isn't part of any OSS distro because building Java packages is the biggest PITA of all. Usually, such packages are available in 3rd-party repos. Still, we have to patch it away. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 07/04/2013 04:06 PM, Thomas Goirand wrote: On 07/04/2013 06:10 PM, Julien Danjou wrote: On Thu, Jul 04 2013, Julie Pichon wrote: Thomas Goirand z...@debian.org wrote: Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Why is Selenium considered non-free? The code is Apache-licensed, including the Python bindings. FWIW only a few of the unit tests use Selenium (and those that do, need to), and they're not run by default unless you set a flag to do so. Yes, that seems like a mistake from the Debian packager as far as I can tell. There's nothing that requires it to be in non-free. (Cc'ing Sascha, the maintainer) Well, see this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 There are files not built from source. Also, when looking at the package, it seems that it isn't maintained as good as it deserves. #700061 was opened in 08 Feb 2013, and there's no answer at all from Sascha to this bug (which is RC). I am sorry, but I'm an openSUSE guy. But I can tell you we had similar bugs :-) https://bugzilla.novell.com/show_bug.cgi?id=755619 That well may have been the reason why this package was removed from testing on the 6th of march (according to the Debian pts). IMO, the maintainer should have at least answered to the bug. Anyway, what isn't explained in #636677, is what is non-free. So I had a look. To me, what is not built from source is what is in py/selenium/webdriver: there is a webdriver.xpi in the firefox folder. Though the maintainer should have write about it, so we don't have to double-guess (it should be clearly documented in debian/copyright). Which part of Selenium is in use in the unit testings of Horizon? Could we imagine that this part of the unit testing be made optional? Like for example, only if python-selenium is installed, or else the tests are gracefully skipped? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
Matthias Runge mru...@redhat.com wrote: On 04/07/13 15:55, Daniel P. Berrange wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 the package ships some files which are not yet built from source. Whether this is still accurate or not, is another matter, since that bz is 2 years old... I remember that I filed a bug, because selenium shipped a binary web driver adapter for firefox. E.g there are prebuilt files checked into seleniums svn: http://selenium.googlecode.com/svn/tags/selenium-2.28.0/cpp/prebuilt/ which are/were required to build the whole thing. That was the point where I stopped packaging it for Fedora. Thanks for the link Daniel, and Matthias for the extra information. I assume this is the same issue openSUSE has with the package (my google-fu is failing me for finding a bug). Cheers, Julie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] How Nova-api should deal with secgroup identifier being UUID in Quantum ?
Hi guys, As you may know : * with Quantum, secgroups are uniquely identified by UUID. * with Nova-Net, secgroups are uniquely identified by numerical ID. At the moment Nova-api, before calling Nova-Net or Quantum,(see nova/api/openstack/compute/contrib/security_group*) performs some calls to validate_id(), defined in : * nova/network/security_group/quantum_drive.py for Quantum * nova/compute/api.py for Nova-Net Validate_id() raises an HTTPBadRequest in case the identifier is not an UUID for Quantum or an ID for Nova-Net. The first thing to notice is that : (1) It's Nova-API that performs identifier validation and raises the exception. This API mismatch breaks 4 Tempest tests (see bugs.launchpad.net/tempest/+bug/1182384) and could be confusing to the user as Sean Dague reported in this bug report. I see several approaches to deal with this : 1) This API change can't be hidden, clients (and Tempest) must refer to security groups by their specific identifier. Ie Clients must be aware of the backing network implementation. (see review.openstack.org/#/c/29899/) 2) Encapsulate all calls to validate_id() in a try/catch HTTPBadRequest and raise a HTTPNotFound instead (exception translation) 3) Don't do any kind of validation neither for Nova-Net not Quantum. Some unit tests in test_quantum_security_groups.TestQuantumSecurityGroups must be adapted/removed. (see review.openstack.org/#/c/35285/ patchset 2 and 4 for 2 different approaches). Let Quantum and Nova-Net deal with malformed inputs. What do you think ? Thanks a lot ! Jordan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
Sascha Peilicke speili...@suse.com wrote: On 07/04/2013 04:06 PM, Thomas Goirand wrote: On 07/04/2013 06:10 PM, Julien Danjou wrote: On Thu, Jul 04 2013, Julie Pichon wrote: Why is Selenium considered non-free? The code is Apache-licensed, including the Python bindings. FWIW only a few of the unit tests use Selenium (and those that do, need to), and they're not run by default unless you set a flag to do so. Yes, that seems like a mistake from the Debian packager as far as I can tell. There's nothing that requires it to be in non-free. (Cc'ing Sascha, the maintainer) Well, see this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 There are files not built from source. Also, when looking at the package, it seems that it isn't maintained as good as it deserves. #700061 was opened in 08 Feb 2013, and there's no answer at all from Sascha to this bug (which is RC). I am sorry, but I'm an openSUSE guy. But I can tell you we had similar bugs :-) I think Thomas was talking about Sascha Girrulat, the maintainer for the Debian package. https://bugzilla.novell.com/show_bug.cgi?id=755619 It looks like I am not authorised to access this bug, thanks for the link though. I understand the idea :) Julie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS
No, I meant server side, e.g. plugins or plugin drivers. RPC api should be designed in such way that allows sending messages to proper device driver. Thanks, Eugene. On Thu, Jul 4, 2013 at 12:51 PM, Oleg Bondarev obonda...@mirantis.comwrote: Hi Eugene, ...RPC API which then is shared between services. Did you mean device drivers rather than services? Thanks, Oleg On Thu, Jul 4, 2013 at 12:42 PM, Eugene Nikanorov enikano...@mirantis.com wrote: I think the design should be documented on the wiki. Major part of such agent should be corresponding RPC API which then is shared between services. That needs to be thought out and discussed. Thanks, Eugene. On Thu, Jul 4, 2013 at 12:27 PM, Oleg Bondarev obonda...@mirantis.comwrote: Hi folks, While working on agent scheduling for LBaaS reference implementation ( https://review.openstack.org/#/c/32137/) I thought that it would be useful to unify existing agent to make it suite any vendor who wants to use async mechanism and agent scheduling. I filed a blueprint on this - https://blueprints.launchpad.net/neutron/+spec/lbaas-common-agent-driver So what do you guys think? Wishes/suggestions are welcome. Thanks, Oleg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Removing the .mo files from Horizon git
I use Babel simply because the setup.cfg on the core projects are already configured for running babel so all I have to do to generate the .mo files is python setup.py compile_catalog. Thanks, MATT RIEDEMANN Advisory Software Engineer Cloud Solutions and OpenStack Development Phone: 1-507-253-7622 | Mobile: 1-507-990-1889 E-mail: mrie...@us.ibm.com 3605 Hwy 52 N Rochester, MN 55901-1407 United States From: Thomas Goirand z...@debian.org To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 07/04/2013 08:15 AM Subject:Re: [openstack-dev] [horizon] Removing the .mo files from Horizon git On 07/04/2013 10:14 AM, Matt Riedemann wrote: If you use Babel, I don't think you need gettext by itself since I thought Babel has it's own conversion/compile code built-in? But why would you use something in Python, when GNU gettext in C does the job lightning fast, and is available everywhere? Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev image/gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Oslo] Bringing audit standards to Openstack
hi Folks, just wanted to bring everyone's attention to this blueprint we have in Ceilometer: https://blueprints.launchpad.net/ceilometer/+spec/support-standard-audit-formats (detailed bp: https://wiki.openstack.org/wiki/Ceilometer/blueprints/support-standard-audit-formats#Provide_support_for_auditing_events_in_standardized_formats ) as a little background, there are many projects that use Ceilometer to track usage information for statistical usage analysis and billing. these projects are seeing similar auditing requirements which are missing currently. the above blueprint's proposal is to add support for auditing APIs access using the Distributed Mgmt. Task Force?s (DMTF) ?Cloud Audit? standard (CADF). you can read further into the spec via the latest public draft here: http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0a_0.pdf but to highlight the standard, it is an open standard developed by multiple enterprises -- IBM, NetIQ, Microsoft, VMware, and Fujitsu to name a few. Also, the model is regulatory compliant (e.g. PCI-DSS, SoX, ISO 27017, etc.) and extensible so it should adapt to a broad range of uses. initially, we drafted this to be part of Ceilometer but as we've worked through it, we've noticed it is applicable in multiple projects. during the course of our discussions with Keystone developers to assure we were recording the correct data for audit, we found that Keystone itself had a blueprint to add notifications and log audit data for their APIs: https://blueprints.launchpad.net/keystone/+spec/notifications. i thought i'd present this on the mailing list to gather feedback on the idea of adopting CADF and discuss possibly its inclusion in Oslo so that all the projects can use the same open standard when capturing events. cheers, gordon chung openstack, ibm software standards email: chu...@ca.ibm.com___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] Bringing audit standards to Openstack
+1 to Mark's recommendation. In this case probably adding the audit generation events to Nova may be a good place to start. (keystone my be good too!!) -- dims On Thu, Jul 4, 2013 at 5:05 PM, Mark McLoughlin mar...@redhat.com wrote: On Thu, 2013-07-04 at 16:50 -0400, Gordon Chung wrote: initially, we drafted this to be part of Ceilometer but as we've worked through it, we've noticed it is applicable in multiple projects. during the course of our discussions with Keystone developers to assure we were recording the correct data for audit, we found that Keystone itself had a blueprint to add notifications and log audit data for their APIs: https://blueprints.launchpad.net/keystone/+spec/notifications. i thought i'd present this on the mailing list to gather feedback on the idea of adopting CADF and discuss possibly its inclusion in Oslo so that all the projects can use the same open standard when capturing events. My usual recommendation is to prove out the concept in a single project and then, when you go to add it to another project, move it to oslo-incubator. Cheers, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: Chalenges with highly available service VMs
[Moving to list] Hi Sam, responses inline -- Forwarded message -- From: Samuel Bercovici samu...@radware.com Date: Thu, Jun 27, 2013 at 1:43 PM Subject: Chalenges with highly available service VMs To: Mark McClain (mark.mccl...@dreamhost.com) mark.mccl...@dreamhost.com, aro...@nicira.com aro...@nicira.com Cc: Samuel Bercovici samu...@radware.com, Avishay Balderman avish...@radware.com, gary.kot...@gmail.com gary.kot...@gmail.com, gkot...@redhat.com gkot...@redhat.com Hi, ** ** As part of provisioning load balancer service VMs we have encountered the following changes. Our planned HA model for this release is going to use a strategy in which IP addresses are configured on the HA VM pair in the same way but only the active box is “connected” to the network and answers ARP request. When the 1st VM fails and after the 2nd VM detects this, it will do a GARP and will take ownership on the IP addresses. The assumption is the underlying L2 network can support IP to MAC discovery. ** *[arosen] - yup makes sense. * The challenge that we are facing is that currently each Neutron port, automatically gets “security” protection via IP tables which is intended to prevent IP spoofing. If the load balancer service VM gets configured with an IP (ex: VIP) this security blocks traffic to the IP until the Neutron port gets updated with this addition IP. In addition the IP should be allocated/marked as used in a Neutron subnet and currency AFAIK there is no means to allocate an IP address without attaching it to a Neutron port. I do not know how a network based on Nicira behaves as AFAIK it does not use IP tables. ** ** In the case of 2 machines acting as an HA pair the same IP address needs to be assigned to two Neutron ports so that the IP tables rules will be update correctly for bot. AFAIK this (IP attached to two Neutron Pots) is currently not supported. As I expect that get 10s-100s VIPs mapped to the same Neutron port, I am worried that having many rules in a chain will have an impact. ** ** Follows a few options to solve this: **1. **Define a Neutron port as a Neutron service port. In this case the assumption is that the VM/Port belongs to the cloud infrastructure and hence no need to specify the IP tables rules that prevents “MAC” spoofing or “IP” spoofing (which are some of the different strategies to achieve HA). Potentially add support in Nova so that when a VM marked as service VM in nova is provisioned, than the Neutron ports of this VM will be defines as Neutron service ports. *[arosen] - there is already an extension that does this though only the nvp plugin implements it at the time though it shouldn't be very hard to add support for it in other plugins. * https://github.com/openstack/quantum/blob/master/quantum/extensions/portsecurity.py **2. **Add support for assigning the same IP address to two Neutron ports [arosen] - there is a blueprint for pluggable ipam which might work for this. That said. it seems like it might also be worth while to add an extension that allows you to add/remove ip/mac address pairs to a port. ** What do you think? ** ** Regards, -Sam. ** ** ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: Chalenges with highly available service VMs
Seems like a tweak would be to identify virtual IPs as separate to the primary IP on a port: you don't need to permit spoofing of the actual host IP for each host in the HA cluster; you just need to permit spoofing of the virtual IP. This would be safer than disabling the spoofing rules, and avoid configuration errors such as setting the primary IP of one node in the cluster to be a virtual IP on another node - neutron would reject that as the primary IP would be known as that. -Rob On 5 July 2013 09:33, Aaron Rosen aro...@nicira.com wrote: [Moving to list] Hi Sam, responses inline -- Forwarded message -- From: Samuel Bercovici samu...@radware.com Date: Thu, Jun 27, 2013 at 1:43 PM Subject: Chalenges with highly available service VMs To: Mark McClain (mark.mccl...@dreamhost.com) mark.mccl...@dreamhost.com, aro...@nicira.com aro...@nicira.com Cc: Samuel Bercovici samu...@radware.com, Avishay Balderman avish...@radware.com, gary.kot...@gmail.com gary.kot...@gmail.com, gkot...@redhat.com gkot...@redhat.com Hi, ** ** As part of provisioning load balancer service VMs we have encountered the following changes. Our planned HA model for this release is going to use a strategy in which IP addresses are configured on the HA VM pair in the same way but only the active box is “connected” to the network and answers ARP request. When the 1st VM fails and after the 2nd VM detects this, it will do a GARP and will take ownership on the IP addresses. The assumption is the underlying L2 network can support IP to MAC discovery. ** *[arosen] - yup makes sense. * The challenge that we are facing is that currently each Neutron port, automatically gets “security” protection via IP tables which is intended to prevent IP spoofing. If the load balancer service VM gets configured with an IP (ex: VIP) this security blocks traffic to the IP until the Neutron port gets updated with this addition IP. In addition the IP should be allocated/marked as used in a Neutron subnet and currency AFAIK there is no means to allocate an IP address without attaching it to a Neutron port. I do not know how a network based on Nicira behaves as AFAIK it does not use IP tables. ** ** In the case of 2 machines acting as an HA pair the same IP address needs to be assigned to two Neutron ports so that the IP tables rules will be update correctly for bot. AFAIK this (IP attached to two Neutron Pots) is currently not supported. As I expect that get 10s-100s VIPs mapped to the same Neutron port, I am worried that having many rules in a chain will have an impact. ** ** Follows a few options to solve this: **1. **Define a Neutron port as a Neutron service port. In this case the assumption is that the VM/Port belongs to the cloud infrastructure and hence no need to specify the IP tables rules that prevents “MAC” spoofing or “IP” spoofing (which are some of the different strategies to achieve HA). Potentially add support in Nova so that when a VM marked as service VM in nova is provisioned, than the Neutron ports of this VM will be defines as Neutron service ports. *[arosen] - there is already an extension that does this though only the nvp plugin implements it at the time though it shouldn't be very hard to add support for it in other plugins. * https://github.com/openstack/quantum/blob/master/quantum/extensions/portsecurity.py **2. **Add support for assigning the same IP address to two Neutron ports [arosen] - there is a blueprint for pluggable ipam which might work for this. That said. it seems like it might also be worth while to add an extension that allows you to add/remove ip/mac address pairs to a port. ** What do you think? ** ** Regards, -Sam. ** ** ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal for including fake implementations in python-client packages
On 4 July 2013 04:19, Christopher Armstrong chris.armstr...@rackspace.comwrote: On Tue, Jul 2, 2013 at 11:38 PM, Robert Collins robe...@robertcollins.net wrote: Radix points out I missed the naunce that you're targeting the users of python-novaclient, for instance, rather than python-novaclient's own tests. ... So it seems to me that a fast server fake can be used in tests of python-novaclient, *and* in tests of code using python-novaclient (including for instance, heat itself), and we get to write it just once per server, rather than once per server per language binding. -Rob I want to make sure I understond you. Let's say I have a program named cool-cloud-tool, and it uses python-novaclient, python-keystoneclient, and three other clients for OpenStack services. You're suggesting that its test suite should start up instances of all those OpenStack services with in-memory or otherwise localized backends, and communicate with them using standard python-*client functionality? Yes. I can imagine that being a useful thing, if it's very easy to do, and won't increase my test execution time too much. In bzr's test suite we found that such tests (using a non-encrypted plain socket to talk to servers, rather than mock objects) was plenty fast: slowness in the test suite occurred in tests that did a lot of actual vcs operations - it's the lower layers that needed chopping out. I think it's important to draw a distinction between what Joe Gordon is suggesting and what I'm suggesting: nova operations are 10's to 100's of ms today. I'm talking about a lightweight server that responds in single-digit ms. Consider a simple API call - say nova boot. Right now that has a good half dozen rabbit RPC calls: API hands off work which is then done done asynchronously: scheduler, neutron, compute, keystone once keypairs live there, cinder and glance. It's a *lot* of work which isn't useful for cool-cloud-tool, which just wants in it's test suite to: a) make a nova API call b) wait for the 'instance to boot' c) check that the expected API calls were made a and b should be no more than a couple ms apart in a test server; (c) is specific to a test server and not a use case the production server /should/ implement. So while today the fake virt backend for nova exists, its still too far down the stack to deliver the sort of story I'm talking about. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: Chalenges with highly available service VMs
On 4 July 2013 23:42, Robert Collins robe...@robertcollins.net wrote: Seems like a tweak would be to identify virtual IPs as separate to the primary IP on a port: you don't need to permit spoofing of the actual host IP for each host in the HA cluster; you just need to permit spoofing of the virtual IP. This would be safer than disabling the spoofing rules, and avoid configuration errors such as setting the primary IP of one node in the cluster to be a virtual IP on another node - neutron would reject that as the primary IP would be known as that. With apologies for diverting the topic somewhat, but for the use cases I have, I would actually like to be able to disable the antispoofing in its entirety. It used to be essential back when we had nova-network and all tenants ended up on one network. It became less useful when tenants could create their own networks and could use them as they saw fit. It's still got its uses - for instance, it's nice that the metadata server can be sure that a request is really coming from where it claims - but I would very much like it to be possible to, as an option, explicitly disable antispoof - perhaps on a per-network basis at network creation time - and I think we could do this without breaking the security model beyond all hope of usefulness. -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Savanna] Savanna meeting minutes
Thanks everyone who have joined today's Savanna meeting. Here are the logs from today's meeting: Minutes: http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-04-18.07.html Minutes (text): http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-04-18.07.txt Log: http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-04-18.07.log.html Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
