[Openstack-operators] [nova] Should we add the 'force' option to the cold migrate API too?

[Matt Riedemann]

Given the recent bugs [1][2] due to the force flag in the live migrate 
and evacuate APIs related to Placement, and some other long standing 
bugs about bypassing the scheduler [3], I don't think we should add the 
force option to the cold migrate API, as (re-)proposed in Takashi's cold 
migrate spec here [4].


I'm fine with being able to specify a host during cold migrate/resize, 
but I think the specified host should be validated by the scheduler (and 
placement) so that the instance can actually move to that specified 
destination host.


Since we've built more logic into the scheduler in Pike for integration 
with Placement, bypassing that gets us into maintenance issues with 
having to duplicate code throughout conductor and just in general, seems 
like a bad idea to force a host and bypass the scheduler and potentially 
break the instance. Not to mention the complicated logic of passing the 
host through from the API to conductor to the scheduler is it's own 
maintenance problem [5].


Looking back at when the force flag was added to the APIs, it was from 
this spec [6]. Reading that, before that microversion if a host was 
specified we'd bypass the scheduler, so the force flag was really just 
there for backward compatibility I guess in case you wanted the option 
to break the instance or your deployment. :) Otherwise after that 
microversion if you specify a host but not the force flag, then we 
validate the specified host via the scheduler first. Given this, and the 
fact we don't have any backward compatibility to maintain with 
specifying a host for cold migrate, I don't think we need to add a force 
flag for it, unless people really love that option on the live migrate 
and evacuate APIs, but it just seems overly dangerous to me.


Finally, if one is going to make the argument, "but this would be 
consistent with the live migrate and evacuate APIs", I can also point 
out that we don't allow you to specify a host (forced or not) during 
unshelve of a shelved offloaded instance - which is basically a move 
(new build on a new host chosen by the scheduler). I'm not advocating 
that we make unshelve more complicated though, because that's already 
broken in several known ways [7][8][9].


[1] https://bugs.launchpad.net/nova/+bug/1712008
[2] https://bugs.launchpad.net/nova/+bug/1713786
[3] https://bugs.launchpad.net/nova/+bug/1427772
[4] https://review.openstack.org/#/c/489031/
[5] 
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121342.html
[6] 
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/check-destination-on-migrations.html

[7] https://bugs.launchpad.net/nova/+bug/1675791
[8] https://bugs.launchpad.net/nova/+bug/1627694
[9] https://bugs.launchpad.net/nova/+bug/1547142

--

Thanks,

Matt

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

Re: [Openstack-operators] Case studies on Openstack HA architecture

[Curtis]

On Mon, Aug 28, 2017 at 6:24 PM, Imtiaz Chowdhury
 wrote:
> Thanks Curtis, Robert, David and Mohammed for your responses.
>
> As a follow up question, do you use any deployment automation tools for 
> setting up the HA control plane? I can see the value of deploying each 
> service in separate virtual environment or containers but automating such 
> deployment requires developing some new tools. Openstack-ansible is one 
> potential deployment tool that I am aware of but that had limited support 
> CentOS.
>

I think it's safe to say that all "distros" and "installers" for
openstack will converge on using containers of some kind. As to what
and how that is actually done, there are a lot of opinions, and I
think you would have to perform your own due diligence around what
makes sense to you in terms of technologies and implementations. I
don't think there is a right answer. :)

To me it seems to be boiling down to: 1) Kubernetes is overkill (and
use something simpler) or 2) If you don't use Kubernetes then you will
just end up building it yourself [1]. I don't think it's actually that
simple, but those are the talking points.

I think, as has been mentioned in this thread so far, the major
opensource openstack "installers" or "managers" (?) are
openstack-ansible, kolla, tripleo, and now openstack-helm. Not sure if
I'm missing any, sorry if I did.

Frankly I find this all pretty interesting. :)

Thanks,
Curtis.

[1]: http://blog.reactiveops.com/is-kubernetes-overkill


> Imtiaz
>
> On 8/28/17, 2:23 PM, "Curtis"  wrote:
>
> On Fri, Aug 25, 2017 at 6:11 PM, Imtiaz Chowdhury
>  wrote:
> > Hi Openstack operators,
> >
> >
> >
> > Most Openstack HA deployment use 3 node database cluster, 3 node 
> rabbitMQ
> > cluster and 3 Controllers. I am wondering whether there are any studies 
> done
> > that show the pros and cons of co-locating database and messaging 
> service
> > with the Openstack control services.  In other words, I am very 
> interested
> > in learning about advantages and disadvantages, in terms of ease of
> > deployment, upgrade and overall API performance, of having 3 all-in-one
> > Openstack controller over a more distributed deployment model.
>
> I'm not aware of any actual case studies, but this is the (current)
> default model for tripleo and its downstream product, so there would
> be a lot of deployments like this out there in the wild. In the
> default deployment everything but compute is on these 3 nodes running
> on the physical OS.
>
> Do you mean 3 physical servers with everything running on the physical OS?
>
> My opinion is that 3 physical nodes to run all the control plane
> services is quite common, but in custom deployments I either run vms
> and containers on those or just containers. I'd use at least lxc to
> segregate services into their own containers.
>
> I would also suggest that using those same physical servers as
> north/south "network nodes" (which you probably don't have as I
> believe workday is a big opencontrail user) or hosts for stateful
> metric systems (ie. mongodb) can cause issues performance wise, but
> co-located mysql/galera and rabbit on the same nodes as the rest of
> the openstack control plane hasn't been a problem for me yet, but with
> containers I could split them out fairly easily if needed.
>
> Thanks,
> Curtis.
>
> >
> >
> >
> > References to any work done in this area will be highly appreciated.
> >
> >
> >
> > Thanks,
> > Imtiaz
> >
> >
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwIBaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=FzzkP-wZtxwR_lHv11gV2RDLNwSuEtI-Ttdh3mloOUA=byM_0ToLQ8JCji20rvyQJYr-Zm4pHsZ5TK4CFkuZbbk=mLtaaDedoNufBf-kCreLrdZ-McNRAuuesR3xWIT76Vc=
> >
>
>
>
> --
> Blog: serverascode.com
>
>



-- 
Blog: serverascode.com

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

[Openstack-operators] Multi-segment routed provider networks...

[Chris Marino]

Hello operators, a few weeks back I posted here on this list

info
about a Meetup where I spoke about the work we were doing for routed
provider networks [slides
,
video ].

Since then we've released updates to Romana to support multi-segment,
routed networks on top of standard flat or VLAN provider networks
configured by Neutrion.

We're working with some operators that are moving to an L3 spine/leaf
network design and want to launch VMs on any of the configured L3 networks.
Romana takes care of IPAM, route advertisement and microsegmentation so
that they can take their old (L2 VLAN) CIDRs and deploy them as
multi-segment routed L3 provider networks.

For example, if they previously ran four VLAN provider networks with /20
CIDRs. As trunked VLANs, a VM could be launched on any network. on any
host. No problem.  These new L3 provider networks will let them use the
same CIDRs and still let Nova launch VMs on any (isolated) CIDR, on any
host, without wasting IPs.  Traffic between the CIDRs can be steered
through an upstream device, just like a VLAN.

To be clear, these deployments do not use Neutron's experimental routed
provider network features. They simply run multiple L3 segments on a
standard Neutron (L2) provider network configured using the flat or VLAN
ML2 type driver.

There is still more work to do, but if anyone is interested in how all this
works, we've set up a demo cluster where you can launch VMs, and see how
things get configured. Send me an email if you want an account. Happy to
set you up.

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