September 2013 - openSUSE Public Cloud

[opensuse-cloud] Preparing of openSUSE 13.1 OpenStack packages
by Dirk Müller 02 Oct '13

02 Oct '13

Hi, In order to prepare good OpenStack packages for openSUSE 13.1, I've started to submit the necessary changes and reduce the list of enabled packages in C:O:M to an absolute minimum. I've also deleted some python-* overlays that I deemed to be not necessary. In order to have a chance of finding the bugs in 13.1, please do not update packages or reenable the build on 13.1 or Factory repositories, as I would like to run tempest and other tests against plain 13.1, not an insane overlay over 13.1. if there are any newly bugs due to that, don't hesitate to bring it up. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

4 13

[opensuse-cloud] openstack-config is now crudini
by Dirk Müller 30 Sep '13

30 Sep '13

Hi, upstream changed from openstack-config to crudini. It is just s,openstack-config,crudini, no change in command line parameters. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

2 1

[opensuse-cloud] Removing openvswitch support in 13.1/Factory
by Dirk Müller 25 Sep '13

25 Sep '13

Hi, The last openvswitch release available upstream is only supporting up to Kernel 3.8, which means openSUSE 12.3 and older. The current version is failing in Factory to build for 4 months. My suggestion would be to remove openvswitch support for 13.1 (in order to not risk OpenStack getting dropped due to the missing dependency from 13.1/Factory). Any objections to that? Thanks, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

3 5

[opensuse-cloud] OpenStack Clean-VM Testing available for more platforms and coverage
by Dirk Müller 23 Sep '13

23 Sep '13

Hi, just want to report the results of last week's hack sprint. We've completed extending cleanvm integration tests to not only test on one openSUSE platform but instead multiple, as well as SLE 11 SP3. Specifically, for Cloud:OpenStack:Master, I've added a openSUSE 13.1 ("factory") test environment (which currently fails to run). In addition, I've added tempest runs to the builds, so that one can have a much deeper test coverage and can find integration errors quickly. There are still quite a few errors due to slightly incomplete configuration (e.g. EC2/boto tests failing due to that part not being setup), but eventually this will be sorted out.. By default, we'll start a new Tempest run against Cloud:OpenStack:Master whenever a new repo is published ( so ~ daily, unless there are more changes). You can see the status here: http://ci.opensuse.org/view/Cloud/job/openstack-cleanvm/ Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

1 0

[opensuse-cloud] Errors deploying DevStack on openSUSE
by Albert De La Fuente 16 Sep '13

16 Sep '13

Hello, This is my first post on the list =) I'm trying to deploy OpenStack via DevStack for testing purposes. I followed the guide: http://en.opensuse.org/SDB:DevStack, but it doesn't goes as smooth as it says on the guide. In fact I'm having error after error and I'm getting frustrated. I tried both with openSUSE 12.3 and I had an error permission on a python lib which I could fix myself and then I had another error which I don't remember. Then I read that the officially supported was 12.2. I tried again with openSUSE 12.2, and here are the results: - The first error was that glance wasn't running, so I started manually with: glance-api prior stack.sh - The second one was that nova wasn't running, similarly I started manually with: nova-api prior stack.sh Now I'm getting this error: /usr/bin/nova-manage --config-file /etc/nova/nova.conf network create private 10.0.0.0/24 1 256 All the tests were run using devstack from github (master branch). I also tried the stable/folsom branch but openSUSE 12.2 wasn't supported (I had to use FORCE=yes), many errors happened too. Question: How do I deploy devstack on openSUSE (any version would do)??? Thanks a lot! -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

2 1

[opensuse-cloud] Aaagh! - OpenStack Grizzly Django CSRF $&#!!
by Tony Su 10 Sep '13

10 Sep '13

I've never personally been a fan of Django despite its popularity among Python coders... Seems I can't run Lunx against the web dashboard now (Grizzly) because it's possible that Lynx doesn't support CSRF cookies properly. I have Lynx accepting all cookies but there still seems to be a problem and the Dashboard is rejecting Lynx requests accordingly. With a little research, it appears that this has been a major problem with Django since approx 2009 when this first appeared and of course in someone's great wisdom made it impossible to disable/uninstall/neuter this "feature." Also, I cannot find any other web framework which uses this approach to fighting XSS attacks (and AFAIK the XSS problem has been mostly addressed by practically everyone in some way). I'm not seeing this problem using other web browsers, although I'm in the process of determining if the <same> problem I ran into in Folsom using the Quickstart script still exists in Grizzly (initial appearance is the same although too early to be sure) about not setting up the keyring properly for SSL certificates. If I do determine it's the same problem, then it's almost certainly a problem with the SUSE/openSUSE build since I never saw the problem in Devstack 6 months ago and didn't see the problem on a RH which was configured with their Quickstart last night. Tony -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

3 4

[opensuse-cloud] Apresentadora Priscilla Alcantara
by PRIKOTA PRODU��ES 05 Sep '13

05 Sep '13

1 0

Fwd: [opensuse-cloud] Aaagh! - OpenStack Grizzly Django CSRF $&#!!
by Tony Su 04 Sep '13

04 Sep '13

---------- Forwarded message ---------- From: Tony Su <tonysu(a)su-networking.com> Date: Wed, Sep 4, 2013 at 11:11 AM Subject: Re: [opensuse-cloud] Aaagh! - OpenStack Grizzly Django CSRF $&#!! To: Dirk Müller <dirk(a)dmllr.de> Cc: openSUSE Cloud ML <opensuse-cloud(a)opensuse.org> Thx Dirk for the response and offer. In this case though, I'm pessimistic how much can be accomplished with minimal effort... From what I can gather, the CSRF implementation is using cookies which requires some kind of special browser support. My personal feeling is that this is an "extended" use of cookies which IMO is a mis-use of cookie use in general but I can see would be attractive. Maybe this special functionality is built into "modern" browsers universally, but in at least Lynx it isn't so maybe I'll need to look at some other text mode web browsers. If what you say is true that it's the de facto standard CSRF implementation used by most web frameworks, I wouldn't be surprised but would be disappointed in the general use of cookies. But, this is my first experience where Lynx has failed, maybe its requirement is not so universal yet. Tony On Tue, Aug 27, 2013 at 12:41 PM, Dirk Müller <dirk(a)dmllr.de> wrote: > > Hi Tony, > > > > disable/uninstall/neuter this "feature." Also, I cannot find any other > > web framework which uses this approach to fighting XSS attacks (and > > AFAIK the XSS problem has been mostly addressed by practically > > everyone in some way). > > Please note that XSS and CSRF are two completely different things. I > assume from your description that you're indeed talking about CSRF. > There are indeed two ways to implement CSRF protection in django, > using cookies or using hidden form values using POST. given that the > latter is largely inconvenient, CSRF cookies is the de-facto standard > used by most web frameworks. > > I assume there is something wrong with the specific way the cookies > are set though or of some specific incompatibility. > > > I'm not seeing this problem using other web browsers, although I'm in > > the process of determining if the <same> problem I ran into in Folsom > > using the Quickstart script still exists in Grizzly (initial > > appearance is the same although too early to be sure) about not > > setting up the keyring properly for SSL certificates. If I do > > determine it's the same problem, then it's almost certainly a problem > > with the SUSE/openSUSE build since I never saw the problem in Devstack > > 6 months ago and didn't see the problem on a RH which was configured > > with their Quickstart last night. > > That might very well be the case. if you could share the details of > this problem we could be looking at what our setup scripts are doing > wrongly. > > Thanks, > Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

1 0

[opensuse-cloud] Grizzly Quickstart Demo Setup errors
by Tony Su 02 Sep '13

02 Sep '13

Curiously, I'm getting different errors installing different ways... In this message I'll just post the error when installing into a KVM Guest. Later, after trying to install into KVM I'll re-visit the issues I ran into installing into LXC. If someone has an idea how to address, appreciate the ideas. Otherwise, if someone really has been successful running the quickstart on openSUSE 12.3 on bare metal or any type of VM, I'd appreciate the <exact> steps you might have done to conclusion. Thx, Tony ***************************************************************************** KVM Guest openSUSE 12.3/XFCE with one processor and 1.6GB RAM and 8GB disk space, fully updated (zypper up) Normal 12.3/XFCE install and update, then Installed Apache, configured to run as a service and started Installed Mariadb, configured to run as a service and started Installed postgresql-server, configured to run as a service and started Note: I <did not> create admin/root accounts for use on MariaDB or PostgreSQL, to my knowledge that should not be done. Listed the OpenStack patterns (with the Grizzly repo installed) zypper se openstack | grep patterns Then, using zypper installed <all> the patterns and openstack-quickstart without issue. Then ran openstack-quickstart, it runs just fine until it tries to read the quantum network configuration (btw - isn't it supposed to be called neutrino now?) I can post the entire stdout but the following is the critical part... Starting with line line 306 where quantum is restarted + insserv openstack-quantum + /etc/init.d/openstack-quantum restart redirecting to systemctl restart openstack-quantum + . /etc/bash.bashrc.local ++ export HOST_IP=127.0.0.1 ++ HOST_IP=127.0.0.1 ++ . /etc/bash.openstackrc +++ export NOVA_URL=http://127.0.0.1:5000/v2.0/ +++ NOVA_URL=http://127.0.0.1:5000/v2.0/ +++ export NOVA_VERSION=1.1 +++ NOVA_VERSION=1.1 +++ export NOVA_REGION_NAME=RegionOne +++ NOVA_REGION_NAME=RegionOne +++ export NOVA_AUTH_STRATEGY=keystone +++ NOVA_AUTH_STRATEGY=keystone +++ export EC2_URL=http://127.0.0.1:8773/services/Cloud +++ EC2_URL=http://127.0.0.1:8773/services/Cloud +++ export SERVICE_ENDPOINT=http://127.0.0.1:35357/v2.0 +++ SERVICE_ENDPOINT=http://127.0.0.1:35357/v2.0 ++ setcreds admin openstack ++ export NOVA_PROJECT_ID=admin ++ NOVA_PROJECT_ID=admin ++ '[' -z admin ']' ++ export NOVA_USERNAME=admin ++ NOVA_USERNAME=admin ++ export NOVA_API_KEY=openstack ++ NOVA_API_KEY=openstack ++ '[' -z openstack ']' ++ export EC2_ACCESS_KEY=admin ++ EC2_ACCESS_KEY=admin ++ export EC2_SECRET_KEY=openstack ++ EC2_SECRET_KEY=openstack ++ export OS_AUTH_USER=admin ++ OS_AUTH_USER=admin ++ export OS_USERNAME=admin ++ OS_USERNAME=admin ++ export OS_TENANT_NAME=admin ++ OS_TENANT_NAME=admin ++ export OS_AUTH_KEY=openstack ++ OS_AUTH_KEY=openstack ++ export OS_PASSWORD=openstack ++ OS_PASSWORD=openstack ++ export OS_AUTH_TENANT=admin ++ OS_AUTH_TENANT=admin ++ export OS_AUTH_URL=http://127.0.0.1:5000/v2.0/ ++ OS_AUTH_URL=http://127.0.0.1:5000/v2.0/ ++ export OS_AUTH_STRATEGY=keystone ++ OS_AUTH_STRATEGY=keystone + cnt=0 + : + [[ 0 -gt 6 ]] + quantum net-list {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} + [[ 1 -eq 0 ]] + cnt=1 + sleep 2 + : + [[ 1 -gt 6 ]] + quantum net-list {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} + [[ 1 -eq 0 ]] + cnt=2 + sleep 2 + : + [[ 2 -gt 6 ]] + quantum net-list {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} + [[ 1 -eq 0 ]] + cnt=3 + sleep 2 + : + [[ 3 -gt 6 ]] + quantum net-list {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} + [[ 1 -eq 0 ]] + cnt=4 + sleep 2 + : + [[ 4 -gt 6 ]] + quantum net-list {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} + [[ 1 -eq 0 ]] + cnt=5 + sleep 2 + : + [[ 5 -gt 6 ]] + quantum net-list {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} + [[ 1 -eq 0 ]] + cnt=6 + sleep 2 + : + [[ 6 -gt 6 ]] + quantum net-list {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} + [[ 1 -eq 0 ]] + cnt=7 + sleep 2 + : + [[ 7 -gt 6 ]] + echo 'Can'\''t reach quantum server. Exiting !!!' Can't reach quantum server. Exiting !!! + exit 1 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

2 7