Re: [Openstack-operators] Maintenance

This was originated because theTelco requirements I have described there. The implementation will reside in the OpenStack. So we are looking the problem described, what else operators need and then how to accomplish that. Most probably looking a new tool instead of injecting any existing. Tomi

Re: [Openstack-operators] Maintenance

The overall requirements are being reviewed in https://etherpad.openstack.org/p/AUS-ops-Nova-maint. A future tool may make its way in OSOps but I think we should keep the requirements discussion distinct from the available community tools and their tool repository. Tim From: Joseph Bajin mail

Re: [Openstack-operators] Maintenance

Rob/Jay, The use of the OSOps Working group and its repos is a great way to address this.. If any of you are coming to the Summit, please take a look at our Etherpad that we have created.[1] This could be a great discussion topic for the working sessions and we can brainstorm how we could help w

Re: [Openstack-operators] [openstack-dev] Thank you to our Event Planners

On 04/22/2016 05:22 PM, Anita Kuno wrote: I would like to take a moment to say thank you to all the folks in our community who take the time and trouble to plan events for all of us to enjoy. Events of all kinds help us to learn and grow by extending ourselves and learning about different ways of

[Openstack-operators] nova snapshots should dump all RAM to hypervisor disk ?

Hello Operators, one of the users of our cluster opened a ticket about a snapshot corner case. It is not possible to snapshot a instance that is booted from volume when the instance is paused. So I wrote this patch, and from the discussion you can see that I learnt a lot about snapshots. https://r

[Openstack-operators] Thank you to our Event Planners

I would like to take a moment to say thank you to all the folks in our community who take the time and trouble to plan events for all of us to enjoy. Events of all kinds help us to learn and grow by extending ourselves and learning about different ways of doing things. We get to interact with new f

Re: [Openstack-operators] Maintenance

Maybe a result of the discussion can be a set of models (let's not go so far as to call them best pracices yet :) for how maintainance can be done at scale, perhaps solidifying the descriptions Jay has above with the user stories Tomi described in his initial note. This seems like an achievable ou

Re: [Openstack-operators] Maintenance

On 04/14/2016 05:14 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote: As admin I want to know when host is ready to actions to be done by admin during the maintenance. Meaning physical resources are emptied. You are equating "host maintenance mode" with the end result of a call to `nova host-evacua

Re: [Openstack-operators] Neutron DHCP agent local routes

Yes, there is an unfortunate possibility of confusion around the word 'subnet'. To some, that means a network segment, or VLAN, and to some that just means the specific IP subnet. Neutron takes the latter view, and treats multiple subnets as multiple IP ranges on the same VLAN (which Neutron calls

[Openstack-operators] [Fuel][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

[crossposting to openstack-operators@lists.openstack.org] On 04/22/2016 05:42 PM, Bogdan Dobrelya wrote: > [crossposting to openstack-operators@lists.openstack.org] > > Hello. > I wrote this paper [0] to demonstrate an approach how we can leverage a > Jepsen framework for QA/CI/CD pipeline for Op

Re: [Openstack-operators] Neutron DHCP agent local routes

But if the subnets are on the same VLAN it should work. That's what that patch is designed for. There is (currently) an assumption in Neutron that subnets in the same network are on the same L2 segment. So if a VM wants to communicate with a VM in another subnet on the same network, it can cut out

Re: [Openstack-operators] Neutron DHCP agent local routes

Hi Neil, Well that explains... My networking setup does not conform to the commit message in such a way that there are multiple subnets on the network, however the instance does not have an IP address in all of them but only in one. I guess the only option for now is to patch this code, as a worka

Re: [Openstack-operators] Neutron DHCP agent local routes

On 22/04/16 12:03, Remco wrote: > Hi Neil, > > Thanks. > The ip route output is as following, i guess the 0.0.0.0 gateway is only > listed by cloud-init: > > debian@instance:/$ ip route > default via 192.168.10.1 dev eth0 > 192.168.10.0/24 dev eth0 scope link > 169.254.169

Re: [Openstack-operators] Neutron DHCP agent local routes

Hi Neil, Thanks. The ip route output is as following, i guess the 0.0.0.0 gateway is only listed by cloud-init: debian@instance:/$ ip route default via 192.168.10.1 dev eth0 192.168.10.0/24 dev eth0 scope link 169.254.169.254 via 192.168.10.1 dev eth0 192.168.11.0/24 dev eth0 scope link 192.168

Re: [Openstack-operators] Neutron DHCP agent local routes

On 22/04/16 10:59, Remco wrote: > Hi, Hi Remco, > We are running Liberty, with provider networks. We use the Neutron DHCP > agent to configure IPv4 and IPv6 addresses for instances. This is all > working great, however we sometimes need to put multiple subnets on one > VLAN interface (for legacy

[Openstack-operators] Neutron DHCP agent local routes

Hi, We are running Liberty, with provider networks. We use the Neutron DHCP agent to configure IPv4 and IPv6 addresses for instances. This is all working great, however we sometimes need to put multiple subnets on one VLAN interface (for legacy reasons). This is in fact also working, however it co