Re: [Openstack] Openstack networking failure after server reboot

[Aniruddha Khadkikar]

On Wed, Nov 7, 2012 at 5:52 PM, Gary Kotton  wrote:
> On 11/07/2012 11:47 AM, Aniruddha Khadkikar wrote:
>>
>> Hi Stackers,
>>
>> We have a small Openstack lab using three servers. The components are
>> distributed as:
>> 1. Network controller - Quantum L3&  DHCP, L2 agent, Nova, Openvswitch
>>
>> 2. Cloud controller - Quantum server, L2 agent, Nova, Openvswitch,
>> Dashboard, API, MySQL, Rabbitmq
>> 3. Compute node - Nova, Openvswitch, L2 agent
>>
>> The network is setup in the following way:
>> 1. Each server has 4 nics. We are using only one public IP and one
>> private IP for the openstack setup. We have a private switch for
>> inter-vm communication
>> 2. We are using gre tunnelling and openvswitch
>> 3. br-int is assigned an IP address
>> 4. br-ex is configured for floating IP allocation
>>
>> Everything works perfectly when we are setting it up from scratch
>>
>> Each vm is able to get the private IP's assigned and the NAT based
>> floating IP is also assigned and we are able to SSH into it.
>> The VM's also get created on all the three hosts.
>>
>> So we are confident that we have the right configurations in place as
>> we have fully operational Openstack implementation using gre-tunnels.
>>
>> In order to test the resilience of the setup, we decided to reboot the
>> servers to see if everything comes up again. We faced some dependency
>> of services errors and after server reboot we restarted the services
>> in the proper order i.e. on cloud controller we have mysql, rabbitmq,
>> keystone, openvswitch and quantum-server started. This was followed by
>> starting openvswitch, L3, dhcp and L2 agent. After which we started L2
>> agents on all the remaining servers and followed by nova. There is
>> some confusion on how to orchestrate the right order of services. This
>> could possibly be something we will need to work upon in future.
>>
>> After this, we have nova working properly i.e. we are able to create
>> vm's and the pre-existing ones are also started (virsh list also shows
>> the vm's). ovsctl shows all the interfaces as earlier. However we are
>> unable to access the vm's. On logging into the vm we do not see any IP
>> address being assigned as the VM is unable to contact the dhcp server.
>>
>> The questions that come up are:
>> * What could change after a reboot that would compromise a running
>> network configuration?
>> * Could there be issues with the TAP interfaces created? What is the
>> best way to troubleshoot such a situation?
>> * Has anyone seen a similar behaviour and is it specific to when we
>> use gre-tunnels? Is it then specific to openvswitch which we are
>> using?
>> * On reboot of the network controller are any steps required to ensure
>> that Openstack continues to function properly?
>
>
> Can you please look in the log files for Quantum and see if there are any
> errors?
>
> There is an open issue with Quantum and QPID after rebooting - the Quantum
> service hangs? On the host for Quantum is you do "netstat -an |grep 9696" do
> you see anything?
>

Unfortunately we recreated the cloud again. This time however we have
not assigned an IP to the br-int interface.
It is working currently as we will do the reboot today. By evening I
will provide details of the errors.
In the syslog on the network node we started seeing a lot of:

Nov  7 12:59:30  dnsmasq-dhcp[5722]: last message repeated 3 times
Nov  7 12:59:30 us000901 dnsmasq-dhcp[5746]:
DHCPDISCOVER(tap224fcabc-70) fa:16:3e:52:38:ce
Nov  7 12:59:30 us000901 dnsmasq-dhcp[5722]:
DHCPDISCOVER(tap7736e97e-5c) fa:16:3e:52:38:ce no address available
Nov  7 12:59:30 us000901 dnsmasq-dhcp[5746]: DHCPOFFER(tap224fcabc-70)
172.24.2.11 fa:16:3e:52:38:ce
Nov  7 12:59:30 us000901 dnsmasq-dhcp[5722]:
DHCPDISCOVER(tap7736e97e-5c) fa:16:3e:52:38:ce no address available
Nov  7 12:59:39 us000901 dnsmasq-dhcp[5722]:
DHCPDISCOVER(tap7736e97e-5c) fa:16:3e:52:38:ce no address available
Nov  7 12:59:39 us000901 dnsmasq-dhcp[5746]:
DHCPDISCOVER(tap224fcabc-70) fa:16:3e:52:38:ce
Nov  7 12:59:39 us000901 dnsmasq-dhcp[5746]: DHCPOFFER(tap224fcabc-70)
172.24.2.11 fa:16:3e:52:38:ce
Nov  7 12:59:57 us000901 dnsmasq-dhcp[5722]:
DHCPDISCOVER(tap7736e97e-5c) fa:16:3e:52:38:ce no address available
Nov  7 12:59:57 us000901 dnsmasq-dhcp[5746]:
DHCPDISCOVER(tap224fcabc-70) fa:16:3e:52:38:ce
Nov  7 12:59:57 us000901 dnsmasq-dhcp[5746]: DHCPOFFER(tap224fcabc-70)
172.24.2.11 fa:16:3e:52:38:ce

The above actions are associated with near 100% cpu for kvm processes
and dnsmasq.

The Quantum dhcp log relevant part is at http://pastebin.com/GmksGeK6

Regards
Aniruddha

>>
>> The setup has failed twice on reboot. For the second iteration we are
>> assigning the IP on startup to br-int so that openvswitch does not
>> give errors.
>>
>> Regards
>> Aniruddha
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help 

Re: [Openstack] [openstack-dev] [metering][ceilometer] Unified Instrumentation, Metering, Monitoring ...

[Sandy Walsh]

Hey!

(sorry for the top-posting, crappy web client)

There is a periodic task already in the compute manager that can handle this:
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3021

There seems to be some recent (to me) changes in the manager now wrt the 
resource_tracker.py and stats.py files about how this information gets relayed. 
Now it seems it only goes to the db, but previously it was sent to a fanout 
queue that the schedulers could use. 

Regardless, this is done at a high enough level that it doesn't really care 
about the underlying virt layer, so long at the virt layer supports the 
get_available_resource() method.

https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L152
https://github.com/openstack/nova/blob/master/nova/virt/xenapi/driver.py#L392
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2209

I'd add a hook in there do what we want with this data. Write it to the db, 
send it over the wire, whatever. If there is additional information required, 
it should go in this dictionary (or we should define a format for extensions to 
it).

The --periodic_interval value is meant to be the "fastest tick" approach and 
the individual methods have to deal with how many multiples of the base tick it 
should use. So you can have different data reported at different intervals.

Now, the question of polling vs. pushing shouldn't really matter if the 
sampling rate is predetermined. We can push when the sample is taken or we can 
read from some other store from an external process ... but the sampling should 
only be done in one place, once. 

Hope I answered your question? If not, just repeat it in another way and I'll 
try again :)

-S




From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Eoghan Glynn [egl...@redhat.com]
Sent: Wednesday, November 07, 2012 4:32 PM
To: OpenStack Development Mailing List
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [openstack-dev] [metering][ceilometer] Unified 
Instrumentation, Metering, Monitoring ...

> Here's a first pass at a proposal for unifying StackTach/Ceilometer
> and other instrumentation/metering/monitoring efforts.
>
> It's v1, so bend, spindle, mutilate as needed ... but send feedback!
>
> http://wiki.openstack.org/UnifiedInstrumentationMetering

Thanks for putting this together Sandy,

We were debating on IRC (#heat) earlier the merits of moving the
ceilometer "emission" logic into the services, e.g. directly into the
nova-compute node. At first sight, this seemed to be what you were
getting at with the suggestion:

 "Remove the Compute service that Ceilometer uses and integrate the
  existing fanout compute notifications into the data collected by the
  workers. There's no need for yet-another-worker."

While this could be feasible for measurements driven directly by
notifications, I'm struggling with the idea of moving say the libvirt
polling out of the ceilometer compute agent, as this seems to leak too
many monitoring-related concerns directly into nova (cadence of polling,
semantics of libvirt stats reported etc.).

So I just wanted to clarify whether the type of low level unification
you're proposing includes both push & pull (i.e. notification & polling)
or whether you mainly had just former in mind when it comes to ceilometer.

Cheers,
Eoghan

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Dope'n'Stack (What the F☁☁K is OpenStack) Shirts

[Gabriel Hurley]

Hey all, I just got this from the Dope'n'Stack crew and thought I'd pass it 
along:

---

We know many of you were devastated by not getting a "What the F☁☁K is 
OpenStack" shirt down in San Diego... if you still want one there's a signup 
list available:

https://docs.google.com/spreadsheet/viewform?formkey=dFp4S3lVcWJjMUZYblg4NFpONnpUbmc6MQ

When there's enough party people signed up we'll send out another run for 
production.

If you have no idea what we're talking about, check out the illest thing in the 
whole IT industry: http://www.dopenstack.com/

Two guys who like OpenStack,

- Terrance Dope & Bertram Stack

---

Just wanted to spread the word. ;-)

- Gabriel
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [OSSA 2012-017] Authentication bypass for image deletion (CVE-2012-4573)

[Russell Bryant]

OpenStack Security Advisory: 2012-017
CVE: CVE-2012-4573
Date: November 7, 2012
Title: Authentication bypass for image deletion
Impact: High
Reporter: Gabe Westmaas (Rackspace)
Products: Glance
Affects: Essex, Folsom, Grizzly

Description:
Gabe Westmaas from Rackspace reported a vulnerability in Glance
authentication of image deletion requests. Authenticated users may be
able to delete arbitrary, non-protected images from Glance servers. Only
Folsom/Grizzly deployments that expose the v1 API are affected by this
vulnerability. Additionally, Essex deployments that use the
delayed_delete option are also affected.

Fixes:
Grizzly:
https://github.com/openstack/glance/commit/6ab0992e5472ae3f9bef0d2ced41030655d9d2bc
2012.2 (Folsom):
https://github.com/openstack/glance/commit/90bcdc5a89e350a358cf320a03f5afe99795f6f6
2012.1 (Essex): https://review.openstack.org/#/c/15562/

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2012-4573
https://bugs.launchpad.net/glance/+bug/1065187

Notes:
This fix will be included in the grizzly-1 development milestone and in
a future 2012.2 (Folsom) release.

-- 
Russell Bryant
OpenStack Vulnerability Management Team

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [openstack-dev] [metering][ceilometer] Unified Instrumentation, Metering, Monitoring ...

[Eoghan Glynn]

> Here's a first pass at a proposal for unifying StackTach/Ceilometer
> and other instrumentation/metering/monitoring efforts.
> 
> It's v1, so bend, spindle, mutilate as needed ... but send feedback!
> 
> http://wiki.openstack.org/UnifiedInstrumentationMetering

Thanks for putting this together Sandy,

We were debating on IRC (#heat) earlier the merits of moving the
ceilometer "emission" logic into the services, e.g. directly into the
nova-compute node. At first sight, this seemed to be what you were
getting at with the suggestion:

 "Remove the Compute service that Ceilometer uses and integrate the
  existing fanout compute notifications into the data collected by the
  workers. There's no need for yet-another-worker."

While this could be feasible for measurements driven directly by
notifications, I'm struggling with the idea of moving say the libvirt
polling out of the ceilometer compute agent, as this seems to leak too
many monitoring-related concerns directly into nova (cadence of polling,
semantics of libvirt stats reported etc.).

So I just wanted to clarify whether the type of low level unification
you're proposing includes both push & pull (i.e. notification & polling)
or whether you mainly had just former in mind when it comes to ceilometer.

Cheers,
Eoghan

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Swift] container synchronization failed on AWS EC2

[Ning Zhang]

Hello All,

I setup two fresh and clean Swift clusters on AWS EC2. I follow the
guide 
(http://docs.openstack.org/developer/swift/overview_container_sync.html 
)

to synchronize two containers in these two clusters.
The two containers itself could be synchronized perfectly
(the containers are correctly created at both clusters),
but the data in the two containers are not synchronized
(if I populate some data in a container at one cluster,
the container at the other cluster is always empty)

I also created two Swift clusters in our local data center and follow
the same procedure to synchronize two clusters. This time,
both containers and data could be synchronized correctly.

So, is there any special setting in EC2 (e.g. security group,
firewall) that will block the data synchronization between
the two clusters?

Thanks,

Ning

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Moniker][DNSaaS] Reminder: Weekly meeting today @ 18:00 UTC

[Kiall Mac Innes]

Thanks to all who attended!

Minutes:
http://eavesdrop.openstack.org/meetings/dnsaas/2012/dnsaas.2012-11-07-18.03.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/dnsaas/2012/dnsaas.2012-11-07-18.03.txt
Log:
http://eavesdrop.openstack.org/meetings/dnsaas/2012/dnsaas.2012-11-07-18.03.log.html



Thanks,
Kiall


On Wed, Nov 7, 2012 at 1:55 PM, Kiall Mac Innes  wrote:

> Hi All,
>
> Just a friendly reminder that Moniker is having it's second weekly IRC
> meeting today and 18:00 UTC[1] in #openstack-meeting. That's 2 hours from
> now.
>
> Since Moniker is a new StackForge project, I'll remind everyone what it
> does!
>
> Moniker provides DNSaaS services for OpenStack:
>
>- REST API for domain/record management
>- Multi-tenant
>- Integrated with Keystone for authentication
>- Framework in place to integrate with Nova and Quantum notifications
>(for auto-generated records)
>- Support for Bind9 out of the box (Refactoring this to be more
>pluggable will be complete in the next few days)
>- .. I've probably missed lot's more off this list!
>
> The agenda has been posted on the OpenStack wiki[2], anyone with an
> interest in DNSaaS is encouraged to attend.
>
>  See you there!
>
> Thanks,
> Kiall
>
> [1]: *http://www.timeanddate.com/worldclock/fixedtime.html?iso=20121107T18
> *
> [2]: http://wiki.openstack.org/Meetings/DNSaaS
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [devstack] Malformed Documentation on stack.sh script web site

[Dean Troyer]

On Wed, Nov 7, 2012 at 9:27 AM, Gui Maluf  wrote:
> In http://devstack.org/stack.sh.html above "Log Files", the whole
> documentation is malformed. All descriptions stop to match with the current
> piece of code. I don't know who to warn, so I'm sending this email here.

Actually, it is the reverse that is the case...everything _after_ "Log
Files" is broken.  We use shocco to format those pages from the bash
scripts.  It treats the comments as documentation and puts it to the
left of the code that follows.  This is why there is markdown
formatting in the comments of devstack scripts.

In this particular case, the spinner string was being improperly
recognized by shocco and it stopped formatting the output.

This is a good excuse to do another periodic doc/formatting pass
through stack.sh, I'll commit this fix then.

dt

-- 

Dean Troyer
dtro...@gmail.com

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Salvatore Orlando]

Kevin is correct; as your're running IP namespaces, you'll need to look for
iptables in that namespace.
The metadata settings however are visible in the log extract you posted.
It seems your metadata server is sitting at 172.16.0.201:8775
I guess you've already ensured that endpoint is reachable from the router
(a wget execute in the router namespace will prove that).

Also, metadata is one of those (few) features which in Quantum come with
strings attached. You can find more info on this in the admin guide [1].
The link to the page where metadata are discussed reported below, just in
case you haven't already seen it.

Salvatore


[1]
http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html

On 7 November 2012 19:00, Stephen Gran  wrote:

> **
> On Wed, 2012-11-07 at 16:02 +, Kevin Jackson wrote:
>
> Heyup good folk of OpenStack,
> I'm having the same issue as Sina.  My configuration seems to look OK (I
> have an instance, with IP that can ping its default route to on an internal
> network) but I get the failure to contact the metadata server with the
> explanation that Sina gave.
>
> In my /var/log/quantum/l3_agent.log I have the following:
> http://paste.openstack.org/show/24801/
> There's also a paste of an iptables output that I would've expected to see
> the DNAT rules in.
>
> What am I missing?
>
>
> You're not looking in the correct network namespace:
>
> ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 iptables -L -v
> -t nat
> ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 ip r
>
> Cheers,
>
> --
> Stephen Gran
> Senior Systems Integrator - guardian.co.uk
>
>   Please consider the environment before printing this email.
> --
> Visit guardian.co.uk - website of the year
>  www.guardian.co.ukwww.observer.co.uk www.guardiannews.com
>
> On your mobile, visit m.guardian.co.uk or download the Guardian
> iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad
>
> Save up to 37% by subscribing to the Guardian and Observer - choose the 
> papers you want and get full digital access.
> Visit guardian.co.uk/subscribe
>
> -
> This e-mail and all attachments are confidential and may also
> be privileged. If you are not the named recipient, please notify
> the sender and delete the e-mail and all attachments immediately.
> Do not disclose the contents to another person. You may not use
> the information for any purpose, or store, or copy, it in any way.
>
> Guardian News & Media Limited is not liable for any computer
> viruses or other material transmitted with or as part of this
> e-mail. You should employ virus checking software.
>
> Guardian News & Media Limited
>
> A member of Guardian Media Group plc
> Registered Office
> PO Box 68164
> Kings Place
> 90 York Way
> London
> N1P 2AP
>
> Registered in England Number 908396
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [ceilometer] Hbase storage backend for Ceilometer - blueprint?

[Julien Danjou]

On Wed, Nov 07 2012, shengjie_...@dell.com wrote:

Hi Shengjie,

> I am looking for a way to propose a blueprint to the ceilometer team -
> "Adding Hbase storage backend for ceilometer". Currently we have only
> MongoDB and SQLalchemy as the possible ceilometer storage backend. Given the
> storage interface is clearly designed and allows us to have different
> backend, it would be nice to have more options which make Ceilometer more
> adoptive to some providers' existing architectures. As a cloud IAAS
> provider, Ceilometer might not be just considered as a usage db, also it's
> being seen as a centralized place to store all the usage data cross
> platforms. Additionally, all the historical usage data stored can be used
> for historical usage analysis as well, this is where MapReduce comes into
> play. With Hadoop Hbase, it allows usage data to be stored in HDFS, also it
> gives us the ability to run large scale massive MapRed analysis jobs in the
> future.

This is indeed a good idea, and as you pointed out, Ceilometer collector
has been designed so this is being possible.

I think you can create a blueprint here:

  https://blueprints.launchpad.net/ceilometer

And write in what should be done.

-- 
Julien Danjou
;; Free Software hacker & freelance
;; http://julien.danjou.info


pgp0Y6makV0xI.pgp
Description: PGP signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Stephen Gran]

On Wed, 2012-11-07 at 16:02 +, Kevin Jackson wrote:

> Heyup good folk of OpenStack,
> I'm having the same issue as Sina.  My configuration seems to look OK
> (I have an instance, with IP that can ping its default route to on an
> internal network) but I get the failure to contact the metadata server
> with the explanation that Sina gave.
> 
> In my /var/log/quantum/l3_agent.log I have the following:
> http://paste.openstack.org/show/24801/
> There's also a paste of an iptables output that I would've expected to
> see the DNAT rules in.
> 
> What am I missing?


You're not looking in the correct network namespace:

ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 iptables -L
-v -t nat
ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 ip r

Cheers,
-- 
Stephen Gran
Senior Systems Integrator - guardian.co.uk

Please consider the environment before printing this email.
--
Visit guardian.co.uk - website of the year
 
www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 
 
On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad 
 
Save up to 37% by subscribing to the Guardian and Observer - choose the papers 
you want and get full digital access. 
Visit guardian.co.uk/subscribe
 
-
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
 
Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
 
Guardian News & Media Limited
 
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
 
Registered in England Number 908396
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [ceilometer] Hbase storage backend for Ceilometer - blueprint?

[Shengjie_Min]

Hi,

I am looking for a way to propose a blueprint to the ceilometer team - "Adding 
Hbase storage backend for ceilometer". Currently we have only MongoDB and 
SQLalchemy as the possible ceilometer storage backend. Given the storage 
interface is clearly designed and allows us to have different backend, it would 
be nice to have more options which make Ceilometer more adoptive to some 
providers' existing architectures. As a cloud IAAS provider, Ceilometer might 
not be just considered as a usage db, also it's being seen as a centralized 
place to store all the usage data cross platforms. Additionally, all the 
historical usage data stored can be used for historical usage analysis as well, 
this is where MapReduce comes into play. With Hadoop Hbase, it allows usage 
data to be stored in HDFS, also it gives us the ability to run large scale 
massive MapRed analysis jobs in the future.

Thanks,
Shengjie
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Minutes from the Technical Committee meeting (Nov 6)

[Thierry Carrez]

The OpenStack Technical Committee ("TC") met in #openstack-meeting at
20:00 UTC yesterday.

Here is a quick summary of the outcome of this meeting:

* The Heat project was granted Incubation status and will
therefore be able to access additional OpenStack common resources,
including tapping into CI, QA and Release management teams.

* At the request of the Board of Directors, the TC discussed the future
of the Incubation process. Given the variety of opinions and the breadth
of the subject, it was decided to move that discussion to the
openstack-dev mailing-list, so that the TC can better define its
position before a future joint discussion with the Board of Directors.
Once the Incubation process and what is "OpenStack Core" will be better
defined, the TC will revisit the currently-incubated projects to check
if they still fulfill the new definition, if any.

See details and full logs at:
http://eavesdrop.openstack.org/meetings/tc/2012/tc.2012-11-06-20.02.html

More information on the Technical Committee at:
http://wiki.openstack.org/Governance/TechnicalCommittee

-- 
Thierry Carrez (ttx)
Chair, OpenStack Technical Committee

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Kevin Jackson]

Heyup good folk of OpenStack,
I'm having the same issue as Sina.  My configuration seems to look OK (I
have an instance, with IP that can ping its default route to on an internal
network) but I get the failure to contact the metadata server with the
explanation that Sina gave.

In my /var/log/quantum/l3_agent.log I have the following:
http://paste.openstack.org/show/24801/
There's also a paste of an iptables output that I would've expected to see
the DNAT rules in.

What am I missing?

Cheers,
Kev


On 7 November 2012 14:35, Choe, Cheng-Dae  wrote:

> - DNAT rule to metadata server is done by l3_agent. but your node
> configuration has no l3_agent
> - and metadata_ip configuration can find l3_agent.ini.
>
> 2012. 11. 7., 오후 9:15, Sina Sadeghi  작성:
>
>  Hello all,
>
> I thought I would giv
> e quantum a shot and I've got a 50-60% working configuration, but having
> trouble understanding where to go from here as the docs are pretty sparse.
>
>
> Ubuntu 12.04.1 + "ubuntu cloud archive" folsom repo
>
> node A: nova-api, nova-scheduler, quantum-server, quantum-plug
> in-openvswitch
> node B: nova-compute, nova-api-metadata, quantum-dhcp-agent, quantum-plug
> in-openvswitch-agent
> node C: nova-compute,
> nova-api-metadata, quantum-dhcp-agent, quantum-plugin-openvswitch-agent
>
> configured as follows:
>
> quantum.conf:
> ...
> core_plugin =
> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
> ...
>
> ovs_quantum_plugin.ini:
> ...
> tenant_network_type=vlan
> network_vlan_ranges = default:2000:3999
> integration_bridge = br-int
> bridge_mappings = default:br-eth3
> ...
>
> node B,C `ovs-vstl list-br`:
> br-eth3
> br-int
>
> node B,C `ovs-vsctl list-ports br-int`:
> int-br-eth3 (created by quantum?)
>
> node B,C `ovs-vsctl list-ports br-eth3`:
> eth3 (added by me)
> phy-br-eth3 (created by quantum?)
>
> eth3 is a NIC which is connected to a switchport accepting VLAN
> 2000:3999. It has no IP assigned currently.
>
> When I start the 12.04 ubuntu "cloud-image" in the dashboard, it
> successfully boots and obtains an IP address as seen in the co
> nsole output:
> cloud-init-nonet waiting 120 seconds for a network device.
>
> ci-info: lo: 1 127.0.0.1   255.0.0.0   .
> ci-info: eth0  : 1 192.168.253.5   255.255.255.0   fa:16:3e:80:33:71
> ci-info: route-0: 0.0.0.0 192.168.253.1   0.0.0.0 eth0   UG
> ci-info: route-1: 192.168.253.0   0.0.0.0 255.255.255.0   eth0   U
>
> However, immediately after that output I see this
>
> 2012-11-07 11:27:29,598 - util.py[WARNING]: '
> http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]:
> url error [[Errno 113] No route to host]
>
> which runs until it times out.
>
> In older versions of
> OpenStack, when I ran 'iptables-save | grep 169.254.169.254' on a 
> metadataserver I was used to seeing a rule show up
> which translated that 169 address to the variable assigned by metadata_host
> in nova.conf, but I note that rule doesn't show up in this version of
> nova? I added the old rule in (to see what would happen) but the result
> was the same, still no route to host.
>
>
> What steps do I need to take here to allow my instance to retrieve its
> metadata? Is my quantum misconfigured somehow? Perhaps
> I need to go back and reconfigure my switch port (for example, there is
> no real 192.168.253.1 gw, but does there need to be for the instance to
> simply fetch metdata)? After that, what steps do I need to take to get
> the VM connected to the rest of the world? Is the quantum-l3-agent the only
> real choice right now?
>
> Thx.
>
> --
>
> --
> *Sina Sadeghi*
> Lead Cloud Engineer
> 
>
> *Aptira Pty Ltd*
> 1800 APTIRA
> aptira.com 
> Follow @aptira 
>
>  ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Kevin Jackson
@itarchitectkev
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [openstack][cinder] cinder create gives an error

[Ahmed Al-Mehdi]

John,

I verified step 13 in the Migrate twiki.  Just curious, should I create the VG 
in a certain directory (e.g  /var/lib/cinder/volumes).

Also, In the document "Openstack Deploy and Install manual", the steps for 
nova-volume recommend having a VG group called nova-volumes (created from a 
partition).  However, the steps mentioned in ( 
http://docs.openstack.org/trunk/openstack-compute/install/apt/content/osfolubuntu-cinder.html
 ) creates a VG from a local file.   Will be the recommend way to setup cinder 
service going forward.  Just making sure I am not missing anything.

root@bodega:/etc/cinder# date; cinder --debug  create   --display_name test 1
Wed Nov  7 07:06:20 PST 2012
connect: (10.176.20.158, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: 
10.176.20.158:5000\r\nContent-Length: 108\r\ncontent-type: 
application/json\r\naccept-encoding: gzip, deflate\r\naccept
: application/json\r\nuser-agent: pyth
on-cinderclient\r\n\r\n{"auth": {"tenantName": "openstackDemo", 
"passwordCredentials": {"username": "admin", "password": "admin"}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Vary: X-Auth-Token
header: Content-Type: application/json
header: Date: Wed, 07 Nov 2012 15:06:21 GMT
header: Transfer-Encoding: chunked
connect: (10.176.20.158, 8776)
send: u'POST /v1/ce1e819636744dc680fa5515f6475e87/volumes HTTP/1.1\r\nHost: 
10.176.20.158:8776\r\nContent-Length: 267\r\nx-auth-project-id: 
openstackDemo\r\naccep
t-encoding: gzip, deflate\r\naccept: a
pplication/json\r\nx-auth-token: 
6cd16b521733442bb3b1dda1dd4e07fa\r\nuser-agent: 
python-cinderclient\r\ncontent-type: application/json\r\n\r\n{"volume": 
{"status": "creating", "availability_zone": nul
l, "display_description": null, "snapshot_id": null, "user_id": null, "size": 
1, "display_name": "test", "imageRef": null, "attach_status": "detached", 
"volume_type": null, "project_id": null, "metada
ta": {}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: X-Compute-Request-Id: req-a197827f-f1fd-4bc8-86a1-93f14e6cdb4f
header: Content-Type: application/json
header: Content-Length: 296
header: Date: Wed, 07 Nov 2012 15:06:21 GMT
+-+--+
|   Property  |Value |
+-+--+
| attachments |  []  |
|  availability_zone  | nova |
|  created_at |  2012-11-07T15:06:21.369097  |
| display_description | None |
| display_name| test |
|  id | f8ee648c-455b-4f54-bb9e-8eafbdc33add |
|   metadata  |  {}  |
| size|  1   |
| snapshot_id | None |
|status   |   creating   |
| volume_type | None |
+-+--+
root@bodega:/etc/cinder#
root@bodega:/etc/cinder#
root@bodega:/etc/cinder# date; cinder --debug  list
Wed Nov  7 07:06:47 PST 2012
connect: (10.176.20.158, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: 
10.176.20.158:5000\r\nContent-Length: 108\r\ncontent-type: 
application/json\r\naccept-encoding: gzip, deflate\r\naccept: 
application/json\r\nuser-agent: pyth
on-cinderclient\r\n\r\n{"auth": {"tenantName": "openstackDemo", 
"passwordCredentials": {"username": "admin", "password": "admin"}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Vary: X-Auth-Token
header: Content-Type: application/json
header: Date: Wed, 07 Nov 2012 15:06:47 GMT
header: Transfer-Encoding: chunked
connect: (10.176.20.158, 8776)
send: u'GET /v1/ce1e819636744dc680fa5515f6475e87/volumes/detail 
HTTP/1.1\r\nHost: 10.176.20.158:8776\r\nx-auth-project-id: 
openstackDemo\r\nx-auth-token: 696766788b9e449e8058dea454f12298\r\naccept-enc
oding: gzip, deflate\r\naccept: application/json\r\nuser-agent: 
python-cinderclient\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: X-Compute-Request-Id: req-c89c9562-5237-4d33-bcbc-e756e763ca3a
header: Content-Type: application/json
header: Content-Length: 296
header: Date: Wed, 07 Nov 2012 15:06:47 GMT
+--++--+--+-+-+
|  ID  | Status | Display Name | Size | Volume 
Type | Attached to |
+--++--+--+-+-+
| f8ee648c-455b-4f54-bb9e-8eafbdc33add | error  | test |  1   | 
None| |
+--++--+--+-+-+
root@bodega:/etc/cinder#

Thank you,
Ahmed.


Regards,
Ahmed.

From: John Griffith 
mailto:john.griff...@solidfire.com>>
Date: Tuesday, November 6, 2012 3:53 PM
To: Ahmed Al-Mehdi mailto:ah...@coraid.com>>
Cc: "openstack@lists.launchpad.n

[Openstack] [devstack] Malformed Documentation on stack.sh script web site

[Gui Maluf]

In http://devstack.org/stack.sh.html above "Log Files", the whole
documentation is malformed. All descriptions stop to match with the current
piece of code. I don't know who to warn, so I'm sending this email here.

Hope it'll be fixed!

att


-- 
*guilherme* \n
\tab *maluf*
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] How do I use the "private" network for glance image transfers?

[Erik Lindblad]

Hello!

I have a pretty basic setup (following the installation guide) of essex on
ubuntu 12.04.

One controller that runs all services and two compute nodes.

The machines are all connected to our office network on eth0, and to a
private (physically separate) network on eth1.

The setup works fine, but I would like to utilize the private network for
image transfers.

I'm using the flat_dhcp network manager. Private network is
192.168.96.0/21(fixed range 192.168.100.1-255)

So basically, I would like to assign an ip, say 192.168.99.1,2,3... on eth1
for my nodes and be able to use glance_api_servers=192.168.99.1:9292 in
nova.conf.

The problem is that nova-network seems to overwrite any configuration i set
in /etc/network/interfaces when setting up networking for nova-compute.

Has anyone tried a similar setup? Any idea where to start looking or if
this is even possible?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Plans for Trusted Computing in OpenStack

[Nicolae Paladi]

Hi,

so basically my questions/thoughts about support for TC in OpenStack are
based on a
somewhat different attack model where the IaaS is actually not trusted.

That is in contrast with the Trusted Compute Pools, where the
scheduler/trusted_filter
is assumed to reject the host as a candidate for running the VM if it does
not have a
corresponding "trust value". However, nothing prevents a really evil IaaS
deployment
to ignore this trust value and go ahead, launch the VM and return it to the
client. So
there's an improvement suggestion focusing on that part.

The model that I have in mind assumes both no trust in the IaaS
setup/provider.

So the gist is that:

1. Client could upload a secret encrypted with the public key of the
authentication service
(possible to include in the extra_specs)

2. The Attestation Service, after verifying the compute host could bind the
secret to the
hosts trusted configuration, so that the host can inject the secret into
the VM

With this approach, a malicious IaaS provider can still launch the VM on an
untrusted host, but
now he client can verify that the VM has been started on a 'trusted' host.

So the questions around this are --
1. Is the scenario of an untrusted IaaS deployment considered for Trusted
Compute Pools?

2. Is there any work ongoing to extend Trusted Compute Polls for storage as
well? Or otherwise
put, what about the storage, is the solution to encrypt all data on the
compute host prior to
storing it in the object store?

3. Is there any work ongoing on the evaluation side, namely the evaluation
of the trust attributes
obtained from the host -- and do Trusted Compute Pools consider a binary
value (trusted/untrusted)
or a scale of security profiles?

Cheers,
/Nico.



On 6 November 2012 19:07, Dugger, Donald D wrote:

>  Nico-
>
> ** **
>
> This is the appropriate place for discussions about Trusted Compute Pools
> under OpenStack.  Feel free to send out any ideas you have, I know I and
> others would be very interested in what you have.
>
> ** **
>
> --
>
> Don Dugger
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>
> Ph: 303/443-3786
>
> ** **
>
> *From:* 
> openstack-bounces+donald.d.dugger=intel@lists.launchpad.net[mailto:
> openstack-bounces+donald.d.dugger=intel@lists.launchpad.net] *On
> Behalf Of *Nicolae Paladi
> *Sent:* Tuesday, November 06, 2012 8:35 AM
> *To:* openstack
> *Subject:* [Openstack] Plans for Trusted Computing in OpenStack
>
> ** **
>
> Hi, 
>
> ** **
>
> I am involved in a project that aims to use TPM modules to ensure that
>
> the compute nodes run a 'trusted' software stack in a public IaaS
> deployment.
>
> ** **
>
> I've read about trusted computing pools (
> http://wiki.openstack.org/TrustedComputingPools)
>
> checked out the OpenAttestation project and seen a presentation from the
> OpenStack
>
> summit (Putting Trust in 
> OpenStack)
> in order to get a better understading of where
>
> OpenStack is heading towards wrt TPM support.
>
> ** **
>
> Are there any more resources, discussions, mailing lists that I could
> check out and
>
> where I could potentially bounce ideas?
>
> ** **
>
> Cheers, 
>
> /Nico.
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Choe, Cheng-Dae]

- DNAT rule to metadata server is done by l3_agent. but your node configuration 
has no l3_agent
- and metadata_ip configuration can find l3_agent.ini.

2012. 11. 7., 오후 9:15, Sina Sadeghi  작성:

> Hello all,
> 
> I thought I would give quantum a shot and I've got a 50-60% working 
> configuration, but having trouble understanding where to go from here as the 
> docs are pretty sparse.
> 
> Ubuntu 12.04.1 + "ubuntu cloud archive" folsom repo
> 
> node A: nova-api, nova-scheduler, quantum-server, quantum-plugin-openvswitch
> node B: nova-compute, nova-api-metadata, quantum-dhcp-agent, 
> quantum-plugin-openvswitch-agent
> node C: nova-compute, nova-api-metadata, quantum-dhcp-agent, 
> quantum-plugin-openvswitch-agent
> 
> configured as follows:
> 
> quantum.conf:
> ...
> core_plugin = 
> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
> ...
> 
> ovs_quantum_plugin.ini:
> ...
> tenant_network_type=vlan
> network_vlan_ranges = default:2000:3999
> integration_bridge = br-int
> bridge_mappings = default:br-eth3
> ...
> 
> node B,C `ovs-vstl list-br`:
> br-eth3
> br-int
> 
> node B,C `ovs-vsctl list-ports br-int`:
> int-br-eth3 (created by quantum?)
> 
> node B,C `ovs-vsctl list-ports br-eth3`:
> eth3 (added by me)
> phy-br-eth3 (created by quantum?)
> 
> eth3 is a NIC which is connected to a switchport accepting VLAN 2000:3999. It 
> has no IP assigned currently.
> 
> When I start the 12.04 ubuntu "cloud-image" in the dashboard, it successfully 
> boots and obtains an IP address as seen in the console output:
> cloud-init-nonet waiting 120 seconds for a network device.
> 
> ci-info: lo: 1 127.0.0.1   255.0.0.0   .
> ci-info: eth0  : 1 192.168.253.5   255.255.255.0   fa:16:3e:80:33:71
> ci-info: route-0: 0.0.0.0 192.168.253.1   0.0.0.0 eth0   UG
> ci-info: route-1: 192.168.253.0   0.0.0.0 255.255.255.0   eth0   U
> 
> However, immediately after that output I see this
> 
> 2012-11-07 11:27:29,598 - util.py[WARNING]: 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: 
> url   error [[Errno 
> 113] No route to host]
> 
> which runs until it times out.
> 
> In older versions of OpenStack, when I ran 'iptables-save | grep 
> 169.254.169.254' on a metadata server I was used to seeing a rule show up 
> which translated that 169 address to the variable assigned by metadata_host 
> in nova.conf, but I note that rule doesn't show up in this version of nova? I 
> added the old rule in (to see what would happen) but the result was the same, 
> still no route to host.
> 
> What steps do I need to take here to allow my instance to retrieve its 
> metadata? Is my quantum misconfigured somehow? Perhaps I need to go back and 
> reconfigure my switch port (for example, there is no real 192.168.253.1 gw, 
> but does there need to be for the instance to simply fetch metdata)? After 
> that, what steps do I need to take to get the VM connected to the rest of the 
> world? Is the quantum-l3-agent the only real choice right now?
> 
> Thx.
> 
> -- 
> 
> --
> Sina Sadeghi
> Lead Cloud Engineer
> 
> Aptira Pty Ltd
> 1800 APTIRA
> aptira.com
> Follow @aptira
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [ceilometer] Potential New Use Cases

[Dan Dyer]

Yes, I see a general need to be able to represent meta data the 
identifies associations between monitored systems and between usage 
stored in the datastore. There could be a variety of ways that we need 
to relate event data, so the mechanism should be relatively generic. In 
addition to your use case, we would want to be able to map instances to 
other tenants, group VM's together to represent some kind of shared 
identity or behavior, map instances to some kind of special service 
type. I think there are big advantages to keeping the collection and 
storage of this data separate:

1. It does not require Nova to be aware of the details of the VM internals.
2.It allows for deferral of processing until later in the rating 
process, which helps on scalability
3. makes it easier to extract and report on this data for other use 
cases besides the base billing
4. it more extensible in the sense that you can add arbitrary metadata 
without affecting the core usage data generation.


We use this information as part of our rating process to determine the 
correct charges to apply, so we will need to be able to query for it.


Dan

On 11/5/2012 5:04 AM, Doug Hellmann wrote:



On Fri, Nov 2, 2012 at 4:42 PM, Dan Dyer > wrote:


Yes, I am assuming the service controller provides a different
stream of data from the lower level VM events. So the question is
how to represent and store this additional meta data in
ceilometer. Note that there doesn't necessarily need to be a
linkage/grouping between the resources since the association is
what is actually contained in the metadata that is provided by the
service controller.

As a summary
Nova provides its normal events for usage
Service controller provides a mapping of nova instances to service
type and actual end user


So the problem isn't necessarily that you want to measure something 
different, but that the "ownership" in the existing data is not 
"correct" from the perspective of the billing system.


We have a similar issue at DreamHost. Our existing user database has 
account ids that need to be mapped to tenant ids from keystone. Rather 
than putting that information in keystone, or ceilometer, we decided 
to store it in our system and have the DreamHost billing system drive 
the ceilometer API. Does it make sense to do something similar here?


If we definitely want ceilometer to hold the metadata, then I could 
also see adding an API to let an outside system add metadata to a 
resource. That would let the PaaS code, which knows about each VM, 
store extra data that would be returned with the VM metadata when a 
caller visits /resources/.


Would you expect to be able to query using the metadata? For example, 
"provide the total instance hours for all instances with paas_tag=foo"?


Doug



Dan


On 11/1/2012 11:25 AM, Doug Hellmann wrote:



On Thu, Nov 1, 2012 at 10:21 AM, Dan Dyer mailto:dan.dye...@gmail.com>> wrote:

In some cases, the service controller is actually running
inside a VM. It would not have access to the internals of the
VM's. It maintains its metadata separately from the Nova
infrastructure.


It doesn't need internal access to the VM, but something has to
share the metadata with ceilometer (or "join" it to the data
ceilometer has) at some point. If it would be too difficult to
get the data into the events, then it could be done by the app
that uses the ceilometer API to query for usage. For example, the
app that loads data from ceilometer to your real billing system
could be driven by data saved by the service controller in
whatever database it uses.

Doug



DD


On 10/25/2012 2:25 AM, Nick Barcet wrote:

Let's imagine that the service that launch instances can tag the
instance with:
a) a common service identifier (constant)
b) a uuid unique for each "Unit" of the service
such as :

If that tag is passed onto the events which ceilometer stores in its
entirety as meta, I do not see what the difficulty would be for the
rating engine to be able to reconcile the information to handle your 2
use cases.  Am I missing something?

Nick

On 10/25/2012 12:03 AM, Dan Dyer wrote:

I don't think its just a matter of adding more meters or events for a
couple of reasons:
1. In many cases the metadata I am referring to comes from a different
source than the base usage data. Nova is still emitting its normal
events, but we get the service/user mapping from a different source. I
would not characterize this data as usage metrics but more data about
the system relationships.
2. in the multiple VM case, we need to have the relationships specified
so that we can ignore the proper VM's. There has also been talk of
hybrid billing mo

Re: [Openstack] [Moniker][DNSaaS] Reminder: Weekly meeting today @ 18:00 UTC

[Kiall Mac Innes]

Wow - My bad. 4 hours from now, Not 2 hours!

18:00 UTC - Convert to your local time here:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20121107T18


Thanks,
Kiall


On Wed, Nov 7, 2012 at 1:55 PM, Kiall Mac Innes  wrote:

> Hi All,
>
> Just a friendly reminder that Moniker is having it's second weekly IRC
> meeting today and 18:00 UTC[1] in #openstack-meeting. That's 2 hours from
> now.
>
> Since Moniker is a new StackForge project, I'll remind everyone what it
> does!
>
> Moniker provides DNSaaS services for OpenStack:
>
>- REST API for domain/record management
>- Multi-tenant
>- Integrated with Keystone for authentication
>- Framework in place to integrate with Nova and Quantum notifications
>(for auto-generated records)
>- Support for Bind9 out of the box (Refactoring this to be more
>pluggable will be complete in the next few days)
>- .. I've probably missed lot's more off this list!
>
> The agenda has been posted on the OpenStack wiki[2], anyone with an
> interest in DNSaaS is encouraged to attend.
>
>  See you there!
>
> Thanks,
> Kiall
>
> [1]: *http://www.timeanddate.com/worldclock/fixedtime.html?iso=20121107T18
> *
> [2]: http://wiki.openstack.org/Meetings/DNSaaS
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Moniker][DNSaaS] Reminder: Weekly meeting today @ 18:00 UTC

[Kiall Mac Innes]

Hi All,

Just a friendly reminder that Moniker is having it's second weekly IRC
meeting today and 18:00 UTC[1] in #openstack-meeting. That's 2 hours from
now.

Since Moniker is a new StackForge project, I'll remind everyone what it
does!

Moniker provides DNSaaS services for OpenStack:

   - REST API for domain/record management
   - Multi-tenant
   - Integrated with Keystone for authentication
   - Framework in place to integrate with Nova and Quantum notifications
   (for auto-generated records)
   - Support for Bind9 out of the box (Refactoring this to be more
   pluggable will be complete in the next few days)
   - .. I've probably missed lot's more off this list!

The agenda has been posted on the OpenStack wiki[2], anyone with an
interest in DNSaaS is encouraged to attend.

See you there!

Thanks,
Kiall

[1]: *http://www.timeanddate.com/worldclock/fixedtime.html?iso=20121107T18*
[2]: http://wiki.openstack.org/Meetings/DNSaaS
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Can't access Dashboard

[Daniel Oliveira]

My bad. This is the
tutorialI
talked about.


2012/11/7 Daniel Oliveira 

> Hello,
>
> I've been following this tutorial to install openstack on a machine
> running Ubuntu Server 12.04, and on the step regarding installation of
> Horizon, well, there must be something wrong either with the tutorial or
> with the configuration files on my machine. The point is, whenever I try to
> access the GUI via browser, I get a 404, and I have no clue as to where to
> look for the error.
>
> Thanks in advance.
>
> P.S.: I would like to say a special thanks to everybody on this community.
> You have been helping me A LOT. I've learned much from you people.
>
> --
> My best regards,
>
> Daniel Oliveira.
>
>


-- 
My best regards,

Daniel Oliveira.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Can't access Dashboard

[Daniel Oliveira]

Hello,

I've been following this tutorial to install openstack on a machine running
Ubuntu Server 12.04, and on the step regarding installation of Horizon,
well, there must be something wrong either with the tutorial or with the
configuration files on my machine. The point is, whenever I try to access
the GUI via browser, I get a 404, and I have no clue as to where to look
for the error.

Thanks in advance.

P.S.: I would like to say a special thanks to everybody on this community.
You have been helping me A LOT. I've learned much from you people.

-- 
My best regards,

Daniel Oliveira.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack networking failure after server reboot

[Gary Kotton]

On 11/07/2012 11:47 AM, Aniruddha Khadkikar wrote:

Hi Stackers,

We have a small Openstack lab using three servers. The components are
distributed as:
1. Network controller - Quantum L3&  DHCP, L2 agent, Nova, Openvswitch
2. Cloud controller - Quantum server, L2 agent, Nova, Openvswitch,
Dashboard, API, MySQL, Rabbitmq
3. Compute node - Nova, Openvswitch, L2 agent

The network is setup in the following way:
1. Each server has 4 nics. We are using only one public IP and one
private IP for the openstack setup. We have a private switch for
inter-vm communication
2. We are using gre tunnelling and openvswitch
3. br-int is assigned an IP address
4. br-ex is configured for floating IP allocation

Everything works perfectly when we are setting it up from scratch

Each vm is able to get the private IP's assigned and the NAT based
floating IP is also assigned and we are able to SSH into it.
The VM's also get created on all the three hosts.

So we are confident that we have the right configurations in place as
we have fully operational Openstack implementation using gre-tunnels.

In order to test the resilience of the setup, we decided to reboot the
servers to see if everything comes up again. We faced some dependency
of services errors and after server reboot we restarted the services
in the proper order i.e. on cloud controller we have mysql, rabbitmq,
keystone, openvswitch and quantum-server started. This was followed by
starting openvswitch, L3, dhcp and L2 agent. After which we started L2
agents on all the remaining servers and followed by nova. There is
some confusion on how to orchestrate the right order of services. This
could possibly be something we will need to work upon in future.

After this, we have nova working properly i.e. we are able to create
vm's and the pre-existing ones are also started (virsh list also shows
the vm's). ovsctl shows all the interfaces as earlier. However we are
unable to access the vm's. On logging into the vm we do not see any IP
address being assigned as the VM is unable to contact the dhcp server.

The questions that come up are:
* What could change after a reboot that would compromise a running
network configuration?
* Could there be issues with the TAP interfaces created? What is the
best way to troubleshoot such a situation?
* Has anyone seen a similar behaviour and is it specific to when we
use gre-tunnels? Is it then specific to openvswitch which we are
using?
* On reboot of the network controller are any steps required to ensure
that Openstack continues to function properly?


Can you please look in the log files for Quantum and see if there are 
any errors?


There is an open issue with Quantum and QPID after rebooting - the 
Quantum service hangs? On the host for Quantum is you do "netstat -an 
|grep 9696" do you see anything?




The setup has failed twice on reboot. For the second iteration we are
assigning the IP on startup to br-int so that openvswitch does not
give errors.

Regards
Aniruddha

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] nova/quantum/ovs configuration conundrum

[Sina Sadeghi]

  
  
Hello all,
  
  I thought I would give quantum a
  shot and I've got a 50-60% working configuration, but having
trouble understanding where to go from here as the docs
are pretty sparse.
  
  Ubuntu 12.04.1 + "ubuntu cloud
archive" folsom repo
  
  node A: nova-api, nova-scheduler,
quantum-server, quantum-plugin-openvswitch
  node B: nova-compute,
nova-api-metadata, quantum-dhcp-agent, quantum-plugin-openvswitch-agent
node C: nova-compute, nova-api-metadata,
quantum-dhcp-agent,
quantum-plugin-openvswitch-agent
  
  configured as
  follows:
  
  quantum.conf:
...
  core_plugin =
quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
  ...
  
  ovs_quantum_plugin.ini:
  ...
  tenant_network_type=vlan
  network_vlan_ranges
  =
  default:2000:3999
  integration_bridge
  = br-int
  bridge_mappings
  =
  default:br-eth3
  ...
  
  node
  B,C `ovs-vstl
  list-br`:
  br-eth3
  br-int
  
  node
  B,C
  `ovs-vsctl
  list-ports
  br-int`:
  int-br-eth3
  (created by
  quantum?)
  
node
  B,C
  `ovs-vsctl
  list-ports
  br-eth3`:
  eth3
  (added by me)
  phy-br-eth3
  (created by
  quantum?)
  
  eth3
  is a
  NIC which is
  connected to a
  switchport
  accepting
  VLAN
  2000:3999. It
  has no IP
  assigned
  currently.
  
  When I start the
 

Re: [Openstack] OpenNebula and Swift integration

[Javier Fontan]

Thanks for the tips. I'll keep you posted with any advance we make.

On Tue, Nov 6, 2012 at 4:54 PM, Chuck Thier  wrote:
> Hi Javier,
>
> On Tue, Nov 6, 2012 at 5:07 AM, Javier Fontan  wrote:
>> Hello,
>>
>> We recently had interest from some of our enterprise users to use
>> Swift Object Store as the backend for the VM images. I have been
>> researching on a possible integration with OpenNebula but I have some
>> questions.
>>
>> AFAIK Swift is only Object Store and exposes the object through a REST
>> interface. Is there any plan to add block storage support like Ceph so
>> VMs can use the objects directly?
>>
>
> There isn't currently any plans for this.  At one time we considered
> it, but decided that it would not be a good idea to build block
> storage on top of Swift.
>
>> We would love to have the same users and permissions in both
>> OpenNebula and Swift so the management is only done in one place. It
>> seems that the "TempAuth" system is the way to go to perform this
>> authentication. Is it going to be supported in the future or is it
>> going to be dumped in favor of just Keystone?
>>
>
> You should be able to write your own auth middleware that integrates
> swift into the OpenNebula auth system.  Docs are here:
>
> http://docs.openstack.org/developer/swift/development_auth.html
>
> You can also use TempAuth as an example to work from.
>
>> Are the object ACLs stored within Swift? Can I provide the object ACLs
>> from the Auth subsystem (OpenNebula in this case)? I plan to map Swift
>> objects to OpenNebula Images and they already have ACLs in place.
>>
>
> Currently ACLs are at the container level in swift and not at the
> object level.  That said, for your specific use case, I think you
> could implement the image ACLs in your auth middleware, but it has
> been a while since I have looked at that code.
>
> --
> Chuck



-- 
Javier Fontán Muiños
Project Engineer
OpenNebula - The Open Source Toolkit for Data Center Virtualization
www.OpenNebula.org | jfon...@opennebula.org | @OpenNebula

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Openstack networking failure after server reboot

[Aniruddha Khadkikar]

Hi Stackers,

We have a small Openstack lab using three servers. The components are
distributed as:
1. Network controller - Quantum L3 & DHCP, L2 agent, Nova, Openvswitch
2. Cloud controller - Quantum server, L2 agent, Nova, Openvswitch,
Dashboard, API, MySQL, Rabbitmq
3. Compute node - Nova, Openvswitch, L2 agent

The network is setup in the following way:
1. Each server has 4 nics. We are using only one public IP and one
private IP for the openstack setup. We have a private switch for
inter-vm communication
2. We are using gre tunnelling and openvswitch
3. br-int is assigned an IP address
4. br-ex is configured for floating IP allocation

Everything works perfectly when we are setting it up from scratch

Each vm is able to get the private IP's assigned and the NAT based
floating IP is also assigned and we are able to SSH into it.
The VM's also get created on all the three hosts.

So we are confident that we have the right configurations in place as
we have fully operational Openstack implementation using gre-tunnels.

In order to test the resilience of the setup, we decided to reboot the
servers to see if everything comes up again. We faced some dependency
of services errors and after server reboot we restarted the services
in the proper order i.e. on cloud controller we have mysql, rabbitmq,
keystone, openvswitch and quantum-server started. This was followed by
starting openvswitch, L3, dhcp and L2 agent. After which we started L2
agents on all the remaining servers and followed by nova. There is
some confusion on how to orchestrate the right order of services. This
could possibly be something we will need to work upon in future.

After this, we have nova working properly i.e. we are able to create
vm's and the pre-existing ones are also started (virsh list also shows
the vm's). ovsctl shows all the interfaces as earlier. However we are
unable to access the vm's. On logging into the vm we do not see any IP
address being assigned as the VM is unable to contact the dhcp server.

The questions that come up are:
* What could change after a reboot that would compromise a running
network configuration?
* Could there be issues with the TAP interfaces created? What is the
best way to troubleshoot such a situation?
* Has anyone seen a similar behaviour and is it specific to when we
use gre-tunnels? Is it then specific to openvswitch which we are
using?
* On reboot of the network controller are any steps required to ensure
that Openstack continues to function properly?

The setup has failed twice on reboot. For the second iteration we are
assigning the IP on startup to br-int so that openvswitch does not
give errors.

Regards
Aniruddha

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp