Re: [Openstack-operators] Cloud Upgrade Strategies

[Yuriy Brodskiy]

Database only needed for control operations. During upgrade we disable API 
(mark down on LB or take them down). This will prevent users from making any 
database changes. 
After that flow is "simple"- backup db - do a migration- perform your 
validation tests
If all good, bring up your api, if not, restore db backup to rollback 
I'm over simplifying it here but this is basic concepts. You will find more 
details in the video 






On Wed, Mar 9, 2016 at 10:38 PM -0800, "Xav Paice"  wrote:












On 10 March 2016 at 19:26, Yuriy Brodskiy  wrote:
building a new cloud is not practical for real production environments. even if 
you can afford it, how do you migrate data?
We have been doing upgrades for a while now, and came up with few basic 
principles:1) you don't have to upgrade all at the same time. do it component 
at the time2) stand up a new version along side of an existing one, test it and 
then flip DNS
Take a look at presentation team did during Vancouver summit 
https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/10-minutes-openstack-upgrades-done

(replying to the list this time, and regretting using gmail)
I readily admit to not having watched that video (but will!) - one question.  
How do you deal with the db migration if you have two versions running at the 
same time?







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

Re: [Openstack-operators] Cloud Upgrade Strategies

[Xav Paice]

On 10 March 2016 at 19:26, Yuriy Brodskiy  wrote:

> building a new cloud is not practical for real production environments.
> even if you can afford it, how do you migrate data?
>
> We have been doing upgrades for a while now, and came up with few basic
> principles:
> 1) you don't have to upgrade all at the same time. do it component at the
> time
> 2) stand up a new version along side of an existing one, test it and then
> flip DNS
>
> Take a look at presentation team did during Vancouver summit
>
> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/10-minutes-openstack-upgrades-done
>
>
(replying to the list this time, and regretting using gmail)

I readily admit to not having watched that video (but will!) - one
question.  How do you deal with the db migration if you have two versions
running at the same time?

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

Re: [Openstack-operators] Cloud Upgrade Strategies

[Yuriy Brodskiy]

building a new cloud is not practical for real production environments.
even if you can afford it, how do you migrate data?

We have been doing upgrades for a while now, and came up with few basic
principles:
1) you don't have to upgrade all at the same time. do it component at the
time
2) stand up a new version along side of an existing one, test it and then
flip DNS

Take a look at presentation team did during Vancouver summit
https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/10-minutes-openstack-upgrades-done

On Sun, Mar 6, 2016 at 5:41 PM, Kavit Munshi  wrote:

> Shameless plug :)
>
> For people currently running a distro but wanting to run CI, please
> checkout StackBuffet (https://aptira.com/stackbuffet/)
>
> Currently under beta, looking for customers with real use cases to help us
> test
>
> regards,
>
> Kavit
>
> *Kavit Munshi*
>
> *Aptira - Asia Pacific’s leading provider of OpenStack*
>
> Direct/mobile: +91 971 292 9850
>
> General enquiries: +61 2 8030 2333
>
> Australia toll free: 1800 APTIRA
>
> Website aptira.com
>
> Twitter @aptira 
>
>
> On 4 March 2016 at 04:34, Robert Starmer  wrote:
>
>> I have to agree, unless you start with CI/CD as your deployment model,
>> you're going to be doing full upgrades.  And be aware that at least one
>> package model will overwrite your carefully crafted config files if you
>> choose the wrong option.  Having tried an upgrade to a system in the middle
>> of an upstream update, I can say that this is potentially a painful few
>> hours tracking down what's changed, and where my config files got tweaked
>> (yes, I'm looking at you Keystone...).  Fun for all ages.
>>
>> And while I agree that it is difficult to stand up two clouds, you can
>> stand up a smaller  new cloud, migrate those workloads that are cloud
>> native (just heard your cattle that-a-way), and as the load increases,
>> migrate the hardware from one cloud to another.  It's almost a square
>> dance, and it's never perfect, but it is doable...
>>
>> On Wed, Mar 2, 2016 at 2:58 PM, Silence Dogood 
>> wrote:
>>
>>>
>>>- In-place Full Release upgrades (upgrade an entire cloud from
>>>Icehouse to Kilo for instance)
>>>
>>> This tends to be the most likely scenario with CI/CD being almost
>>> impossible for anyone using supported openstack components ( such as SDN /
>>> NAS / other hardware integration pieces ).
>>>
>>> That's not to say people don't almost always test on a test environment
>>> ( other cloud ) first.
>>>
>>> On Wed, Mar 2, 2016 at 4:34 PM, Adam Lawson  wrote:
>>>
 Hey all,

 So I've been discussing cloud design with the team and of course the
 topic comes up about how upgrades will be handled.

 Handling OpenStack code updates generally consists of three paths in my
 experience:

- CI/CD (continuous incremental upgrades)
- In-place Full Release upgrades (upgrade an entire cloud from
Icehouse to Kilo for instance)
- Migrating old cloud to new cloud

 Is there a cloud maintenance strategy I'm missing that doesn't fall
 into the categories above? How are the rest of you adopting your cloud
 upgrade strategies and how has cloud size impacted whatever strategy you
 ultimately selected? Migrating workloads from an Icehouse cloud with 1000
 nodes to a Liberty cloud with similar capacity isn't always a realistic
 option due to cost, upgrading a cloud in place is super-risky and CI/CD
 takes a lot of development and testing overhead.

 For CI/CD strategies, I'm also curious how the rest of you are handling
 disruptive tasks (for example replacing a vRouter with a newer version,
 updating the SQL schema etc etc)? Just looking to learn from everyone's
 experiences to hopefully keep my own thinking on where it needs to be.

 Thanks!!!

 //adam

 *Adam Lawson*

 AQORN, Inc.
 427 North Tatnall Street
 Ste. 58461
 Wilmington, Delaware 19801-2230
 Toll-free: (844) 4-AQORN-NOW ext. 101
 International: +1 302-387-4660
 Direct: +1 916-246-2072

 ___
 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
>>>
>>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> ___
> OpenStack-operators mailing list
> 

Re: [Openstack-operators] What are you excited for in Mitaka?

[Marcus Furlong]

On 10 March 2016 at 16:33, Matt Kassawara  wrote:
> Don't forget about fixing MTU in neutron. No more confusing options that
> don't really do anything.

Does this mean we can modify the MTU via the API now?

-- 
Marcus Furlong

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

Re: [Openstack-operators] What are you excited for in Mitaka?

[Edgar Magana]

I really like the MTU one! That was a good hit!

Edgar

From: Matt Kassawara >
Date: Wednesday, March 9, 2016 at 9:33 PM
To: Matt Jarvis 
>
Cc: OpenStack Operators 
>
Subject: Re: [Openstack-operators] What are you excited for in Mitaka?

Don't forget about fixing MTU in neutron. No more confusing options that don't 
really do anything.

On Tue, Mar 8, 2016 at 12:12 PM, Matt Jarvis 
> wrote:
We've just patched in https://review.openstack.org/#/c/262740/ on Kilo.

On 8 March 2016 at 17:33, Jesse Keating 
> wrote:
Perhaps I was confused by the wording I found at 
http://docs.openstack.org/liberty/networking-guide/migration-classic-to-l3ha.html

I was looking for a way to do it on Kilo :(
-jlk


- Original message -
From: "Clayton O'Neill" >
To: Jesse Keating/Seattle/IBM@IBMUS
Cc: 
openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] What are you excited for in Mitaka?
Date: Tue, Mar 8, 2016 8:31 AM

On Tue, Mar 8, 2016 at 11:15 AM, Jesse Keating 
> wrote:
> I found one. In Mitaka Neutron you can take an existing router and turn it
> into a HA router. That will make it quite easy to transition older
> environments into a more stable configuration. Previously we'd have to tear
> down the router and build a new one, then re-attach all the interfaces.

You can do this on Liberty also, assuming you have Neutron 7.0.3.  It
does require taking the router offline, but it doesn’t require
delete/recreate.  Can Mitaka do this online?




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



DataCentred Limited registered in England and Wales no. 05611763
___
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] What are you excited for in Mitaka?

[Matt Kassawara]

Don't forget about fixing MTU in neutron. No more confusing options that
don't really do anything.

On Tue, Mar 8, 2016 at 12:12 PM, Matt Jarvis 
wrote:

> We've just patched in https://review.openstack.org/#/c/262740/ on Kilo.
>
> On 8 March 2016 at 17:33, Jesse Keating  wrote:
>
>> Perhaps I was confused by the wording I found at
>> http://docs.openstack.org/liberty/networking-guide/migration-classic-to-l3ha.html
>>
>> I was looking for a way to do it on Kilo :(
>> -jlk
>>
>>
>>
>> - Original message -
>> From: "Clayton O'Neill" 
>> To: Jesse Keating/Seattle/IBM@IBMUS
>> Cc: openstack-operators@lists.openstack.org
>> Subject: Re: [Openstack-operators] What are you excited for in Mitaka?
>> Date: Tue, Mar 8, 2016 8:31 AM
>>
>> On Tue, Mar 8, 2016 at 11:15 AM, Jesse Keating  wrote:
>> > I found one. In Mitaka Neutron you can take an existing router and turn
>> it
>> > into a HA router. That will make it quite easy to transition older
>> > environments into a more stable configuration. Previously we'd have to
>> tear
>> > down the router and build a new one, then re-attach all the interfaces.
>>
>> You can do this on Liberty also, assuming you have Neutron 7.0.3.  It
>> does require taking the router offline, but it doesn’t require
>> delete/recreate.  Can Mitaka do this online?
>>
>>
>>
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> DataCentred Limited registered in England and Wales no. 05611763
> ___
> 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

[Openstack-operators] [app-catalog] IRC Meeting Thursday March 10th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for March 10th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing everyone there tomorrow!

-Christopher

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

Re: [Openstack-operators] [openstack-operators][neutron] use-case for multiple routers within a tenant

[Rubab Syed]

That makes perfect sense. Thank you.

On Wed, Mar 9, 2016 at 4:28 AM, Fox, Kevin M  wrote:

> We use them all the time, and openstack in one version actually broke them
> on us. (I wrote and contributed a unit test so it shouldn't happen again.)
>
> Use case:
>
> You have two external networks.
> 1. Internet - One that's directly connected to the internet.
> 2. One that is a private network space and is available to the whole cloud.
>
> Each tenant gets a router on each network (two routers total), defaulting
> to the internet one, and the subnet has a static routing rule to make the
> external private net route to the right neutron router.
>
> The user can then add floating ip's to one or both of the networks making
> the vm available on that network. If the service is internet facing, they
> can just put that type of floating ip on. If they want to share it with the
> other tenants but not with the internet, they just put that type of
> floating ip on.
>
> We don't have many ip's on the internet side, so having it split like this
> allows us to conserve ip's.
>
> Make sense?
>
> Thanks,
> Kevin
>
> --
> *From:* Rubab Syed [rubab.sye...@gmail.com]
> *Sent:* Tuesday, March 08, 2016 2:20 PM
> *To:* openstack-operators@lists.openstack.org
> *Subject:* [Openstack-operators] [openstack-operators][neutron] use-case
> for multiple routers within a tenant
>
> Hi all,
>
> I am trying to get a general understanding of OpenStack networking. Can
> someone please point out a simple use-case for using multiple routers
> within same tenant?
>
>
> Thanks,
> Rubab
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Liberty Setup - Can't ping Demo Router

[Christopher Hull]

Hi all;
Following the Neutron (Network Option 2 setup) instructions in Liberty.  I
can't ping my demo router.  However, I do recall there are new security
constraints that might prevent this in Liberty.   Do I need to somehow
allow ICMP?

Here's what I did.



===
Create virtual networks
http://docs.openstack.org/liberty/install-guide-rdo/launch-instance.html#create-virtual-networks

===
Create Public Provider Network

http://docs.openstack.org/liberty/install-guide-rdo/launch-instance-networks-public.html


[root@maersk src]# source admin-openrc.sh
[root@maersk src]# neutron net-create public --shared
--provider:physical_network public \
>   --provider:network_type flat
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| be6e920a-51aa-4293-bb95-7ac38aab9df6 |
| mtu   | 0|
| name  | public   |
| port_security_enabled | True |
| provider:network_type | flat |
| provider:physical_network | public   |
| provider:segmentation_id  |  |
| router:external   | False|
| shared| True |
| status| ACTIVE   |
| subnets   |  |
| tenant_id | fdf3f98a9b0c4e9e94603d8a84ea41a8 |
+---+--+
[root@maersk src]#




--- Create a subnet on the network:

Replace START_IP_ADDRESS and END_IP_ADDRESS with the first and last IP
address of the range within
the subnet that you want to allocate for instances. This range must not
include any
existing active IP addresses.

Example
neutron subnet-create public 203.0.113.0/24 --name public \
  --allocation-pool start=203.0.113.101,end=203.0.113.200 \
  --dns-nameserver 8.8.4.4 --gateway 203.0.113.1

[root@maersk src]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
search attlocal.net
nameserver 172.22.10.254

cat ifcfg-enp3s0
GATEWAY=172.22.10.254
DNS1=172.22.10.254

neutron subnet-create public 172.22.10.0/24 --name public \
   --allocation-pool start=172.22.10.10,end=172.22.10.90 \
   --dns-nameserver 172.22.10.254 --gateway 172.22.10.254

Created a new subnet:
+---+--+
| Field | Value|
+---+--+
| allocation_pools  | {"start": "172.22.10.10", "end": "172.22.10.90"} |
| cidr  | 172.22.10.0/24   |
| dns_nameservers   | 172.22.10.254|
| enable_dhcp   | True |
| gateway_ip| 172.22.10.254|
| host_routes   |  |
| id| f227734a-eca3-4472-81f6-620e1bf1fac9 |
| ip_version| 4|
| ipv6_address_mode |  |
| ipv6_ra_mode  |  |
| name  | public   |
| network_id| be6e920a-51aa-4293-bb95-7ac38aab9df6 |
| subnetpool_id |  |
| tenant_id | fdf3f98a9b0c4e9e94603d8a84ea41a8 |
+---+--+

===
Create the private project network
http://docs.openstack.org/liberty/install-guide-rdo/launch-instance-networks-private.html


source demo-openrc.sh

neutron net-create private
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| 28ca326a-8443-4c1c-b288-48920a1eefbe |
| mtu   | 0|
| name  | private  |
| port_security_enabled | True |
| router:external   | False|
| shared| False  

[Openstack-operators] [nfv][telco] Telco Working Group meeting for Wednesday Marcch 16th CANCELLED

[Steve Gordon]

Hi all,

There will be no Telco Working Group [1] meeting for Wednesday March 16th as we 
will be lacking a chair.

Thanks,

Steve

[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup

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