cloud December 2011

cloud@lists.fedoraproject.org

31 participants
27 discussions

Running horizon/dashboard from git
by Cole Robinson 17 Jan '12

17 Jan '12

Below are some steps to get openstack horizon (aka dashboard) kinda running. I'm still having issues with talking to nova, hopefully its just a small config problem. Assumes we are starting from a setup similar to http://fedoraproject.org/wiki/Getting_started_with_OpenStack_Nova # Not sure if it's required, but this is how I was running sudo setenforce 0 sudo service iptables stop # First we need to set up keystone, since horizon requires it. sudo yum install -y openstack-keystone # Clear any previous keystone config sudo rm /var/lib/keystone/keystone.sqlite sudo systemctl start openstack-keystone.service # These steps are derived from # http://keystone.openstack.org/configuringservices.html # Assumes that openstack, keystone, and dashboard are all on localhost sudo keystone-manage service add nova compute "Nova Compute Service" sudo keystone-manage service add glance image "Glance Image Service" sudo keystone-manage service add keystone identity "Keystone Identity Service" sudo keystone-manage endpointTemplates add RegionOne nova \ http://localhost:8774/v1.1/ \ http://localhost:8774/v1.1/ \ http://localhost:8774/v1.1/ \ 1 1 sudo keystone-manage endpointTemplates add RegionOne glance \ http://localhost:9292/v1.1/ \ http://localhost:9292/v1.1/ \ http://localhost:9292/v1.1/ \ 1 1 sudo keystone-manage endpointTemplates add RegionOne keystone \ http://localhost:5000/v2.0 \ http://localhost:35357/v2.0 \ http://localhost:5000/v2.0 \ 1 1 sudo keystone-manage user add admin admin sudo keystone-manage user add demo demo sudo keystone-manage tenant add admin sudo keystone-manage tenant add demo sudo keystone-manage role add Admin sudo keystone-manage role grant Admin admin admin sudo keystone-manage token add 999888777666 admin admin 2015-02-05T00:00 sudo keystone-manage role add Member sudo keystone-manage role grant Member demo demo sudo keystone-manage role grant Admin admin demo sudo keystone-manage endpoint add demo nova sudo keystone-manage endpoint add demo glance sudo keystone-manage endpoint add demo identity sudo keystone-manage endpoint add admin nova sudo keystone-manage endpoint add admin glance sudo keystone-manage endpoint add admin identity # Checkout horizon (aka dashboard) git clone git://github.com/openstack/horizon.git horizon.git cd horizon.git git branch --track diablo remotes/origin/stable/diablo git checkout diablo # Now we set up a local environment with all the required dashboard # dependencies, without polluting our system configuration. dashboard # supplies tools for this but some tweaks are needed. sudo yum install -y bzr python-coverage cd openstack-dashboard edit tools/pip-requires, comment out the quantum git URL (reason: https://bugs.launchpad.net/horizon/+bug/888385) python tools/install_venv.py # Manually install quantum into the virtual environment git clone https://github.com/openstack/quantum.git quantum.git cd quantum.git/common ../../tools/with_venv.sh python setup.py install cd ../client ../../tools/with_venv.sh python setup.py install cd ../.. # Run unit tests. Currently looks like 2 tests are failing with a glance # import issue: 'module' object has no attribute 'Error' ./run_tests.sh # No unexpected failures, great! Let's configure the dashboard cd openstack-dashboard # needed by glance imports but wasn't installed automatically ./tools/with_venv.sh pip --verbose install --environment .dashboard-venv/ pycrypto # Actually run the dashboard ./tools/with_venv.sh python dashboard/manage.py runserver syncdb ./tools/with_venv.sh python dashboard/manage.py runserver 127.0.0.1:9000 firefox 127.0.0.1:9000 # should see a login page, accounts are demo:demo or admin:admin log in with admin:admin, it should work! # If openstack-nova-api isn't running, you will see and error like: Unable to get usage info: [Errno 111] Connection refused # If nova-api is running, on log in there will be an error like: Unable to get usage info: This error may be caused by a misconfigured nova url in keystone's service catalog, or by missing openstackx extensions in nova. See the dashboard README. # Not required, but easy to setup the django debugging toolbar ./tools/with_venv.sh pip --verbose install --environment .dashboard-venv/ django-debug-toolbar add the following to local/local_settings.py INTERNAL_IPS = ('127.0.0.1',) DEBUG_TOOLBAR_CONFIG = { "INTERCEPT_REDIRECTS" : False, } # Configure nova to use openstackx admin extension # According to README at: https://github.com/openstack/horizon/blob/stable/diablo/openstack-dashboard… git clone git://github.com/cloudbuilders/openstackx.git /tmp/openstackx cd /tmp/openstackx git branch --track diablo remotes/origin/diablo git checkout diablo Set --osapi_extensions_path=/tmp/openstackx/extensions in /etc/nova/nova.conf sudo systemctl restart openstack-nova-api.service restart dashboard, login # Hmm, didn't change anything? Let's try and configure nova to use # keystone according to instructions at # http://keystone.openstack.org/configuringservices.html#setting-up-openstack… git clone git://github.com/openstack/keystone.git /tmp/keystone Add --api_paste_config=/tmp/keystone/examples/paste/nova-api-paste.ini to /etc/nova/nova.conf sudo systemctl restart openstack-nova-api.service restart dashboard, login # Something changed... error is now: Unable to get usage info: 401 Unauthorized This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required. And that's all I've got for now. The error messages don't prevent poking at some of the UI, but nothing useful like instances are listed. I'd like to find some simple way to test that nova and keystone are working together, so if anyone has ideas that would be appreciated. Thanks, Cole

5 14

Problem with OpenStack Getting Started Guide
by Steven Dake 06 Jan '12

06 Jan '12

The getting started guide is missing the assignment to the em1 interface in the initial ip address range setup. This results in flakey network behavior when VMs are terminated. Analysis of problem: With default guide settings, assume two VMs are run via euca-run-instances. The first VM will get a vnet with a mac address. It will then be added directly into the bridge. The bridge will then take the MAC of the vnet0 interface. Then the second VM will start and get a vnet1 with an assigned MAC address. Killing the first VM that was started (which has a MAC address equal to the br0) will cause deletion of vnet0 and cause the bridge driver to flush the arp table and choose a new bridge interface. This results in disconnection of the remaining VM for 30-60 seconds. A simple solution is to specify a physical bridge interface during bridge creation ie: sudo nova-manage network create markmc 10.0.0.0/24 --bridge=br0 --bridge_interface=em1 This is shown for the compute nodes, but not the controller nodes. With this setting, br0 will always be assigned the MAC address of the bridge interface. Then terminating VMs will not result in the arp table being flushed, and loss of network connectivity. This is shown in the "controller" section of the getting started guide when using compute nodes, but not in the initial setup. Note if vnet0 VM is killed, then the br0 will adopt the mac address of vnet1. Then if vnet1 is killed the network will stall for 30-60 seconds and lose the arp table (while killing the VM associated with vnet0 will have no impact on the network). This does raise the question what to do when em1 is taken out of service. This will cause the bridge driver to flush the arp table and pick a new device (vnet0) resulting in again flakey behavior with the bridges when stopping virtual machines. Just learning the ins and outs of bridges today I don't have a good recommendation for a solution to this "em1 taken out of service" problem. One idea I had was changing nova to add a "dummy" vnet0 before adding em1 or any of the VM vnets (during br0 creation in nova-network). I'm not sure if this would cause traffic to bridge out of the physical interface properly, but it would fix the network connectivity issues and arp table killing that occurs while a new bridge MAC is chosen. Now off to PTO. Regards -steve

4 9

Cloudy Forecast at FUDCon Blacksburg
by Robyn Bergeron 06 Jan '12

06 Jan '12

Hi guys, I realize many of us are on vacation this week but I'm shipping this out in the hopes of getting something organized before the last second, since I am pretty sure I will have plenty of other ohgodlastsecond things to do come FUDCon time. I know that Matt Domsch had previously sent an email about getting together an OpenStack workshop/hackfest while we're at FUDCon. We also presumably have folks planning on doing OTHER THINGS, so, feel free to list your plans, wishes, hopes, dreams, and so forth. Conveniently, I have a wiki page set up for this! https://fedoraproject.org/wiki/FUDCon:Blacksburg_2012_Cloudy_Plans Once we have some stuff listed in the way of workshops/hackfests I'll reserve our room spots for Friday and/or Sunday, hopefully in a non-overlapping kind of way. And so: Garrett, Andy, Greg, Perry, Russell, David, Mike, Matt, Clint, Justin, John Mark, Marek, Karsten, Jeff, Kaleb (???), and anyone I missed, (that's gholms, mull, gregdek, pmyers, drumkilla (I REFUSE TO CALL YOU RUSSELLB), ke4qqq, mmcgrath, mdomsch, herlo, jforbes, johnmark, mgoldmann, quaid, jdarcy, kkeithley for those playing along at home) ...... Get your stuff listed! :) -Robyn

3 2

Please test git-review RPM
by Pete Zaitcev 05 Jan '12

05 Jan '12

Dear All: I am thinking about packaging git-review (the real one, not Facebook's), and to that end I prepared RPMs that are to be submitted for Fedora. Before I do that, I'd like someone verify that they work. AFAIK both Gluster and OpenStack use Gerrit with git-review. These RPMs come from OpenStack source, and I am very curious if they are compatible with Gluster use, so that we can have one in Fedora. http://people.redhat.com/zaitcev/linux/git-review-1.8-1.fc16.noarch.rpm http://people.redhat.com/zaitcev/linux/git-review-1.8-1.fc16.src.rpm Thanks and have a happy New Year, -- Pete

3 4

No Cloud SIG meeting today
by Robyn Bergeron 23 Dec '11

23 Dec '11

Consider it a special gift from me to you. :) <soapbox> I am super delighted with this group - we (and by "we", I mean you guys!) have accomplished a TON of stuff in the past year - we've gone from barely anything to having reliably-created images up on EC2, a boatload of cloud "stuff" / Features in Fedora 15 and 16 (and 17, to be!), having test days, and growing a crew of people helping each other out with a variety of tasks and generally becoming great friends. You guys rock, and this SIG (In my ever-so-humble-and-unbiased opinion) is one of the great spots to get stuff done in Fedora right now. SO PROUD!! </soapbox> Okay, enough of the fluffy stuff. I hope all of you have a great holiday / vacation time / time to get some stuff done without everyone else around. :) And feel free to congregate in the #fedora-cloud channel and have a collective cloud party if you really miss the meeting time today :) Cheers! -Robyn

1 0

Re: P2P Packaging/Koji Cloud
by Denis Arnaud 22 Dec '11

22 Dec '11

Date: Thu, 22 Dec 2011 00:16:31 +0100 > From: Florian La Roche <Florian.LaRoche(a)gmx.net> > > Doing a generic "koji.example.com" image would allow anyone to start rpm > builds and probably many could use this who now object to the many config > steps that koji requires. I am often setting up koji within different > environments to rebuild a few rpms, but haven't setup such a generic image > yet. > Yes, having an image which we can deploy in a VM of a mere server, or even to a cloud, would be already very good. We would have to address the storage of the generated RPMs (i.e., the repositories), and the ability to share/serve the build logs. By the way, it may make sense for RedHat to set up OpenShift in such a way as to also allow RPM building. D

1 0

Re: P2P Packaging/Koji Cloud
by Denis Arnaud 21 Dec '11

21 Dec '11

> Date: Thu, 8 Dec 2011 12:33:38 -0500 > From: seth vidal <skvidal(a)fedoraproject.org> > > I answered Denis immediately at the first post and he concurred it was > a problem. I like to think the conversation evolved as we discussed. > Yes, the conversation has shifted... Indeed, I mixed two distinct ideas: 1. One corresponding to an actual use case: using a private/trusted cloud service to do scratch, chain or even massive builds. 2. Another one corresponding to a dream, really: a P2P cloud, just because it sounds exciting, and would certainly be a USP (unique selling point) for Fedora. >From the answers, it seems that both ideas ring a bell. And, of course, the dream does not seem doable, mainly for security reason. Or it could be implemented as a proof-of-concept of all the technologies and skills, which Fedora gathers under its umbrella? Nevertheless, for now, I am really interested by the item #1 above. For the #2, we never know. Maybe a GSoC, or something like that, could make it happen... Thanks for having shared your thoughts! Regards Denis

2 1

Fedora 17 test day - OpenStack
by Russell Bryant 21 Dec '11

21 Dec '11

Greetings, I have reserved a date for having a Fedora 17 test day for OpenStack. https://fedoraproject.org/wiki/Test_Day:2012-03-08_OpenStack_Test_Day For anyone who is interested in OpenStack, I could use some help getting test cases in shape between now and the test day. Things to look at include: 1) Updating existing test cases as appropriate for changes essex. There may be other general improvements that could be made. One example would be trying to be more consistent about which tools are used in the test cases. Right now sometimes openstack utilities are used, and other times euca2ools are used to do things through the EC2 API. 2) Adding new test cases. I think we should at least have test cases that hit everything we are proposing as a Fedora 17 feature. The existing test cases only hit nova and glance, so there's a lot of work that could be done to include the other components. A feature page has been started for OpenStack Essex in Fedora 17 which you can find here. It's still a work in progress. https://fedoraproject.org/wiki/Features/OpenStack_Essex Thanks, -- Russell Bryant

1 0

Fwd: New Ruby Guidelines Draft
by Mo Morsi 21 Dec '11

21 Dec '11

As another followup to the Ruby 1.9.3 inquiry at last Friday's cloud-sig meeting, here is the new proposed ruby guidelines for Fedora. Also see the following link for packages which might need some work http://lists.fedoraproject.org/pipermail/ruby-sig/2011-December/000729.html -Mo -------- Original Message -------- Subject: New Ruby Guidelines Draft Date: Wed, 21 Dec 2011 06:36:58 -0500 (EST) From: Bohuslav Kabrda <bkabrda(a)redhat.com> Reply-To: Ruby SIG mailing list <ruby-sig(a)lists.fedoraproject.org> To: Ruby SIG mailing list <ruby-sig(a)lists.fedoraproject.org> Hi guys, I promise that this is my last mail today :) Together with Vit, we have created a new Ruby packaging guidelines draft [1] and we would very much like you to go through it, so that we can discuss it here and change it for the best. Regards, Bohuslav. [1] https://fedoraproject.org/wiki/PackagingDrafts/Ruby _______________________________________________ ruby-sig mailing list ruby-sig(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

1 0

fedora 16 AMI on EC2
by Sandeep Dixit 20 Dec '11

20 Dec '11

I just created a Fedora16 (i-26c60f44) instance on AWS. Then I did su -l yum install apache everything went well. I started apache using: service apache start However I public DNS is not able to find the default page. I checked my security group and it has http 80 access. I read in a blog somewhere that with Fedora you have to make sure that files are read? By default they are not - for apache installation? Is this correct? Please advise. Thanks, Sandeep

6 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud December 2011