Re: [openstack-dev] [Horizon] Problem with compressing scss files
After a long investigation, I have found out that, in python-pyscss,
there's the following code in scss/expression.py:
return String(
six.u(%s(%s) % (func_name, six.u(, .join(rendered_args,
quotes=None)
If I remove the first six.u(), and the code becomes like this:
return String(
%s(%s) % (func_name, six.u(, .join(rendered_args))),
quotes=None)
then everything works. Though this comes from a Debian specific patch
for which I added the six.u() calls, to make it work in Python 3.2 in
Wheezy. The original code is in fact:
return String(
u%s(%s) % (func_name, u, .join(rendered_args)),
quotes=None)
So, could anyone help me fixing this? What's the way to make it always
work? I wouldn't like to just drop Python 3.x support because of this... :(
Cheers,
Thomas Goirand (zigo)
On 09/28/2014 12:38 AM, Thomas Goirand wrote:
Hi,
When installing the Juno b3 version of Horizon, the package that I
maintain does the compressions, so that we can use the offline
compression mode, which offers better performances. Unfortunately, it
just breaks. See the log below.
Does anyone has an idea of what's going on, and why this happens?
Cheers,
Thomas Goirand (zigo)
Setting up openstack-dashboard (2014.2~b3-1) ...
RemovedInDjango18Warning: 'The `cycle` template tag is changing to
escape its arguments; the non-autoescaping version is deprecated. Load
it from the `future` tag library to start using the new behavior.
WARNING:py.warnings:RemovedInDjango18Warning: 'The `cycle` template tag
is changing to escape its arguments; the non-autoescaping version is
deprecated. Load it from the `future` tag library to start using the new
behavior.
Found 'compress' tags in:
/usr/share/openstack-dashboard/openstack_dashboard/templates/_stylesheets.html
/usr/lib/python2.7/dist-packages/horizon/templates/horizon/_conf.html
/usr/lib/python2.7/dist-packages/horizon/templates/horizon/_scripts.html
Compressing... CommandError: An error occured during rendering
/usr/share/openstack-dashboard/openstack_dashboard/templates/_stylesheets.html:
Error evaluating expression:
(twbs-font-path() != unquote('twbs-font-path()'))
From bootstrap/scss/bootstrap/_variables.scss:1
...imported from bootstrap/scss/bootstrap.scss:6
...imported from string u'// bootstrap overrides:\n$icon-font-path:
../../bo'...:0
Traceback:
File /usr/lib/python2.7/dist-packages/scss/expression.py, line 130,
in evaluate_expression
return ast.evaluate(self, divide=divide)
File /usr/lib/python2.7/dist-packages/scss/expression.py, line 182,
in evaluate
return self.contents.evaluate(calculator, divide=True)
File /usr/lib/python2.7/dist-packages/scss/expression.py, line 207,
in evaluate
left = self.left.evaluate(calculator, divide=True)
File /usr/lib/python2.7/dist-packages/scss/expression.py, line 329,
in evaluate
six.u(%s(%s) % (func_name, six.u(, .join(rendered_args,
File /usr/lib/python2.7/dist-packages/six.py, line 601, in u
return unicode(s.replace(r'\\', r''), unicode_escape)
TypeError: decoding Unicode is not supported
dpkg: error processing package openstack-dashboard (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
openstack-dashboard
E: Sub-process /usr/bin/dpkg returned an error code (1)
___
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] Problem with compressing scss files
On 09/28/2014 03:35 PM, Thomas Goirand wrote: After a long investigation, I have found out that, in python-pyscss, there's the following code in scss/expression.py: return String( six.u(%s(%s) % (func_name, six.u(, .join(rendered_args, quotes=None) If I remove the first six.u(), and the code becomes like this: return String( %s(%s) % (func_name, six.u(, .join(rendered_args))), quotes=None) then everything works. Though this comes from a Debian specific patch for which I added the six.u() calls, to make it work in Python 3.2 in Wheezy. The original code is in fact: return String( u%s(%s) % (func_name, u, .join(rendered_args)), quotes=None) So, could anyone help me fixing this? What's the way to make it always work? I wouldn't like to just drop Python 3.x support because of this... :( Ops, silly me. The parenthesis aren't correct. Fixing it made it all work. Sorry for the noise, issue closed! Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] where can i get all notifications spec for nova
Hello, Is there some documents to display all notifications in nova? Thanks. -- Best Li Tianqing___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] where can i get all notifications spec for nova
You may find part of them here… https://wiki.openstack.org/wiki/SystemUsageData Regards, Liping Mao From: Li Tianqing [mailto:jaze...@163.com] Sent: 2014年9月28日 16:30 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova] where can i get all notifications spec for nova Hello, Is there some documents to display all notifications in nova? Thanks. -- Best Li Tianqing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] where can i get all notifications spec for nova
Yes. But it's just a part of notifications. Should we collect all notifications and display them in documents? Or is there an elegant way to get all notifications? Thanks. -- Best Li Tianqing At 2014-09-28 17:17:57, Liping Mao -X (limao - YI JIN XIN XI FU WU(SU ZHOU)YOU XIAN GONG SI at Cisco) li...@cisco.com wrote: You may find part of them here… https://wiki.openstack.org/wiki/SystemUsageData Regards, Liping Mao From: Li Tianqing [mailto:jaze...@163.com] Sent: 2014年9月28日 16:30 To:openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova] where can i get all notifications spec for nova Hello, Is there some documents to display all notifications in nova? Thanks. -- Best Li Tianqing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting
2014-09-26 17:11 GMT+02:00 Jay Pipes jaypi...@gmail.com: On 09/26/2014 06:45 AM, Soren Hansen wrote: Define best. best == most appropriate. #copout -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] where can i get all notifications spec for nova
For the next release we will work on automating these into the docs so it stays up to date and is easier to find. See lists.openstack.org/pipermail/openstack-docs/2014-September/005207.html Anne Gentle Content Stacker a...@openstack.org On Sep 28, 2014, at 4:55 AM, Li Tianqing jaze...@163.com wrote: Yes. But it's just a part of notifications. Should we collect all notifications and display them in documents? Or is there an elegant way to get all notifications? Thanks. -- Best Li Tianqing At 2014-09-28 17:17:57, Liping Mao -X (limao - YI JIN XIN XI FU WU(SU ZHOU)YOU XIAN GONG SI at Cisco) li...@cisco.com wrote: You may find part of them here… https://wiki.openstack.org/wiki/SystemUsageData Regards, Liping Mao From: Li Tianqing [mailto:jaze...@163.com] Sent: 2014年9月28日 16:30 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova] where can i get all notifications spec for nova Hello, Is there some documents to display all notifications in nova? Thanks. -- Best Li Tianqing ___ 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] [OpenStack-Dev] [Test PPA's] Glance Test PPA's for Juno missing?
On Sat, Sep 27, 2014 at 12:38 PM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: Also here: http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_basic_environment.html - there is add-apt-repository cloud-archive:juno but I'm not sure if it is ready for tests... Cheers! On 27 September 2014 15:34, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: About this https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/juno-staging ? On 27 September 2014 13:12, John Griffith john.griffi...@gmail.com wrote: Hey Everyone, I've been trying some upgrade testing from Icehouse to Juno on running systems using the test PPA's but I'm running into problems with Glance. Glance fails to update because of python-sqlalchemy deps, poking around I noticed the test PPA list [1] doesn't seem to have a Juno version for Glance, and I'm assuming this is likely the reason I'm stuck. Does anybody know why the Glance packages aren't being built by the test bot? Or if there's another way I can install the glance portion for the upgrade tests? Thanks, John [1]: https://launchpad.net/~openstack-ubuntu-testing-bot/+ppa-packages ___ 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 Cool... thanks Martinx, the CA Staging seems to do the trick. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Unplanned project infrastructure reboots
The OpenStack project infrastructure servers which provide the majority of our developer and community resources will be down for brief periods throughout the day while the service provider donating the resources to run them restarts the underlying Nova compute nodes over the course of a day-long emergency maintenance window. All our systems are designed to tolerate random reboots and getting restarted in any order, but there is still a risk of prolonged impact (particularly due to unforeseen consequences of interrupting interactions between interdependent systems). I will follow up again in roughly 12 hours once I'm reasonably confident the maintenance activity poses no further risk to these systems and have given then a cursory health check to make sure nothing's seriously broken prior to heading into the work week. -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] developer survey on contribution policies
Hi all, I'm gathering input on developer perspectives about CLAs and other contribution policies. While you're clicking through voting for PTLs, I'd appreciate it if you could take an extra 5 minutes and click through the developer survey too: http://survey.lohutok.net/ I'm aiming for a broad and diverse representation of developer communities, so feel free to pass this along to anyone you think might be interested. Thanks, Allison ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] developer survey on contribution policies
Alison, Can you give some more details on the survey with respect to OpenStack ? I have both a developer contribution policy survey and a project contribution policy survey. It would also be good to have more background as to the interest in obtaining the survey results and what you intend to do with them since this is not clear from your post. Tim -Original Message- From: Allison Randal [mailto:alli...@lohutok.net] Sent: 28 September 2014 20:16 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [all] developer survey on contribution policies Hi all, I'm gathering input on developer perspectives about CLAs and other contribution policies. While you're clicking through voting for PTLs, I'd appreciate it if you could take an extra 5 minutes and click through the developer survey too: http://survey.lohutok.net/ I'm aiming for a broad and diverse representation of developer communities, so feel free to pass this along to anyone you think might be interested. Thanks, Allison ___ 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] [infra] Nominating Anita Kuno for project-config-core
Big +1 Franck On Sat, Sep 27, 2014 at 1:18 AM, Boris Pavlovic bo...@pavlovic.me wrote: +1 On Sat, Sep 27, 2014 at 9:51 AM, Nikhil Manchanda nik...@manchanda.me wrote: Big +1 from me. Anita has been super helpful, both with reviews and with discussions on IRC. On Fri, Sep 26, 2014 at 8:34 AM, James E. Blair cor...@inaugust.com wrote: I'm pleased to nominate Anito Kuno to the project-config core team. The project-config repo is a constituent of the Infrastructure Program and has a core team structured to be a superset of infra-core with additional reviewers who specialize in the area. Anita has been reviewing new projects in the config repo for some time and I have been treating her approval as required for a while. She has an excellent grasp of the requirements and process for creating new projects and is very helpful to the people proposing them (who are often creating their first commit to any OpenStack repository). She also did most of the work in actually creating the project-config repo from the config repo. Please respond with support or concerns and if the consensus is in favor, we will add her next week. Thanks, Jim ___ 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] [all] developer survey on contribution policies
On 09/28/2014 11:30 AM, Tim Bell wrote: Can you give some more details on the survey with respect to OpenStack ? I have both a developer contribution policy survey and a project contribution policy survey. It would also be good to have more background as to the interest in obtaining the survey results and what you intend to do with them since this is not clear from your post. It's a topic I've been interested in for over a decade, as I've worked on various different open source projects, in various different roles. People sometimes talk about what most projects do or what most developers want, but I've never seen any data to back up those statements. It can be difficult to have a genuine conversation around a large unknown center. The idea for this particular survey started in the last face-to-face meeting of the OpenStack Foundation board, on the topic of CLAs. I promised several people, but especially Josh McKenty, that I'd gather more concrete statistics on developer opinions about contribution policies, and on project usage patterns for CLAs and other contribution agreements (how common they are, how they're applied, etc). The survey isn't just for OpenStack developers, it's for all FLOSS developers. I'll make a blog post noting general trends across the entire FLOSS community. But, I'll also put together a very condensed informational slide of the results for the OpenStack Foundation board meeting in Paris. Allison ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Nominating Anita Kuno for project-config-core
On Fri, Sep 26, 2014 at 10:34 AM, James E. Blair cor...@inaugust.com wrote: I'm pleased to nominate Anito Kuno to the project-config core team. The project-config repo is a constituent of the Infrastructure Program and has a core team structured to be a superset of infra-core with additional reviewers who specialize in the area. Anita has been reviewing new projects in the config repo for some time and I have been treating her approval as required for a while. She has an excellent grasp of the requirements and process for creating new projects and is very helpful to the people proposing them (who are often creating their first commit to any OpenStack repository). She also did most of the work in actually creating the project-config repo from the config repo. Please respond with support or concerns and if the consensus is in favor, we will add her next week. +1 from me! Thanks, Jim ___ 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] [all] concrete proposal on changing the library testing model with devstack-gate
On 27 September 2014 10:07, Robert Collins robe...@robertcollins.net wrote: TripleO has been running pip releases of clients in servers from the get go, and I've lost track of the number of bad dependency bugs we've encounted. We've hit many more of those than bad releases that crater the world [though those have happened]. And yes, alpha dependencies are a mistake - if we depend on it, its a release. Quod erat demonstratum. Doug has pointed out to me that this is perhaps a little shallow :). So let me try and sketch a little deeper. TripleO's upstream CI looks similar (if more aggressive) to the CD deploy process some of our major contributors are using: we take trunk, wrap it up into a production config and deploy it. There are two major differences vis-a-vis what HP Cloud or Rackspace are doing. Firstly, they're running off a fork which they sync at high frequency - which exists to deal with the second thing, which is that they run deployment specific tests against their tree before deployment, and when that fails, they fix it simultaneously upstream and in the fork. So, more or less *every commit* in Nova, Cinder, etc is going into a production release in a matter of days. From our hands to our users. What TripleO does - and I don't know the exact detail for Rackspace or HP Cloud to say if this is the same) - is that we're driven by requirements.txt files + what happens when things break. So if requirements.txt specifies a thing thats not on PyPI, that causes things to break : we -really- don't like absolute URLs in requirements.txt, and we -really- don't like having stale requirements in requirements.txt. The current situation where (most) everything we consume is on PyPI is a massive step forwards. Yay. But if requirements.txt specifies a library thats not released, thats a little odd. It's odd because we're saying that each commit of the API servers is at release quality (but we don't release because for these big projects a release is much more than just quality - its ecosystem, its documentation, its deployment support)... The other way things can be odd is if requirements.txt is stale: e.g. say cinderclient adds an API to make life easier in Nova. If Nova wants to use that, they could just use it - it will pass the integrated gate which tests tip vs tip. But it will fail if any user just 'pip install' installs Nova. It will fail for developers too. So I think its far better to publish that cinderclient on PyPI so that things do work. And here is where the discussion about alphas comes in. Should we publish that cinderclient as a release, or as a pre-release preview? If we publish it as a pre-release preview, we're saying that we reserve the right to change the API anyway we want. We're not saying that its not release quality: because the API servers can't be at release quality if they depend on non-release quality components. And yet, we /cannot/ change that new cinderclient API anyway we want. Deployers have already deployed the API server that depends on it; they are pulling from pypi: if we push up a breaking cinderclient alpha-2 or whatever, it will break our deployers. Thats why I say that if we depend on it, its released: because in all ways that matter, the constraints that one expects to see on a full release, apply to *every commit* we do within the transitive dependency tree that is the integrated gate. And this isn't because we test together - its because the top level drivers for that gate are the quality of the API server trees, which are CD deployed. The testing strategy doesn't matter so much compared to that basic starting point. To summarise the requirements I believe we have are: - every commit of API servers is production quality and release-ready [for existing features] - we don't break public APIs in projects at the granularity of consumption - Thats per commit for API servers, and per-whatever-pip-grabs-when-installing-api-servers for library projects (e.g. per-release) - requirements.txt should be pip installable at all times - and faithfully represent actual dependencies: nothing should break if one pip installs e.g. nova from git Requirements we *do not have*: - new features within a project have to be production quality on day one That is, projects are allowed to have code that isn't yet supported, though for instance we don't have a good way to annotate that X 'will be a public API but is not yet'. So the alpha thing is a mistake IMO not because we're pushing to PyPI, but because we're calling them alphas, which I don't believe represents the actual state of the code nor our ability to alter things. Right now we test tip vs tip, so some of this is hidden until it breaks TripleO [which is more often than we'd like!] but the incremental, don't break things approach is enforced by the gate, which is good :). My proposal, FWIW, would be that we just call the things we push up to PyPI releases. We've already tested the code in
[openstack-dev] [nova][cinder] (OperationalError) (1040, 'Too many connections') None None
Hi All, I am seeing 'Too many connections' error in nova api and cinder when when installing openstack using the latest.. The error happens when launching couple of VMs (in this test around 5 VMs). Here are the logs when error happens: (1) nova-api logs/traceback: http://paste.openstack.org/show/116414/ (2) cinder api logs/traceback: http://paste.openstack.org/show/hbaomc5IVS3mig8z2BWq/ (3) Stats of some connections: http://paste.openstack.org/show/116425/ As it shown in (3) the issue is not seen with icehouse release. Can somebody please let me know if it is a known issue? Thanks, Nader. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Nominating Anita Kuno for project-config-core
Absolutely. +1. Rackspace Australia On 9/27/14 1:34 AM, James E. Blair wrote: I'm pleased to nominate Anito Kuno to the project-config core team. The project-config repo is a constituent of the Infrastructure Program and has a core team structured to be a superset of infra-core with additional reviewers who specialize in the area. Anita has been reviewing new projects in the config repo for some time and I have been treating her approval as required for a while. She has an excellent grasp of the requirements and process for creating new projects and is very helpful to the people proposing them (who are often creating their first commit to any OpenStack repository). She also did most of the work in actually creating the project-config repo from the config repo. Please respond with support or concerns and if the consensus is in favor, we will add her next week. Thanks, Jim ___ 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] [infra] Nominating Andreas Jaeger for project-config-core
Agreed :-). +1 Rackspace Australia On 9/27/14 1:35 AM, James E. Blair wrote: I'm pleased to nominate Andreas Jaeger to the project-config core team. The project-config repo is a constituent of the Infrastructure Program and has a core team structured to be a superset of infra-core with additional reviewers who specialize in the area. Andreas has been doing an incredible amount of work simplifying the Jenkins and Zuul configuration for some time. He's also been making it more complicated where it needs to be -- making the documentation jobs in particular a model of efficient re-use that is far easier to understand than what he replaced. In short, he's an expert in Jenkins and Zuul configuration and both his patches and reviews are immensely helpful. Please respond with support or concerns and if the consensus is in favor, we will add him next week. Thanks, Jim ___ 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] [infra] Nominating Sean Dague for project-config-core
Awesome. +1. Rackspace Australia On 9/27/14 1:35 AM, James E. Blair wrote: I'm pleased to nominate Sean Dague to the project-config core team. The project-config repo is a constituent of the Infrastructure Program and has a core team structured to be a superset of infra-core with additional reviewers who specialize in the area. For some time, Sean has been the person we consult to make sure that changes to the CI system are testing what we think we should be testing (and just as importantly, not testing what we think we should not be testing). His knowledge of devstack, devstack-gate, tempest, and nova is immensely helpful in making sense of what we're actually trying to accomplish. Please respond with support or concerns and if the consensus is in favor, we will add him next week. Thanks, Jim ___ 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] [tc][cross-project-work] What about adding cross-project-spec repo?
Hi stackers, it goes without saying that working on cross-project stuff in OpenStack is quite hard task. Because it's always hard to align something between a lot of people from different project. And when topic start being too HOT the discussion goes in wrong direction and attempt to do cross project change fails, as a result maybe not *ideal* but *good enough* change in OpenStack will be abandoned. The another issue that we have are specs. Projects are asking to make spec for change in their project, and in case of cross project stuff you need to make N similar specs (for every project). That is really hard to manage, and as a result you have N different specs that are describing the similar stuff. To make this process more formal, clear and simple, let's reuse process of specs but do it in one repo /openstack/cross-project-specs. It means that every cross project topic: Unification of python clients, Unification of logging, profiling, debugging api, bunch of others will be discussed in one single place.. Process description of cross-project-specs: - PTL - person that mange core team members list and puts workflow +1 on accepted specs - Every project have 1 core position (stackforge projects are included) - Cores are chosen by project team, they task is to advocate project team opinion - No more veto, and -2 votes - If 75% cores +1 spec it's accepted. It means that all project have to accept this change. - Accepted specs gret high priority blueprints in all projects With such simple rules we will simplify cross project work: 1) Fair rules for all projects, as every project has 1 core that has 1 vote. 2) Small team that works on cross project features. 3) Faster adoption of cross features 4) Single person/project is not able to block adoption of feature 5) Code unification between projects. E.g. single feature has same implementation in all projects, and this specification is specified in spec. This is just a draft. Any thoughts and ideas are welcome. Best regards, Boris Pavlovic ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
Mark's suggestion works for me as well. If no one objects, I am going to
start the implementation.
Thanks,
Xu Han
On 09/27/2014 01:05 AM, Mark McClain wrote:
On Sep 26, 2014, at 2:39 AM, Xu Han Peng pengxu...@gmail.com
mailto:pengxu...@gmail.com wrote:
Currently the extra_dhcp_opts has the following API interface on a port:
{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
{opt_value: 123.123.123.45, opt_name:
server-ip-address}
],
}
}
During the development of DHCPv6 function for IPv6 subnets, we found
this format doesn't work anymore because an port can have both IPv4
and IPv6 address. So we need to find a new way to specify
extra_dhcp_opts for DHCPv4 and DHCPv6, respectively. (
https://bugs.launchpad.net/neutron/+bug/1356383)
Here are some thoughts about the new format:
Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4
or v6) so we can distinguish opts for v4 or v6 by parsing the
opt_name. For backward compatibility, no prefix means IPv4 dhcp opt.
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name:
*v4:*tftp-server},
{opt_value: [2001:0200:feed:7ac0::1], opt_name:
*v6:*dns-server}
]
Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For
backward compatibility, both old format and new format are
acceptable, but old format means IPv4 dhcp opts.
extra_dhcp_opts: {
ipv4: [
{opt_value: testfile.1,opt_name:
bootfile-name},
{opt_value: 123.123.123.123, opt_name:
tftp-server},
],
ipv6: [
{opt_value: [2001:0200:feed:7ac0::1],
opt_name: dns-server}
]
}
The pro of Option1 is there is no need to change API structure but
only need to add validation and parsing to opt_name. The con of
Option1 is that user need to input prefix for every opt_name which
can be error prone. The pro of Option2 is that it's clearer than
Option1. The con is that we need to check two formats for backward
compatibility.
We discussed this in IPv6 sub-team meeting and we think Option2 is
preferred. Can I also get community's feedback on which one is
preferred or any other comments?
I'm -1 for both options because neither is properly backwards
compatible. Instead we should add an optional 3rd value to the
dictionary: version. The version key would be used to make the
option only apply to either version 4 or 6. If the key is missing or
null, then the option would apply to both.
mark
___
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] [all] Unplanned project infrastructure reboots
On 2014-09-28 14:44:20 + (+), Jeremy Stanley wrote: [...] I will follow up again in roughly 12 hours once I'm reasonably confident the maintenance activity poses no further risk to these systems and have given then a cursory health check to make sure nothing's seriously broken prior to heading into the work week. As predicted, we came through mostly unscathed. At this point everything looks like it should be working normally, with the exception of a couple non-critical informational systems we're continuing to troubleshoot (graphite and logstash/elasticsearch). If you notice any other systems having issues, please let the project infrastructure team know in #openstack-infra on freenode. -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VPNaaS site to site connection down.
Hi Germy We cannot ping the public interface of the 2nd devstack setup (devstack West). From our Cirros instance (First devstack -- devstack east), we can ping our own public ip, but cannot ping the other public ip. I think problem lies here, if we are reaching the devstack west, how can we make a VPN connection Our topology looks like: *CirrOS ---QrouterPublic IP ---publicIPQrouter-CirrOS* _ _ devstack EASTdevstack WEST Also it is important to note that we are not able to ssh the instance private ip, without *sudo ip netns qrouter id *so this means we cannot even ssh with floating ip. it seems there is a problem in firewall or iptables. Please guide On Sunday, September 28, 2014, Germy Lure germy.l...@gmail.com wrote: Hi, masoom: I think firstly you can just check that if you could ping from left to right without installing VPN connection. If it worked, then you should cat the system logs to confirm the configure's OK. You can ping and tcpdump to dialog where packets are blocked. stackers: I think we should give mechanism to show the cause when vpn-connection is down. At least, we could extend an attribute to explain this. Maybe the VPN-incubator project is a chance? BR, Germy On Sat, Sep 27, 2014 at 7:04 PM, masoom alam masoom.a...@gmail.com wrote: Hi Every one, I am trying to establish the VPN connection by giving the neutron ipsec-site-connection-create. neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 172.24.4.233 --peer-id 172.24.4.233 --peer-cidr 10.2.0.0/24 --psk secret For the --peer-address I am giving the public interface of the other devstack node. Please note that my two devstack nodes are on different public addresses, so scenario is a little different than the one described here: https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall The --peer-id is the ip address of the Qrouter connected to the public interface. With this configuration, I am not able to up the VPN site to site connection. Do you think its a firewall issue, I have disabled both firewalls with sudo ufw disable. Any help in this regard. Am I giving the correct parameters? Thanks ___ 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
