Running horizon/dashboard from git
by Cole Robinson
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-dashboa...
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-opensta...
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
11 years, 10 months
Problem with OpenStack Getting Started Guide
by Steven Dake
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
11 years, 11 months
Cloudy Forecast at FUDCon Blacksburg
by Robyn Bergeron
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
11 years, 11 months
No Cloud SIG meeting today
by Robyn Bergeron
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
11 years, 11 months
Re: P2P Packaging/Koji Cloud
by Denis Arnaud
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
11 years, 11 months
Re: P2P Packaging/Koji Cloud
by Denis Arnaud
> 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
11 years, 11 months
Fedora 17 test day - OpenStack
by Russell Bryant
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
11 years, 11 months
Fwd: New Ruby Guidelines Draft
by Mo Morsi
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
11 years, 11 months
fedora 16 AMI on EC2
by Sandeep Dixit
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
11 years, 11 months
