Re: [Openstack-operators] FAiled to create instance wiht openstack nova network

[matt]

root-wrap failed probably a config error.  might want to post your nova
configs with commenting out of passwords / service tokens.

dnsmasq --strict-order --bind-interfaces --conf-file=
--pid-file=/var/lib/nova/networks/nova-br100.pid
--listen-address=192.168.22.1 --except-interface=lo
--dhcp-range=set:demo-net,192.168.22.2,static,255.255.255.0,120s
--dhcp-lease-max=256
--dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
--domain=novalocal --no-hosts
--addn-hosts=/var/lib/nova/networks/nova-br100.hosts
2015-07-10 15:30:29.753 3044 TRACE oslo.messaging.rpc.dispatcher Exit code: 2

needs to run as root.  exit code 2 is obviously pretty bad.  so that
NEEDs to be fixed.



On Fri, Jul 10, 2015 at 3:25 PM, pra devOPS  wrote:

> All:
>
> I get the following error when trying to create an instance in openstack
> icehouse centOS 7 on nova network.
>
> nova network logs and UI logs are pasted at:
> *http://paste.openstack.org/show/362706/
> *
>
>
>
> Can somebdody give susggestiong?
> Thanks,Siva
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] DB archive deleted rows

[Matt Riedemann]

On 10/2/2014 9:51 AM, Simon McCartney wrote:

We're using the exceptionally crude scripts
here: https://gist.github.com/8b90b0b913df9f679d16
& https://gist.github.com/efbb3b55bffd5bd41a42 (this is on a Grizzly
environment)

if you try the archive script & it fails, it should tell you what record
in what table failed (we had to clean up a few fixed_ip table entries by
hand to clear some dangling FKs)

Simon.
--
Simon McCartney
"If not me, who? If not now, when?"
+447710836915 

On 2 October 2014 at 15:18:32, Belmiro Moreira
(moreira.belmiro.email.li...@gmail.com
) wrote:


Hi,
our nova DBs are growing rapidly and it's time to start pruning them...

I'm trying the "archive deleted rows" however is not working and I'm
getting the following
warning in the logs: "IntegrityError detected when archiving table"
Searching about this problem I found the bug
"https://bugs.launchpad.net/nova/+bug/1183523";
which, if I understood correctly, means this functionality is broken
for a while...

How are other deployments dealing with growing DBs?

thanks,
Belmiro
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



Heh, very timely comment on dangling FKeys in the fixed_ips table, we're 
discussing that in a spec which proposes adding a script in the nova 
tree to do the deleted instance purge work [1].


I didn't have fixed_ips in the whitelist of tables to purge because 
technically when deleting an instance and using nova-network, we should 
be disassociating the instance from the fixed_ip in the database which 
removes the FKey constraint issue, but if there are bugs in that 
teardown path in nova-network and the disassociation didn't happen, but 
the instance is marked as deleted, we'll have problems during archive/purge.


Can you comment on which version of nova you were hitting this issue 
with?  Grizzly?  Is it still an issue?


[1] https://review.openstack.org/#/c/200224/

--

Thanks,

Matt Riedemann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] FAiled to create instance wiht openstack nova network

[pra devOPS]

All:

I get the following error when trying to create an instance in openstack
icehouse centOS 7 on nova network.

nova network logs and UI logs are pasted at:
*http://paste.openstack.org/show/362706/
*



Can somebdody give susggestiong?
Thanks,Siva
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] OpenStack Community Weekly Newsletter (July 3 - 10)

[Nicole Martinelli]

  Seven habits of highly effective OpenStack contributors
  


If you want to be an awesome OpenStack contributor, there’s a formula
for that. So says Adrian Otto,  who
should know. Otto is a distinguished architect at Rackspace, chairman of
the OpenStack containers team,
 current project team
lead (PTL) for Magnum  and
launched the Solum  project back in 2013.


  Ops Mid-Cycle Meetup in Palo Alto, Aug 18-19
  


We finalized the dates and location of the Ops mid-cycle meetup. Due to
timing and the size of our growing event, the best option to accommodate
300 people (if needed) will be Crowne Plaza Hotel
 in Palo Alto, CA, August 18-19, 2015.
Register now

and join the brainstorming to define the agenda.



The Road to Tokyo

  * *IMPORTANT AND TIME SENSITIVE*:Need a visa for the Tokyo Summit?
Here’s what you need to know


  * Interested in being a Tokyo Summit Sponsor?

  * How to craft a successful OpenStack Summit proposal


  * Tips for getting a travel grant to the next OpenStack Summit


  * Accepting presentation submissions until July 15th, 2015, 11:59 pm
PDT 


Reports from Previous Events

  * Third OpenStack CEE Day grows by 35 percent




Relevant Conversations

  * Strategy to port Swift to Python 3

  * [Neutron] Linux Bridge CI status report

  * Thoughts on ReleaseNoteImpact git commit message tag



Deadlines and Contributors Notifications

  * Full list of mid-cycle sprints (meetups)

  * CHANGED TIME AND VENUE: Product WG Liberty Meetup: August 20-21-12,
2015 @Cisco, San Jose, CA



Security Advisories and Notices

  * [OSSN 0049] Nova ironic driver logs sensitive information while
operating in debug mode



Tips ‘n Tricks

  * By Jake Girouard

:
Mirantis Training Blog: User Deletion and User VMs


  * By Gorka Eguileor : Inside Cinder’s
Incremental Backup

  * By Spencer Smith

:
Up and running with Docker Machine and OpenStack


  * By Dan Smith

:
Upgrading Nova to Kilo with minimal downtime


  * By Steve Martinelli

:
Viewing Keystone CADF notifications with Ceilometer and RabbitMQ


  * By Craige McWhirter : How
To Delete a Cinder Snapshot with a Status of error or error_deleting
With Ceph Block Storage




Open Call for Proposals

  * OpenStack Summit Tokyo, open until July 15



Recently Merged Specs

Subject Owner   Project
Change release model to independent releases

Re: [Openstack-operators] OSAD for RHEL

[Kevin Carter]

To be clear the present OSAD project really has no intention to bring package 
based installations of OpenStack. We'd certainly not reject the idea and 
wouldn't mind having an implementation spec for it but all of our current 
tooling and design principles have been based on the fact that we've move away 
from distro packages and on to upstream source as it pertains to OpenStack. The 
system as it stands today creates an internal repository of built wheels for 
your environment and all of the OpenStack services are installed within LXC 
containers, where possible and it makes sense. The installation of these bits 
comes from the internal wheel repository and uses pip and all of the pre / post 
config happens within the Ansible playbooks.


One issue that will become a problem, for users of RedHat specifically, is the 
fact that RedHat has no LXC container templates (at least none that are 
publicly available) and even if someone were to make an official RedHat 
container template there'd be issues with the containers being able to connect 
to the satellite servers as well as other potential license problems.


I've done some experimenting with a RedHat 7.1 hosts and CentOS 7 containers 
and things seem to work OK but I'd not say that I have really put a lot of 
effort into it. That said, if its something that you'd all like to work on I'd 
be happy to help out to make it all go.


--

Kevin Carter

From: Adam Young 
Sent: Thursday, July 9, 2015 11:32 AM
To: Kris G. Lindgren; John Dewey
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] OSAD for RHEL

On 07/09/2015 02:16 AM, Kris G. Lindgren wrote:
Does OSP support running each service in an LXC container as well?  What about 
nova-cells? How does it handle people who need to carry local changes?  What is 
the upgrade path like with OSP?

So, ignoring the Hypervisor for the moment, there is no reason that the rest of 
the controllers can't run in separate Containers.  I think a container based 
deployment would be fantastic.

venv is not really sufficient, as the system level binaries can still conflict 
(MysQL and LDAP both require system libraries for Keystone, for example)

>From an Ansible perspective;  we need to  be able to share the HTTPD instance 
>for Keystone and Apache, and getting that right will solve most of the issues 
>deploying in a secure manner.  Putting Them on separate hosts or containers 
>should be a degenerate case, and thus be supported, too.







Asking, because in Philly the general consensus, I fel,t was people want to 
move away from the current system level package stuff and move towards: venv's, 
"lightweight packages", containers.  The only reason that was brought up to 
keep packages around was to solve the non-python lib stuff and using a 
depsolver (yum/apt) that doesn't suck (pip).  So I am pretty sure my wants are 
inline with what other people in the community are either already doing or 
moving towards.
___

Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.


From: John Dewey mailto:j...@dewey.ws>>
Date: Wednesday, July 8, 2015 at 11:43 PM
To: "Kris G. Lindgren" mailto:klindg...@godaddy.com>>
Cc: Adam Young mailto:ayo...@redhat.com>>, 
"openstack-operators@lists.openstack.org"
 
mailto:openstack-operators@lists.openstack.org>>
Subject: Re: [Openstack-operators] OSAD for RHEL

This would not be acceptable for those running OSP.


On Wednesday, July 8, 2015 at 10:12 PM, Kris G. Lindgren wrote:

I should be more clear. My current thought is to have a venv packaged
inside an rpm - so the rpm includes the needed init scripts, ensures the
required system level binaries are installed, adds the users - ect ect.
But would be a single deployable autonomous unit. Also, have a versioning
schema to roll forward and back between venvs for quick update/rollback.
We are already working on doing something similar to this to run kilo on
cent6 boxen, until we can finish revving the remaining parts of the fleet
to cent7.

My desire is to move away from using system level python & openstack
packages, so that I can possibly run mismatched versions if I need to. We
had a need to run kilo ceilometer and juno neutron/nova on a single
server. The conflicting python requirements between those made that task
impossible. In general I want to get away from treating Openstack as a
single system that everything needs to be upgraded in lock step (packages
force you into this). I want to move to being able to upgrade say
oslo.messaging to a newer version on just say nova on my control plane
servers. Or upgrade nova to kilo while keeping the rest of the system
(neutron) on juno. Unless I run each service in a vm/container or on a
physical piece of hardware that is pretty much impossible to do with
packages - outside of placing everything inside venv's.

However, it is my understanding that OSAD al

Re: [Openstack-operators] Cant ping or SSH Cirros VM #Kilo-Multinode#

[Yuki Nishiwaki]

Hello Abhishek.

I will answer about two problem
 -  controller can’t ping any external network 
 -  vm can’t access internet


First , about the problem controller can’t ping any external network 
>  I am able to boot a VM and it goes to active state but cannot ping it from 
> Controller or any external network.
> 

If you want to ping vm which connected to external network  from controller , 
you need to create nic belong to segment the same as external network in 
controller.

As described  bellow, your controller don’t have the nic belong to external 
network.
> **#Controller Node**
> 
> # The primary network interface - NAT connection
> auto eth0
> iface eth0 inet dhcp
> 
> # vboxnet0 - OpenStack management network
> auto eth1
> iface eth1 inet static
> address 10.0.0.11
> netmask 255.255.255.0

Second, about the problem vm can’t access internet
> Moreover, as per the install guide the VM should be able to ping 
> “openstack.org” to verify ext-net connectivity it is not doing that. The VM 
> is able to ping the tenant router gateway of the external network interface 
> “192.168.56.105”.
> 

the reason of this problem is that your network node don’t routing  or the next 
router of network node don’t know external network ( 192.168.56.0/24 ).

this problem can be solved  by following 
 - Set NAT to NIC belong to segment which can access internet in network node


I’m grad if this information help you.


Yuki Nishiwaki 

2015/07/09 18:38、Abhishek Talwar  のメール：

> HI Folks,
> 
> 
> 
> I have a multinode OpenStack kilo setup with a controller node, network node 
> and 2 compute nodes. I followed all the steps 
> (http://docs.openstack.org/kilo/instal...) given in the OpenStack kilo 
> install guide. I am able to boot a VM and it goes to active state but cannot 
> ping it from Controller or any external network.
> 
> The external network interface (eth3) has a gateway of 192.168.56.105 and we 
> can ping it from any external network.
> 
> I have assigned a floting ip to the VM, and added the icmp and tcp rules to 
> allow the ping and SSH but we can't ping to the VM.
> 
> Moreover, as per the install guide the VM should be able to ping 
> “openstack.org” to verify ext-net connectivity it is not doing that. The VM 
> is able to ping the tenant router gateway of the external network interface 
> “192.168.56.105”.
> 
> How should we proceed further to enable the ping and SSH functionality.
> 
> The setup details are listed as follows:
> 
> 
> 
> 
> **#Controller Node**
> 
> # The primary network interface - NAT connection
> auto eth0
> iface eth0 inet dhcp
> 
> # vboxnet0 - OpenStack management network
> auto eth1
> iface eth1 inet static
> address 10.0.0.11
> netmask 255.255.255.0
> 
> **#Network Node**
> 
> # vboxnet0 - OpenStack management network
> auto eth1
> iface eth1 inet static
> address 10.0.0.21
> netmask 255.255.255.0
> 
> # vboxnet2 - OpenStack data/communication network
> auto eth2
> iface eth2 inet static
> address 10.0.1.21
> netmask 255.255.255.0
> 
> #vboxnet0 - For exposing external network
> auto eth3
> iface eth3 inet manual
> up ip link set dev $IFACE up
> down ip link set dev $IFACE down
> 
> 
> 
> **#Compute Node** 
> 
> # The primary network interface - NAT connection
> auto eth0
> iface eth0 inet dhcp
> 
> # vboxnet0 - OpenStack management network
> auto eth1
> iface eth1 inet static
> address 10.0.0.31
> netmask 255.255.255.0
> 
> # vboxnet2 - OpenStack VM data/communication network
> auto eth2
> iface eth2 inet static
> address 10.0.1.31
> netmask 255.255.255.0
> 
> 
> **#Compute1 Node** 
> 
> # The primary network interface - NAT connection
> auto eth0
> iface eth0 inet dhcp
> 
> # vboxnet0 - OpenStack management network
> auto eth1
> iface eth1 inet static
> address 10.0.0.32
> netmask 255.255.255.0
> 
> # vboxnet2 - OpenStack VM data/communication network
> auto eth2
> iface eth2 inet static
> address 10.0.1.32
> netmask 255.255.255.0
> 
> **#neutron net-list**
> 
> --+ 
> | id   | name  | subnets  
>| 
> +--+---+-+
>  
> | 
> | 6c91a7e8-4182-4fb7-8d42-b83ca6775e57 | ext-net   | 
> c4dac528-3fa9-47db-a5c4-50590ed8edf5| 
> | 314323cd-cbd1-43e9-a5f5-58213a6afdee | demo-net1 | 
> 7412369e-a91f-4228-af55-2792fde85d3d 192.168.1.0/24 | 
> +--+---+-+
>  
> 
> 
> **# neutron floatingip-list**
> -+--+ 
> | id   | fixed_ip_address | 
> floating_ip_address | port_id  | 
> +--+--+-+--+
>  
> | 65872868-6318-4eb3-bce4-6bd8922b90e1 | 192.1

[Openstack-operators] [Large Deployments Team] A few Housekeeping items

[Matt Van Winkle]

Hey folks,
Following our discussions in YVR, and in the last monthly meeting, we have a 
few things related to meetings to work on.

1.   Because the new gerrit based meeting scheuler doesn't handle monthly 
meetings, we made the move in June to #openstack-operators.  This seemed to 
work quite we'll, and unless anyone has any objections, we'll keep it that way 
going forward.

2.  We need to pick and official time for the APAC friendly meeting time on the 
alternating months - January, March, May, July, Sepetember and November.  I've 
set up the following poll for that - http://doodle.com/cpug2c3xypnk5aep

3.  For this month, I posted two options - next Thursday (we normally target 
the 3rd Thursday) or the following since there are 5 Thursdays in July.  I'll 
pick the most popular vote by Monday for this months and the most popular time 
slot between both options for the official time going forward.  I'll make sure 
the later is reflected here - https://wiki.openstack.org/wiki/Meetings/LDT

Overall, things are going quite well.  We are actually seeing an active 
feedback loop that started with our discussion of network segmentation in YVR,  
led to combined LDT and Neutron dev interaction in the last meeting, involved 
gathering use cases following that and ultimately, had members of the LDT form 
GoDaddy in the Neutron mid-cycle.  This is exactly what we wanted to see happen 
with the creation of this team.  Great work all!  A good portion of this 
month's meeting will be getting caught up on where we are with this particular 
feedback loop.

As always, please let me know if you have any questions or concerns.

Thanks!
Matt
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [Openstack] Rescinding the M name decision

[Neil Jerram]

On 10/07/15 10:19, Thierry Carrez wrote:


Part of the confusion here is that we are not naming "releases". We are
naming release *cycles*. We are giving a name to a period of time,
basically. In that period of time, various version numbers for various
components will be released. Saying "Glance 12.0.0 was released in
OpenStack 13 cycle" is not really helping.

We won't run out of letters, because the names can cycle back to A
(potentially using a new theme, away from "geographic features near
where the corresponding design summit happened").

So while we could technically name a release cycle "14", I feel it's a
bit more difficult to rally around a number than a name. Also, numbers
wouldn't really solve the perceived issues with names: numbers happen to
also be culturally meaningful. You don't have a 13th floor in many US
buildings. In China, building miss the 4th floor instead. 9 is feared in
Japan. And don't talk about 39 to Afghans.

I think "growing up" is accepting the pain that comes with picking a
good name, rather than sidestepping the issue.


+1 to all that.  Nicely put.

Neil

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [Openstack] Rescinding the M name decision

[Thierry Carrez]

Adam Lawson wrote:
> The alternative of course is to just number the releases since names
> ultimately don't mean anything but it seems there are problems with that
> level of simplicity. I personally prefer Tristan's suggestion to keep it
> as simple as possible. In a few years we'll run out of letters anyway.

Part of the confusion here is that we are not naming "releases". We are
naming release *cycles*. We are giving a name to a period of time,
basically. In that period of time, various version numbers for various
components will be released. Saying "Glance 12.0.0 was released in
OpenStack 13 cycle" is not really helping.

We won't run out of letters, because the names can cycle back to A
(potentially using a new theme, away from "geographic features near
where the corresponding design summit happened").

So while we could technically name a release cycle "14", I feel it's a
bit more difficult to rally around a number than a name. Also, numbers
wouldn't really solve the perceived issues with names: numbers happen to
also be culturally meaningful. You don't have a 13th floor in many US
buildings. In China, building miss the 4th floor instead. 9 is feared in
Japan. And don't talk about 39 to Afghans.

I think "growing up" is accepting the pain that comes with picking a
good name, rather than sidestepping the issue.

-- 
Thierry Carrez (ttx)

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators