Open Stack

On Tue, Feb 6, 2018 at 6:03 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> Goutham, comments inline...
>
> Also, FYI, using HTML email with different color fonts to indicate
> different people talking is not particularly mailing list-friendly. For
> reasons why, just check out your last post:
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-Janu
> ary/126842.html
>
> You can't tell who is saying what in the mailing list post...
>
> Much better to use non-HTML email and demarcate responses with the
> traditional > marker. :)
>
> OK, comments inline below.
>
> On 01/31/2018 01:17 PM, Goutham Pratapa wrote:
>
>> Hi Jay,
>>
>> Thanks for the questions.. :)
>>
>> What precisely do you mean by "resources" above ??
>>
>> Resources as-in resources required to boot-up a vm (Keypair, Image,
>> Flavors )
>>
>
> Gotcha. Thanks for the answer.
>
> Also, by "syncing", do you mean "replicating"? The reason I ask is because
>> in the case of, say, VM "resources", you can't "sync" a VM across regions.
>> You can replicate its bootable image, but you can't "sync" a VM's state
>> across multiple OpenStack deployments.
>>
>> Yes as you said syncing as-in replicating only.
>>
>
> Gotcha. You could, of course, actually use synchronous (or semi-sync)
> replication for various databases, including Glance and Keystone's
> identity/assignment information, but yes, async replication is just as good.
>
> and yes we cannot sync vm's across regions but our idea is to
>> sync/replicate all the parameters required to boot a vm
>>
>
> OK, sounds good.
>
> (viz. *image, keypair, flavor*) which are originally there in the source
>> region to the target regions in a single-go.
>>
>
> Gotcha.
>
> Some questions on scope that piqued my interest while reading your
> response...
>
> Is Kingbird predominantly designed to be the multi-region orchestrator for
> OpenStack deployments that are all owned/operated by the same deployer? Or
> does Kingbird have intentions of providing glue services between multiple
> fully-independent OpenStack deployments (possibly operated by different
> deployers)?
>
> Further, does Kingbird intend to get into the multi-cloud (as in AWS,
> OpenStack, Azure, etc) orchestration game?
>>
>>  > For now Kingbird is designed for openstack  deployments that are all
>> owned by the same deployer and yes we would like to get into multi-cloud
>> orchestration dont know how ?? But the idea is there. (If you can please
>> guide us then may be we can acheive this :) )
>
> > We have to see how far we can adhere between different
>> multiple-openstack deployments
>
> I'm curious what you mean by "resource management". Could you elaborate a
>> bit on this?
>>
>> Resource management as-in managing the resources i.e say a user has a
>> glance image(*qcow2 or ami format*) or
>> say flavor(*works only if admin*) with some properties or keypair present
>> in one source regionand he wants the same image or
>> same flavor with same properties or the same keypair in another set of
>> regions user may have to recreate them in all target regions.
>>
>> But with the help of kingbird you can do all the operations in a single
>> go.
>>
>> --> If user wants to sync a resource of type keypair he can replicate the
>> keypair into multiple target regions in single go (similarly glance images
>> and flavors )
>> --> If user wants different type of resource( keypair,image and flavor)
>> in a single go then user can  give a yaml file as input and kingbird
>> replicates all resources in all target regions
>>
>
> OK, I understand your use case here, thanks.
>
> It does seem to me, however, that if the intention is *not* to get into
> the multi-cloud orchestration game, that a simpler solution to this
> multi-region OpenStack deployment use case would be to simply have a global
> Glance and Keystone infrastructure that can seamlessly scale to multiple
> regions.

> Frankly we never tried this. we will have to try this.
>
> That way, there'd be no need for replicating anything.
>
> I suppose what I'm recommending it that instead of the concept of a region
> (or availability zone in Nova for that matter) being a mostly-configuration
> option thing, that the OpenStack contributor community actually work to
> make regions (the concept that Keystone labels a region; which is just a
> grouping of service endpoints) the one and only concept of a user-facing
> "partition" throughout OpenStack.
>
> That way we would have OpenStack services like Glance, Nova, Cinder,
> Neutron, etc just *natively* understand which region they are in and how/if
> they can communicate with other regions.
>
> Sometimes it seems we (as a community) go through lots of hoops working
> around fundamental architectural problems in OpenStack instead of just
> fixing those problems to begin with. See: Nova cellsv1 (and some of
> cellsv2), Keystone federation, the lack of a real availability zone concept
> anywhere, Nova shelve/unshelve (partly developed because VMs and IPs were
> too closely coupled at the time), the list goes on and on...
>
> Anyway, mostly just rambling/ranting... just food for thought.
>
> Yes :) thanks for your suggestions and ideas.. this is good way forward
> for our team.
>
> Best,
> -jay
>
> Thanks
>> Goutham.
>>
>>
>> On Wed, Jan 31, 2018 at 9:25 PM, Jay Pipes <jaypipes at gmail.com <mailto:
>> jaypipes at gmail.com>> wrote:
>>
>>     On 01/31/2018 01:49 AM, Goutham Pratapa wrote:
>>
>>         *Kingbird (The Multi Region orchestrator):*
>>
>>         We are proud to announce kingbird is not only a centralized
>>         quota and resource-manager but also a  Multi-region Orchestrator.
>>
>>         *Use-cases covered:
>>
>>         *- Admin can synchronize and periodically balance quotas across
>>         regions and can have a global view of quotas of all the tenants
>>         across regions.
>>         - A user can sync a resource or a group of resources from one
>>         region to other in a single go
>>
>>
>>     What precisely do you mean by "resources" above?
>>
>>     Also, by "syncing", do you mean "replicating"? The reason I ask is
>>     because in the case of, say, VM "resources", you can't "sync" a VM
>>     across regions. You can replicate its bootable image, but you can't
>>     "sync" a VM's state across multiple OpenStack deployments.
>>
>>            A user can sync multiple key-pairs, images, and flavors from
>>         one region to other, ( Flavor can be synced only by admin)
>>
>>         - A user must have complete tempest test-coverage for all the
>>         scenarios/services rendered by kingbird.
>>
>>         - Horizon plugin so that user can access/view global limits.
>>
>>         * Our Road-map:*
>>
>>         -- Automation scripts for kingbird in
>>               -ansible,
>>               -salt
>>               -puppet.
>>         -- Add SSL support to kingbird
>>         -- Resource management in Kingbird-dashboard.
>>
>>
>>     I'm curious what you mean by "resource management". Could you
>>     elaborate a bit on this?
>>
>>     Thanks,
>>     -jay
>>
>>         -- Kingbird in a docker
>>         -- Add Kingbird into Kolla.
>>
>>         We are looking out for*_contributors and ideas_* which can
>>         enhance Kingbird and make kingbird a one-stop solution for all
>>         multi-region problems
>>
>>
>>
>>         *_Stable Branches :_
>>         *
>>         *
>>         Kingbird-server:
>>         https://github.com/openstack/kingbird/tree/stable/queens
>>         <https://github.com/openstack/kingbird/tree/stable/queens>
>>         <https://github.com/openstack/kingbird/tree/stable/queens
>>         <https://github.com/openstack/kingbird/tree/stable/queens>>
>>         *
>>         *Python-Kingbird-client (0.2.1):
>>         https://github.com/openstack/python-kingbirdclient/tree/0.2.1
>>         <https://github.com/openstack/python-kingbirdclient/tree/0.2.1>
>>         <https://github.com/openstack/python-kingbirdclient/tree/0.2.1
>>         <https://github.com/openstack/python-kingbirdclient/tree/0.2.1>>
>>         *
>>
>>         I would like to Thank all the people who have helped us in
>>         achieving this milestone and guided us all throughout this
>>         Journey :)
>>
>>         Thanks
>>         Goutham Pratapa
>>         PTL
>>         OpenStack-Kingbird.
>>
>>
>>
>>         ____________________________________________________________
>> ______________
>>         OpenStack Development Mailing List (not for usage questions)
>>         Unsubscribe:
>>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@lists.openstack.org?subject:un
>> subscribe>
>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> --
>> Cheers !!!
>> Goutham Pratapa
>>
>


-- 
Cheers !!!
Goutham Pratapa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180207/6e7d4254/attachment.html>