Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model
-Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 26 September 2014 22:51 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model Heh, I just got off the phone with Monty talking about this :) Comments inline... On 09/22/2014 03:11 PM, Tim Bell wrote: The quality designation is really important for the operator community who are trying to work out what we can give to our end users. So, I think it's important to point out here that there are three different kinds of operators/deployers: * Ones who use a distribution of OpenStack (RDO, UCA, MOS, Nebula, Piston, etc) * Ones who use Triple-O * Ones who go it alone and install (via source, a mixture of source and packages, via config management like Chef or Puppet, etc) In reality, you are referring to the last group, since operators in the first group are saying we are relying on a distribution to make informed choices about what is ready for prime time because we tested these things together. Operators in the second group are really only HP right now, AFAICT, and Triple- O's opinion on the production readiness of the things it deploys in the undercloud are roughly equal to all of the integrated release that the TC defines. I personally think that if an operator is choosing to be in the third group, then they are taking on the responsibility of testing what they deploy in a staging/test environment in order to validate that it meets their own requirements. In other words, the onus of determining whether something is production ready is on their own shoulders. If the operator chose to deploy OpenStack on top of a vanilla/custom Linux distribution instead of Red Hat, Ubuntu, OpenSUSE, or whatever, we would not complain to the Linux kernel community that they have not made quality designations available for all the pieces we decided to put in our custom Linux distribution. Likewise, I think that is the role of OpenStack distributions: the choices and options that the distributor makes are a result of testing certain things together and the distributor's opinion of quality. If a deployer of OpenStack chooses to go it alone and not use an OpenStack distribution, that's totally cool, but I don't believe it should be the OpenStack developer community's responsibility to vouch for the production readiness of each component of OpenStack. Now, Monty has a big problem with this idea. I know, because he just told me he does :) Monty thinks this attitude of relying on OpenStack distributions to make choices about production quality of OpenStack components leads inevitably to open core opportunities, with some companies choosing to label a few upstream components as production quality and others (the ones the company developed internally) as their production quality choices. I happen to doubt that relying on OpenStack distributions to make these choices will lead to open core stuff. I think there is a hybrid model in addition to your 3 listed of those who take a distribution for the core functions and are then cherry picking the other components according to the cloud they wish to offer. Thus, a distribution would define a base code set complying with the standard APIs and then deployers can select from a stackforge like repository for additional function not in the distribution. An example would be if you used RDO to deploy your cloud and then the Murano package from stackforge to give additional function not in the distribution. Puppetlabs recently announced 'approved' modules (http://www.infoq.com/news/2014/09/puppet-approved-modules) which are intended to help select modules which are not part of the core set but have had a good track record in production. Clearly, there is a difference in governance between the projects which would need a different mechanism for gathering the overall state such as some crowd-sourcing approach like Drupal does. Tim Best, -jay Offering early helps to establish the real-life experience and give good feedback on the designs. However, the operator then risks leaving their users orphaned if the project does not get a sustainable following or significant disruption if the APIs change. The packaging teams are key here as well. When do Ubuntu and Red Hat work out the chain of pre-reqs etc. to produce installable packages, packstack/juju tool support ? We do need to have some way to show that an layer #2 package is ready for prime time production and associated criteria (packages available, docs available, 1 company communities, models for HA and scale, ...) Tim ___ 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
+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] VPNaaS site to site connection down.
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
Re: [openstack-dev] [Sahara] Verbosity of Sahara overview image
On 09/26/2014 02:27 PM, Sharan Kumar M wrote: Hi all, I am trying to modify the diagram in http://docs.openstack.org/developer/sahara/overview.html so that it syncs with the contents. In the diagram, is it nice to mark the connections between the openstack components like, Nova with Cinder, Nova with Swift, components with Keystone, Nova with Neutron, etc? Or would it be too verbose for this diagram and should I be focusing on links between Sahara and other components? Thanks, Sharan Kumar M ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://docs.openstack.org/developer/sahara/architecture.html has a better diagram imho i think the diagram should focus on links between sahara and other components only. best, matt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] setuptools 6.0 ruins the world
If anyone is checking in on their patches this weekend and sees that they seem to be failing on really odd stuff, like docs, pep8, unit tests... it looks like it's because setuptools 6.0 has a terrible memory leak when processing requirements - I've filed it upstream https://bitbucket.org/pypa/setuptools/issue/259/setuptools-60-causes-giant-memory-leaks-in Setuptools 6.0 was released Friday night. (Side note: as a service to others releasing major software bumps on critical python software on a Friday night should be avoided.) If anyone has a direct line to setuptools devs, please reach out. The entire CI pipeline is basically dead until this is addressed. Because of how deeply embedded setuptools is in our environment... there isn't much we can do without an upstream fix. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] setuptools 6.0 ruins the world
On 09/27/2014 09:23 AM, Sean Dague wrote: If anyone is checking in on their patches this weekend and sees that they seem to be failing on really odd stuff, like docs, pep8, unit tests... it looks like it's because setuptools 6.0 has a terrible memory leak when processing requirements - I've filed it upstream https://bitbucket.org/pypa/setuptools/issue/259/setuptools-60-causes-giant-memory-leaks-in Setuptools 6.0 was released Friday night. (Side note: as a service to others releasing major software bumps on critical python software on a Friday night should be avoided.) If anyone has a direct line to setuptools devs, please reach out. The entire CI pipeline is basically dead until this is addressed. Because of how deeply embedded setuptools is in our environment... there isn't much we can do without an upstream fix. Just as I sent this Jason R. Coombs said he pulled the release from pypi. No idea if that will automatically get pulled from our mirrors or not, but that should make things function again (see update in - https://bitbucket.org/pypa/setuptools/issue/259/setuptools-60-causes-giant-memory-leaks-in) -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] setuptools 6.0 ruins the world - SOLVED
setuptools 6.0.1 has been released - https://pypi.python.org/pypi/setuptools/6.0.1#id1 - hopefully addressing this issue. -Sean On 09/27/2014 09:34 AM, Diego Parrilla Santamaría wrote: Hi Sean, I'm getting memory errors today using devstack. Never happened to me before with 8GB of RAM... It seems the mirrors still have the version with the memory leak. Thank you for the information, you saved my day! Diego -- Diego Parrilla http://www.stackops.com/*CEO* **www.stackops.com* http://www.stackops.com/ | * diego.parri...@stackops.com mailto:diego.parri...@stackops.com | +34 91 005-2164 | skype:diegoparrilla * * On Sat, Sep 27, 2014 at 3:27 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: On 09/27/2014 09:23 AM, Sean Dague wrote: If anyone is checking in on their patches this weekend and sees that they seem to be failing on really odd stuff, like docs, pep8, unit tests... it looks like it's because setuptools 6.0 has a terrible memory leak when processing requirements - I've filed it upstream https://bitbucket.org/pypa/setuptools/issue/259/setuptools-60-causes-giant-memory-leaks-in Setuptools 6.0 was released Friday night. (Side note: as a service to others releasing major software bumps on critical python software on a Friday night should be avoided.) If anyone has a direct line to setuptools devs, please reach out. The entire CI pipeline is basically dead until this is addressed. Because of how deeply embedded setuptools is in our environment... there isn't much we can do without an upstream fix. Just as I sent this Jason R. Coombs said he pulled the release from pypi. No idea if that will automatically get pulled from our mirrors or not, but that should make things function again (see update in - https://bitbucket.org/pypa/setuptools/issue/259/setuptools-60-causes-giant-memory-leaks-in) -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Devstack][Ironic] Is devstack gate broken?
Hi all, I have been trying to deploy ironic using devstack, but getting this error: 2014-09-27 14:34:07.758 | ++ err_trap 2014-09-27 14:34:07.759 | ++ local r=1 2014-09-27 14:34:07.760 | stack.sh failed: full log in /opt/stack/devstack.log.2014-09-27-193748 2014-09-27 14:34:07.766 | Error on exit 2014-09-27 14:34:11.235 | df: '/run/user/112/gvfs': Permission denied So, it's a fuse issue. I changes the configuration in /etc/fuse.conf to enable user_allow_other, but it's still the same error. I am having this issue since last night only. Before that it was working completely fine. Anyone else having the same issue? Should I try something else to make it work? Thanks, -- Peeyush Gupta gpeey...@linux.vnet.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack][Ironic] Is devstack gate broken?
On 09/27/2014 10:42 AM, Peeyush Gupta wrote: Hi all, I have been trying to deploy ironic using devstack, but getting this error: 2014-09-27 14:34:07.758 | ++ err_trap 2014-09-27 14:34:07.759 | ++ local r=1 2014-09-27 14:34:07.760 | stack.sh failed: full log in /opt/stack/devstack.log.2014-09-27-193748 2014-09-27 14:34:07.766 | Error on exit 2014-09-27 14:34:11.235 | df: '/run/user/112/gvfs': Permission denied So, it's a fuse issue. I changes the configuration in /etc/fuse.conf to enable user_allow_other, but it's still the same error. I am having this issue since last night only. Before that it was working completely fine. Anyone else having the same issue? Should I try something else to make it work? Thanks, Scroll further back up, the actually error will be before err_trap is printed. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack][Ironic] Is devstack gate broken?
On 09/27/2014 08:15 PM, Sean Dague wrote: On 09/27/2014 10:42 AM, Peeyush Gupta wrote: Hi all, I have been trying to deploy ironic using devstack, but getting this error: 2014-09-27 14:34:07.758 | ++ err_trap 2014-09-27 14:34:07.759 | ++ local r=1 2014-09-27 14:34:07.760 | stack.sh failed: full log in /opt/stack/devstack.log.2014-09-27-193748 2014-09-27 14:34:07.766 | Error on exit 2014-09-27 14:34:11.235 | df: '/run/user/112/gvfs': Permission denied So, it's a fuse issue. I changes the configuration in /etc/fuse.conf to enable user_allow_other, but it's still the same error. I am having this issue since last night only. Before that it was working completely fine. Anyone else having the same issue? Should I try something else to make it work? Thanks, Scroll further back up, the actually error will be before err_trap is printed. -Sean Hi Sean, That part keeps changing, sometimes it's about cinder-api and sometimes it's about mysql connection. I just want to make sure it's not because of some changes in devstack environment. -- Peeyush Gupta gpeey...@linux.vnet.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceph] Why performance of benchmarks with small blocks is extremely small?
Hello all, I installed OpenStack with Glance + Ceph OSD with replication factor 2 and now I can see the write operations are extremly slow. For example, I can see only 0.04 MB/s write speed when I run rados bench with 512b blocks: rados bench -p test 60 write --no-cleanup -t 1 -b 512 Maintaining 1 concurrent writes of 512 bytes for up to 60 seconds or 0 objects Object prefix: benchmark_data_node-17.domain.tld_15862 sec Cur ops started finishedavg MB/s cur MB/s last lat avg lat 0 0 0 0 0 0 - 0 1 183820.0400341 0.0400391 0.008465 0.0120985 2 1 169 168 0.04101110.0419922 0.080433 0.0118995 3 1 240 239 0.03889590.034668 0.008052 0.0125385 4 1 356 355 0.0433309 0.0566406 0.00837 0.0112662 5 1 472 471 0.0459919 0.0566406 0.008343 0.0106034 6 1 550 549 0.0446735 0.0380859 0.036639 0.0108791 7 1 581 580 0.0404538 0.0151367 0.008614 0.0120654 My test environment configuration: Hardware servers with 1Gb network interfaces, 64Gb RAM and 16 CPU cores per node, HDDs WDC WD5003ABYX-01WERA0. OpenStack with 1 controller, 1 compute and 2 ceph nodes (ceph on separate nodes). CentOS 6.5, kernel 2.6.32-431.el6.x86_64. I tested several config options for optimizations, like in /etc/ceph/ceph.conf: [default] ... osd_pool_default_pg_num = 1024 osd_pool_default_pgp_num = 1024 osd_pool_default_flag_hashpspool = true ... [osd] osd recovery max active = 1 osd max backfills = 1 filestore max sync interval = 30 filestore min sync interval = 29 filestore flusher = false filestore queue max ops = 1 filestore op threads = 16 osd op threads = 16 ... [client] rbd_cache = true rbd_cache_writethrough_until_flush = true and in /etc/cinder/cinder.conf: [DEFAULT] volume_tmp_dir=/tmp but in the result performance was increased only on ~30 % and it not looks like huge success. Non-default mount options and TCP optimization increase the speed in about 1%: [root@node-17 ~]# mount | grep ceph /dev/sda4 on /var/lib/ceph/osd/ceph-0 type xfs (rw,noexec,nodev,noatime,nodiratime,user_xattr,data=writeback,barrier=0) [root@node-17 ~]# cat /etc/sysctl.conf net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_sack = 1 Do we have other ways to significantly improve CEPH storage performance? Any feedback and comments are welcome! Thank you! -- Timur, QA Engineer OpenStack Projects Mirantis Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack-Dev] [Test PPA's] Glance Test PPA's for Juno missing?
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] [Horizon] Problem with compressing scss files
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
Re: [openstack-dev] [infra] Nominating Andreas Jaeger for project-config-core
+1 from me, Andreas is very responsive and his reviews are spot on. Regards 2014-09-26 22:11 GMT+02:00 Anne Gentle a...@openstack.org: On Fri, Sep 26, 2014 at 10:35 AM, James E. Blair cor...@inaugust.com 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. Huge +1 - docs CI is a beautiful thing. 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 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?
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
Re: [openstack-dev] [OpenStack-Dev] [Test PPA's] Glance Test PPA's for Juno missing?
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
Re: [openstack-dev] [all] setuptools 6.0 ruins the world - SOLVED
On 09/27/2014 10:20 AM, Sean Dague wrote: setuptools 6.0.1 has been released - https://pypi.python.org/pypi/setuptools/6.0.1#id1 - hopefully addressing this issue. -Sean Thanks for taking care of this, Sean! Though it was kinda interesting to see my little 8GB stinkpad totally brought to its knees doing cinder 'run_tests.sh -f -u'. Chasing requirements.txt wasn't getting me very far. Working now though. -- Tom On 09/27/2014 09:34 AM, Diego Parrilla Santamaría wrote: Hi Sean, I'm getting memory errors today using devstack. Never happened to me before with 8GB of RAM... It seems the mirrors still have the version with the memory leak. Thank you for the information, you saved my day! Diego -- Diego Parrilla http://www.stackops.com/*CEO* **www.stackops.com* http://www.stackops.com/ | * diego.parri...@stackops.com mailto:diego.parri...@stackops.com | +34 91 005-2164 | skype:diegoparrilla * * On Sat, Sep 27, 2014 at 3:27 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: On 09/27/2014 09:23 AM, Sean Dague wrote: If anyone is checking in on their patches this weekend and sees that they seem to be failing on really odd stuff, like docs, pep8, unit tests... it looks like it's because setuptools 6.0 has a terrible memory leak when processing requirements - I've filed it upstream https://bitbucket.org/pypa/setuptools/issue/259/setuptools-60-causes-giant-memory-leaks-in Setuptools 6.0 was released Friday night. (Side note: as a service to others releasing major software bumps on critical python software on a Friday night should be avoided.) If anyone has a direct line to setuptools devs, please reach out. The entire CI pipeline is basically dead until this is addressed. Because of how deeply embedded setuptools is in our environment... there isn't much we can do without an upstream fix. Just as I sent this Jason R. Coombs said he pulled the release from pypi. No idea if that will automatically get pulled from our mirrors or not, but that should make things function again (see update in - https://bitbucket.org/pypa/setuptools/issue/259/setuptools-60-causes-giant-memory-leaks-in) -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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] [oslo] adding James Carey to oslo-i18n-core
+1 On Sat, Sep 27, 2014 at 8:31 AM, Jay S. Bryant jsbry...@electronicjungle.net wrote: On 09/26/2014 06:46 PM, Matt Riedemann wrote: On 9/25/2014 11:04 AM, Ben Nemec wrote: +1. He's on the short list of people who actually understand how all that lazy translation stuff works. :-) -Ben On 09/23/2014 04:03 PM, Doug Hellmann wrote: James Carey (jecarey) from IBM has done the 3rd most reviews of oslo.i18n this cycle [1]. His feedback has been useful, and I think he would be a good addition to the team for maintaining oslo.i18n. Let me know what you think, please. Doug [1] http://stackalytics.com/?module=oslo.i18n ___ 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 I'm not part of the core team but agree with Ben here. Jim is my go-to guy on the i18n stuff, which I'm sure delights him whenever I have issues. :) I second Matt's note! I hadn't voted since I am not a core member. Jim was my partner in crime on the i18n stuff in Icehouse and has done a lot of good work in Juno. I am so thankful for his knowledge and help! So, a big +2 from me. :-) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STO/CBE* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ 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, 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
