Re: [openstack-dev] [rally] There is no Platform plugin with name: 'existing@openstack'"
Hi Andrey, Thanks it worked. On Thu, Aug 9, 2018 at 3:10 PM, Andrey Kurilin wrote: > Hi Goutham! > > There are 2 issues which can result in such error: > > 1) You did not read change log for Rally (see > https://github.com/openstack/rally/blob/master/CHANGELOG.rst, all > versions are included there). We do not provide in-tree OpenStack plugins > started from Rally 1.0.0 .You need to install rally-openstack package ( > https://pypi.python.org/pypi/rally-openstack) . It has Rally as a > dependency, so if you are preparing the environment from the scratch -> > just install rally-openstack package. > > 2) There are one or many conflicts in package requirements. Run `rally > plugin show Dummy.openstack` and see the logging messages. It should point > out the errors of loading plugins if there is something. > > чт, 9 авг. 2018 г. в 10:32, Goutham Pratapa : > >> Hi Rally Team, >> >> I have been trying to setup rally version v1.1.0 >> >> I could successfully install rally but when i try to create the >> deployment i am getting this error >> >> >> >> *ubuntu@ubuntu:~$ rally deployment create --file=existing.json >> --name=existing* >> >> *Env manager got invalid spec:* >> >> >> * ["There is no Platform plugin with name: 'existing@openstack'"]* >> >> >> *ubuntu@ubuntu:~$ rally version * >> >> *1.1.0* >> >> can any one help me the issue and the fix ? >> >> Thanks in advance. >> >> -- >> Cheers !!! >> Goutham Pratapa >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > Best regards, > Andrey Kurilin. > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [rally] There is no Platform plugin with name: 'existing@openstack'"
Hi Rally Team, I have been trying to setup rally version v1.1.0 I could successfully install rally but when i try to create the deployment i am getting this error *ubuntu@ubuntu:~$ rally deployment create --file=existing.json --name=existing* *Env manager got invalid spec:* * ["There is no Platform plugin with name: 'existing@openstack'"]* *ubuntu@ubuntu:~$ rally version * *1.1.0* can any one help me the issue and the fix ? Thanks in advance. -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tempest] Small doubt in Tempest setup
stestr worked thanks but im getting the same error for ostestr -l any idea on what to do ?? On Mon, Aug 6, 2018 at 7:27 PM, Attila Fazekas wrote: > I was tried to be quick and become wrong. ;-) > > Here are the working ways: > > On Mon, Aug 6, 2018 at 3:49 PM, Attila Fazekas > wrote: > >> Please use ostestr or stestr instead of testr. >> >> $ git clone https://github.com/openstack/tempest >> $ cd tempest/ >> $ stestr init >> $ stestr list >> >> $ git clone https://github.com/openstack/tempest >> $ cd tempest/ >> $ ostestr -l #old way, also worked, does to steps >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tempest] Small doubt in Tempest setup
Done thanks afazekas Thanks Goutham On Mon, 6 Aug 2018 at 7:27 PM, Attila Fazekas wrote: > I was tried to be quick and become wrong. ;-) > > Here are the working ways: > > On Mon, Aug 6, 2018 at 3:49 PM, Attila Fazekas > wrote: > >> Please use ostestr or stestr instead of testr. >> >> $ git clone https://github.com/openstack/tempest >> $ cd tempest/ >> $ stestr init >> $ stestr list >> >> $ git clone https://github.com/openstack/tempest >> $ cd tempest/ >> $ ostestr -l #old way, also worked, does to steps >> >> > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tempest] Small doubt in Tempest setup
Hi all, This is regarding Tempest setup I have cloned and setup my tempest i could run my tests with '*nosetests*' also but when i try to run with *testr* im getting *$ testr list-tests * *No .testr.conf config file* any idea why it is occurring and any idea how to fix it will really help.. Thanks in advance. -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] ptl non candidacy
Hi Jeffrey, Thank you for your works as a PTL in OpenStack-kolla. You were always friendly, Helpful and always a ready to approach guy Thank you for all the help and support. Thanks Goutham Pratapa. On Fri, Aug 3, 2018 at 1:10 PM, Ha Quang, Duong wrote: > Hi Jeffrey, > > Thank you for your works as PTL in Rocky cycle and release liaison from > many cycle ago (at least I joined Kolla community, you are already release > liaison). > > Hope that we still see you around then. > > Regards, > Duong > > > > From: Jeffrey Zhang [mailto:zhang.lei@gmail.com] > > Sent: Wednesday, July 25, 2018 10:48 AM > > To: OpenStack Development Mailing List openstack.org> > > Subject: [openstack-dev] [kolla] ptl non candidacy > > > > Hi all, > > > > I just wanna to say I am not running PTL for Stein cycle. I have been > involved in Kolla project for almost 3 years. And recently my work changes > a little, too. So > I may not have much time in the community in the > future. Kolla is a great project and the community is also awesome. I would > encourage everyone in the > community to consider for running. > > > Thanks for your support :D. > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] : Query regarding bug 1769089
Try asking people in webirc webchat.freenode.net Nickname : your name channel: #openstack-heat and you will find people ask them it's better to talk to them rather than here people might not respond here there you have a good chance https://review.openstack.org/#/admin/groups/114,members you will find people with these names ping them directly... Cheers Goutham. On Wed, May 30, 2018 at 6:26 PM, Ashika Meher Majety wrote: > Hello, > > We have raised a bug in launchpad and the bug link is as follows: > https://bugs.launchpad.net/heat-dashboard/+bug/1769089 . > Can anyone please provide a solution or fix for this issue since it's been > 20 days since we have created this bug. > > Thanks, > Ashika Meher > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][vote]Core nomination for Mark Goddard (mgoddard) as kolla core member
+1 for `mgoddard` On Thu, May 3, 2018 at 1:21 PM, duon...@vn.fujitsu.com < duon...@vn.fujitsu.com> wrote: > +1 > > > > Sorry for my late reply, thank you for your contribution in Kolla. > > > > Regards, > > Duong > > > > *From:* Jeffrey Zhang [mailto:zhang.lei@gmail.com] > *Sent:* Thursday, April 26, 2018 10:31 PM > *To:* OpenStack Development Mailing List <openstack-dev@lists. > openstack.org> > *Subject:* [openstack-dev] [kolla][vote]Core nomination for Mark Goddard > (mgoddard) as kolla core member > > > > Kolla core reviewer team, > > It is my pleasure to nominate > > > > mgoddard for kolla core team. > > > > Mark has been working both upstream and downstream with kolla and > kolla-ansible for over two years, building bare metal compute clouds with > ironic for HPC. He's been involved with OpenStack since 2014. He started > the kayobe deployment project which complements kolla-ansible. He is > also the most active non-core contributor for last 90 days[1] > > > > Consider this nomination a +1 vote from me > > A +1 vote indicates you are in favor of > > > > mgoddard as a candidate, a -1 > is a > > > > veto. Voting is open for 7 days until > > May > > > > 4 > > th, or a unanimous > response is reached or a veto vote occurs. > > [1] http://stackalytics.com/report/contribution/kolla-group/90 > > > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [rally] Moving OpenStack plugins into separate repo
Hi andrey, Great to hear this Cheers and I wish you all luck Cheers Goutham. On Wed, 11 Apr 2018 at 11:00 PM, Boris Pavlovic <bo...@pavlovic.me> wrote: > Andrey, > > Great news! > > Best regards, > Boris Pavlovic > > On Wed, Apr 11, 2018 at 9:14 AM, Andrey Kurilin <andr.kuri...@gmail.com> > wrote: > >> Hi Stackers! >> >> Today I am happy to announce great news! >> >> From a historical perspective, Rally is testing (benchmarking) tool for >> OpenStack, but it is changed. More and more users want to use Rally for >> different platforms and environments. Our pluggable system allows doing >> this. >> To make the framework lightweight and simplify our release model, we >> decided to move OpenStack to the separate repository[1]. >> >> [1] https://git.openstack.org/cgit/openstack/rally-openstack >> >> We cut the first release 1.0.0 two weeks ago, and it is published to >> PyPI[2]. >> >> [2] https://pypi.python.org/pypi/rally-openstack >> >> If you are Rally consumer and do not have custom plugins, the migration >> should be simple. Just install rally-openstack package instead of rally and >> everything will work as previously. rally-openstack has a dependency to >> rally, so you need nothing more than installing one package. >> >> If you have custom plugins, do not worry, the migration should be simple >> for you too. The first release has the similar structure as it was in rally >> repository. The only thing which should be changed is importing >> rally_openstack instead of rally.plugins.openstack. >> >> -- >> Best regards, >> Andrey Kurilin. >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][Kingbird][Heat][Glance]Multi-Region Orchestrator
Hi Colleen, Thanks for writing to us. Sure, we will definitely try to help as much as we can :). On Mon, Feb 12, 2018 at 8:44 PM, Colleen Murphy <coll...@gazlene.net> wrote: > On Mon, Feb 12, 2018 at 7:44 AM, Goutham Pratapa > <pratapagout...@gmail.com> wrote: > > > > > OUR USE-CASES QUOTA-MANAGEMENT: > > > > 1. Admin must have a global view of all quotas to all tenants across all > the > > regions > > 2. Admin can periodically balance the quotas (we have a formula using > which > > we do this balancing ) across regions > > 3. Admin can update, Delete quotas for tenants > > 4. Admin can sync quotas for all tenants so that the quotas will be > updated > > in all regions. > > Global quota management is something we're seeking to solve in > keystone[1][2][3][4], which would enable admins to do 1, 3, and 4 via > keystone (though admittedly this is a few cycles out). We expect to > dive into this at the PTG if you'd like to help shape this work. > > [1] http://specs.openstack.org/openstack/keystone-specs/ > specs/keystone/ongoing/unified-limits.html > [2] http://specs.openstack.org/openstack/keystone-specs/ > specs/keystone/queens/limits-api.html > [3] https://review.openstack.org/#/c/441203/ > [4] https://review.openstack.org/#/c/540803/ > > Colleen > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][Kingbird][Heat][Glance]Multi-Region Orchestrator
Hi, Zane, Sorry for the late reply I was on leave for a couple of days. Firstly, Thanks for the clear in detail analysis and suggestions on quotas and resources-management it really means a lot to us :). Secondly, these are the use-cases which kingbird is mainly developed for. *OUR USE-CASES QUOTA-MANAGEMENT:* 1. Admin must have a global view of all quotas to all tenants across all the regions 2. Admin can periodically balance the quotas (we have a formula using which we do this balancing ) across regions 3. Admin can update, Delete quotas for tenants 4. Admin can sync quotas for all tenants so that the quotas will be updated in all regions. *USE-CASES FOR RESOURCE-MANAGEMENT:* 1. Resources which are required to boot up a VM in One region should be accessible in other target-regions In the process, Kingbird has support for the following a) Sync/Replicate existing Nova-Keypairs b) Sync/Replicate existing Glance-Images c) Sync/Replicate existing Nova-Flavors.(Only admin can sync these.) 2. User who has a VM in one region should have the ease or possibility to have a replica of the same vm in target-region(s) a) It can be a snapshot of the already booted-up VM or with the same qcow2 image. *GENERIC USE-CASES* 1. Automation scripts for kingbird in -ansible, -salt -puppet. 2. Add SSL support to kingbird 3. Resource management in Kingbird-dashboard. 4. Kingbird in a docker 5. Add Kingbird into Kolla. On Fri, Feb 9, 2018 at 12:47 AM, Zane Bitter <zbit...@redhat.com> wrote: > On 07/02/18 12:24, Goutham Pratapa wrote: > >> >Yes as you said it can be interpreted as a tool that can >> orchestrate multiple-regions. >> > > Actually from your additional information I'm now getting the impression > that you are, in fact, positioning this as a partial competitor to Heat. >To some extent yes, Till now we have focused on resource-synchronization > and quota-balancing for various tenants across multiple-regions. But in the > coming cycle we want to enter the orchestration game. > > Just to be sure does openstack already has project which can >> replicate the resources and orchestrate??? >> > > OpenStack has an orchestration service - Heat - and it allows you to do > orchestration across multiple regions by creating a nested Stack in an > arbitrary region as a resource in a Heat Stack.[1] > > Heat includes the ability to create Nova keypairs[2] and even, for those > users with sufficient privileges, flavors[3] and quotas[4][5][6]. (It used > to be able to create Glance images as well, but this was deprecated because > it is not feasible using the Glance v2 API.) > > [1] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Heat::Stack > [2] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Nova::KeyPair > [3] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Nova::Flavor > [4] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Nova::Quota > [5] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Cinder::Quota > [6] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Neutron::Quota > > why because In coming >> cycle our idea is that a user just gives a VM-ID or Vm-name and we >> sync all the resources with which the vm is actually created >> ofcourse we cant have the same network in target-region so we may >> need the network-id or port-id from the target region from user so >> that kingbird will boot up the requested vm in the target region(s). >> > > So it sounds like you are starting from the premise that users will create > stuff in an ad-hoc way, then later discover that they need to replicate > their ad-hoc deployments to multiple regions, and you're building a tool to > do that. Heat, on the other hand, starts from the premise that users will > invest a little up-front effort to create a declarative definition of their > deployment, which they can then deploy repeatably in multiple (or the > same!) regions. Our experience is that people have shown themselves to be > quite willing to do this, because repeatable deployments have lots of > benefits. > Yes that is true. But, our idea is the same as what you have stated above > ` *So it sounds like you are starting from the premise that users will > create stuff in an ad-hoc way, then later discover that they need to > replicate their ad-hoc deployments to multiple regions *` to reduce the > repeatable deployments. > > Looking at the things you want to synchronise: > > * Quotas > > Synchronize after balancing quotas across regions. (our use-case is if an > admin user wants to know the global limit for a
Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator
Hi Chris, Thanks for writing to us. Our idea is just the same. and we are working on how to do it :) Thanks for the use-case :) On Wed, Feb 7, 2018 at 9:50 PM, Chris Friesen <chris.frie...@windriver.com> wrote: > On 02/05/2018 06:33 PM, Jay Pipes wrote: > > 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. >> >> That way, there'd be no need for replicating anything. >> > > One use-case I've seen for this sort of thing is someone that has multiple > geographically-separate clouds, and maybe they want to run the same heat > stack in all of them. > > So they can use global glance/keystone, but they need to ensure that they > have the right flavor(s) available in all the clouds. This needs to be > done by the admin user, so it can't be done as part of the normal user's > heat stack. > Something like "create a keypair in each of the clouds with the same > public key and same name" could be done by the end user with some coding, > but it's convenient to have a tool to do it for you. > > Chris > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator
Hi Zane, Thanks for writing to us. We have a doubt and I have mentioned in the inline comments can you please help us in that regard. On Tue, Feb 6, 2018 at 11:53 PM, Zane Bitter <zbit...@redhat.com> wrote: > On 31/01/18 01:49, 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. >> > > I'd invite you to consider coming up with a different short description > for the project, because this one reads ambiguously. It can be interpreted > as either an orchestrator that works across multiple regions, or a tool > that 'orchestrates' multiple regions for some new definition of > 'orchestration' (and I regret that we already have more than one). I gather > you mean the latter; the former already exists in OpenStack. >Yes as you said it can be interpreted as a tool that can orchestrate > multiple-regions. Just to be sure does openstack already has project which can replicate the > resources and orchestrate??? why because In coming cycle our idea is that a > user just gives a VM-ID or Vm-name and we sync all the resources with which > the vm is actually created ofcourse we cant have the same network in > target-region so we may need the network-id or port-id from the target > region from user so that kingbird will boot up the requested vm in the > target region(s). > > cheers, > Zane. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator
On Tue, Feb 6, 2018 at 6:03 AM, Jay Pipes <jaypi...@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 OpenStac
Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator
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 ) 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. and yes we cannot sync vm's across regions but our idea is to sync/replicate all the parameters required to boot a vm (viz. *image, keypair, flavor*) which are originally there in the source region to the target regions in a single-go. 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 region and 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 Thanks Goutham. On Wed, Jan 31, 2018 at 9:25 PM, Jay Pipes <jaypi...@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> >> * >> *Python-Kingbird-client (0.2.1): https://github.com/openstack/p >> ython-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-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator
OK, sorry that was a mistake :) Thank you, Thierry :) On Wed, Jan 31, 2018 at 2:51 PM, Thierry Carrez <thie...@openstack.org> wrote: > 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. > > [...] > > Thanks > > Goutham Pratapa > > PTL > > OpenStack-Kingbird. > > Quick clarification: Kingbird is not (yet) an official OpenStack > component, so it should probably not call itself OpenStack Kingbird. > > Regards, > > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][Kingbird]Multi-Region Orchestrator
*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 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. -- 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>* *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>* 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack-ansible] Cannot connect to proxy server from infra1-repo-container
Hi, We are trying test environment deployment with OpenStack-ansible pike release. After executing setup-hosts.yaml, the lxc-containers were created. We have an issue while doing *apt-get update *in infra-repo-container as it couldn't connect to the proxy server. The strange thing is that the infra-repo-container is not showing ip on any interface when checked with *ip r*. Could you please help us with this issue. Below are some logs on the container and on the host. E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/xenial-security/ main/binary-amd64/Packages Something wicked happened resolving 'xx.xx.xx.xx :8080 <http://10.51.40.88:8080>' (-9 - Address family for hostname not supported) root@infra1-repo-container-a7a137c4:/# ping xx.xx.xx.xx (proxy server) connect: Network is unreachable *On Container*: root@infra1-repo-container-a7a137c4:/# cat /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # LXC interface, this is ALWAYS assumed to be DHCP. auto eth0 iface eth0 inet dhcp # Load any additional configs source /etc/network/interfaces.d/*.cfg root@infra1-repo-container-a7a137c4:/# cat /etc/network/interfaces.d/ eth1.cfg # Ansible managed ### start generated network for [ eth1 ] ### auto eth1 iface eth1 inet static address 192.168.124.126 netmask 255.255.255.0 mtu 1500 post-up sysctl -w net.ipv4.conf.$IFACE.arp_notify=1 post-up ip link set $IFACE address $(cat /sys/class/net/$IFACE/address) ### end generated network for [ eth1 ] ### root@infra1-repo-container-a7a137c4:/# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface *On host:* root@ubuntu:/home/ansible# ifconfig lxcbr0 lxcbr0Link encap:Ethernet HWaddr fe:02:f2:ff:bd:86 inet addr:10.0.3.1 Bcast:10.0.3.255 Mask:255.255.255.0 inet6 addr: fe80::a085:76ff:febb:401d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:691 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:181224 (181.2 KB) TX bytes:828 (828.0 B) root@ubuntu:/home/ansible# ip r default via 192.168.124.1 dev eno1 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 192.168.124.0/24 dev eno1 proto kernel scope link src 192.168.124.28 192.168.124.0/24 dev br-mgmt proto kernel scope link src 192.168.124.28 Thanks in advance... -- Thanks !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack-ansible] Cannot connect to prxy server from infra1-repo-container
Hi, We are trying test environment deployment with openstack-ansible pike release. After executing setup-hosts.yaml, the lxc-containers were created. We have an issue while doing apt-get update in infra-repo-container as it couldn't connect to the proxy server. The strange this is that the infra-repo-container is not showing ip on any interface when checked with ip r. Could you please help us with this issue. Below are some logs on the container and on the host. E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages Something wicked happened resolving '10.51.40.88:8080' (-9 - Address family for hostname not supported) root@infra1-repo-container-a7a137c4:/# ping 10.51.40.88 (proxy server) connect: Network is unreachable On Container: root@infra1-repo-container-a7a137c4:/# cat /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # LXC interface, this is ALWAYS assumed to be DHCP. auto eth0 iface eth0 inet dhcp # Load any additional configs source /etc/network/interfaces.d/*.cfg root@infra1-repo-container-a7a137c4:/# cat /etc/network/interfaces.d/eth1.cfg # Ansible managed ### start generated network for [ eth1 ] ### auto eth1 iface eth1 inet static address 192.168.124.126 netmask 255.255.255.0 mtu 1500 post-up sysctl -w net.ipv4.conf.$IFACE.arp_notify=1 post-up ip link set $IFACE address $(cat /sys/class/net/$IFACE/address) ### end generated network for [ eth1 ] ### root@infra1-repo-container-a7a137c4:/# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface On host: root@ubuntu:/home/ansible# ifconfig lxcbr0 lxcbr0Link encap:Ethernet HWaddr fe:02:f2:ff:bd:86 inet addr:10.0.3.1 Bcast:10.0.3.255 Mask:255.255.255.0 inet6 addr: fe80::a085:76ff:febb:401d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:691 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:181224 (181.2 KB) TX bytes:828 (828.0 B) root@ubuntu:/home/ansible# ip r default via 192.168.124.1 dev eno1 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 192.168.124.0/24 dev eno1 proto kernel scope link src 192.168.124.28 192.168.124.0/24 dev br-mgmt proto kernel scope link src 192.168.124.28 -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Vxlan and OVS issues post deployment.
Hi Eduardo, No, they were not created by default I had to follow the workaround only then they are getting created I'm just bringing to your notice that the issue is still there because they are not present after the deployment :) Now even after the tunnels are created VM's are not getting the IP Thanks Goutham. On Thu, Nov 30, 2017 at 4:02 PM, Eduardo Gonzalez <dabar...@gmail.com> wrote: > Hi Goutham, > > VXLAN tunnels are created between network/compute hosts in expected > interface (ens3): > > df_default="true", in_key=flow, local_ip="192.168.122.215", out_key=flow, > remote_ip="192.168.122.177" > > Where is exactly failing? Instances not get IP, DHCP does not work, vm-to-vm > traffic issues, public traffic issues? > > Regards > > > 2017-11-30 11:26 GMT+01:00 Goutham Pratapa <pratapagout...@gmail.com>: > >> Hi Eduardo, >> >> I am trying to deploy self-service network topology. >> >> I think then I shouldn't be bothered about the `ens8` because I'm not >> dealing with provider networks >> >> and attached are the outputs requested... >> >> Ps: Controller and the network node are both same in my setup. >> >> Thanks in advance >> >> Goutham >> >> On Thu, Nov 30, 2017 at 3:33 PM, Eduardo Gonzalez <dabar...@gmail.com> >> wrote: >> >>> Hi, >>> >>> In kolla,VXLAN tunnels are connfigured in ``tunnel_interface`` variable >>> which defaults to ``network_interface``, ``neutron_external_interface`` is >>> used for public floating IPs in neutron. >>> >>> Please share your globals.yml, ``ip a`` output in compute/network hosts >>> and ``ovs-vsctl show`` from openvswitch daemon containers. >>> >>> What network topology are you trying to deploy? Self-service, provider >>> networks, etc? >>> >>> Regards >>> >>> >>> 2017-11-30 10:42 GMT+01:00 Jeffrey Zhang <zhang.lei@gmail.com>: >>> >>>> i guess you didn't enabled one of following[0] >>>> >>>> enable_neutron_dvr: yes >>>> enable_neutron_provider_networks: yes >>>> >>>> I hit this recently. i am thinking we should remove this or make >>>> enable_neutron_provider_network=yes in default. >>>> >>>> [0] https://github.com/openstack/kolla-ansible/blob/master/a >>>> nsible/group_vars/all.yml#L607 >>>> >>>> >>>> On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa < >>>> pratapagout...@gmail.com> wrote: >>>> >>>>> Hi Kolla Team, >>>>> >>>>> I have tried deploying Kolla OpenStack multinode and I am facing this >>>>> issue vxlan_peers_not_created >>>>> <https://ask.openstack.org/en/question/110570/vxlan-peers-not-being-created-on-compute-node-vm-not-getting-dhcp/> >>>>> in every deployment and I* tried the workaround* i.e restart the >>>>> network containers to get the vxlan peers >>>>> >>>>> But when I see *ip addr show *in my compute node. >>>>> >>>>> *P.S:* "ens8" is the interface I specified as >>>>> *neutron_external_interface** in globals.yml* >>>>> >>>>> >>>>> * Globals.yml-* >>>>> >>>>> >>>>> >>>>> >>>>> *# This is the raw interface given to neutron as its external network >>>>> port. Even# though an IP address can exist on this interface, it will be >>>>> unusable in most# configurations. It is recommended this interface not be >>>>> configured with any IP# addresses for that reason.* >>>>> >>>>> *neutron_external_interface: "ens8"*3: ens8: >>>>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP >>>>> group default qlen 1000 >>>>> link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff >>>>> inet 192.168.122.218/24 scope global ens8 >>>>>valid_lft forever preferred_lft forever >>>>> inet6 fe80::5054:ff:fe54:b350/64 scope link >>>>>valid_lft forever preferred_lft forever >>>>> >>>>> Which should be something like the below (as per my understanding) for >>>>> the Vms to be up and running. >>>>> >>>>> 3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast >>>>>
Re: [openstack-dev] [kolla] Vxlan and OVS issues post deployment.
Hi Eduardo, I am trying to deploy self-service network topology. I think then I shouldn't be bothered about the `ens8` because I'm not dealing with provider networks and attached are the outputs requested... Ps: Controller and the network node are both same in my setup. Thanks in advance Goutham On Thu, Nov 30, 2017 at 3:33 PM, Eduardo Gonzalez <dabar...@gmail.com> wrote: > Hi, > > In kolla,VXLAN tunnels are connfigured in ``tunnel_interface`` variable > which defaults to ``network_interface``, ``neutron_external_interface`` is > used for public floating IPs in neutron. > > Please share your globals.yml, ``ip a`` output in compute/network hosts > and ``ovs-vsctl show`` from openvswitch daemon containers. > > What network topology are you trying to deploy? Self-service, provider > networks, etc? > > Regards > > > 2017-11-30 10:42 GMT+01:00 Jeffrey Zhang <zhang.lei@gmail.com>: > >> i guess you didn't enabled one of following[0] >> >> enable_neutron_dvr: yes >> enable_neutron_provider_networks: yes >> >> I hit this recently. i am thinking we should remove this or make >> enable_neutron_provider_network=yes in default. >> >> [0] https://github.com/openstack/kolla-ansible/blob/master/ >> ansible/group_vars/all.yml#L607 >> >> >> On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa < >> pratapagout...@gmail.com> wrote: >> >>> Hi Kolla Team, >>> >>> I have tried deploying Kolla OpenStack multinode and I am facing this >>> issue vxlan_peers_not_created >>> <https://ask.openstack.org/en/question/110570/vxlan-peers-not-being-created-on-compute-node-vm-not-getting-dhcp/> >>> in every deployment and I* tried the workaround* i.e restart the >>> network containers to get the vxlan peers >>> >>> But when I see *ip addr show *in my compute node. >>> >>> *P.S:* "ens8" is the interface I specified as >>> *neutron_external_interface** in globals.yml* >>> >>> >>> * Globals.yml-* >>> >>> >>> >>> >>> *# This is the raw interface given to neutron as its external network >>> port. Even# though an IP address can exist on this interface, it will be >>> unusable in most# configurations. It is recommended this interface not be >>> configured with any IP# addresses for that reason.* >>> >>> *neutron_external_interface: "ens8"*3: ens8: >>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP >>> group default qlen 1000 >>> link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff >>> inet 192.168.122.218/24 scope global ens8 >>>valid_lft forever preferred_lft forever >>> inet6 fe80::5054:ff:fe54:b350/64 scope link >>>valid_lft forever preferred_lft forever >>> >>> Which should be something like the below (as per my understanding) for >>> the Vms to be up and running. >>> >>> 3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast *master >>> ovs-system* state UP group default qlen 1000 >>> link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff >>> inet 192.168.122.165/32 scope global ens8 >>>valid_lft forever preferred_lft forever >>> inet6 fe80::5054:ff:fe22:4bcf/64 scope link >>>valid_lft forever preferred_lft forever >>> >>> Is this a known issue ?? >>> >>> If yes any workaround to solve?? >>> >>> Thanks in advance. >>> -- >>> Thanks!!! >>> Goutham Pratapa >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-d
[openstack-dev] [kolla] Vxlan and OVS issues post deployment.
Hi Kolla Team, I have tried deploying Kolla OpenStack multinode and I am facing this issue vxlan_peers_not_created <https://ask.openstack.org/en/question/110570/vxlan-peers-not-being-created-on-compute-node-vm-not-getting-dhcp/> in every deployment and I* tried the workaround* i.e restart the network containers to get the vxlan peers But when I see *ip addr show *in my compute node. *P.S:* "ens8" is the interface I specified as *neutron_external_interface** in globals.yml* * Globals.yml-* *# This is the raw interface given to neutron as its external network port. Even# though an IP address can exist on this interface, it will be unusable in most# configurations. It is recommended this interface not be configured with any IP# addresses for that reason.* *neutron_external_interface: "ens8"*3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff inet 192.168.122.218/24 scope global ens8 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe54:b350/64 scope link valid_lft forever preferred_lft forever Which should be something like the below (as per my understanding) for the Vms to be up and running. 3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast *master ovs-system* state UP group default qlen 1000 link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff inet 192.168.122.165/32 scope global ens8 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe22:4bcf/64 scope link valid_lft forever preferred_lft forever Is this a known issue ?? If yes any workaround to solve?? Thanks in advance. -- Thanks!!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Compute fails to startup
Hi Eduardo, Following is the nova-compute log <https://hastebin.com/asikijekiq.sql> https://hastebin.com/asikijekiq.sql -- compute log (I didn't find any error) and the libvirt log is empty What kolla release is deployed? >> $ *pip freeze | grep kolla* kolla==5.0.1.dev26 kolla-ansible==5.0.1.dev37 Kolla 5.0.1 is the version we have used.. If using nested virtualization, is correctly configured to use qemu instead of kvm? >> Yes, because 2 weeks back on the same setup we could deploy kolla Thanks in advance Goutham On Tue, Nov 21, 2017 at 9:28 PM, Eduardo Gonzalez <dabar...@gmail.com> wrote: > Hi Goutham, > > Please share your nova-compute and libvirt logs from > /var/lib/docker/volumes/kolla_logs/_data/nova. > > What kolla release is deployed? > If using nested virtualization, is correctly configured to use qemu > instead of kvm? > > Regards > > 2017-11-21 15:37 GMT+01:00 Goutham Pratapa <pratapagout...@gmail.com>: > >> Hi all, >> >> I have been trying to deploy Kolla on a virtualized environment with >> Centos Docker images using the >> >> stable/pike branch >> >> Deployment fails with -- https://hastebin.com/gubilijecu.vbs >> Inventory fail -- https://hastebin.com/etosipegez.pl >> extra log -- https://hastebin.com/yudafudegu.go >> Docker logs https://hastebin.com/imotenanob.cs >> Gloabls.yml https://hastebin.com/ihamepanim.coffeescript >> >> Any help would be of great use ??? >> >> Thanks in advance... >> >> Thank you !!! >> Goutham Pratapa >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla] Compute fails to startup
Hi all, I have been trying to deploy Kolla on a virtualized environment with Centos Docker images using the stable/pike branch Deployment fails with -- https://hastebin.com/gubilijecu.vbs Inventory fail -- https://hastebin.com/etosipegez.pl extra log -- https://hastebin.com/yudafudegu.go Docker logs https://hastebin.com/imotenanob.cs Gloabls.yml https://hastebin.com/ihamepanim.coffeescript Any help would be of great use ??? Thanks in advance... Thank you !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Host networking in Kolla
Hi Eduardo, Thanks, this helps we will get back to you in case of any doubts Thanks, Goutham. On Mon, Nov 13, 2017 at 6:20 PM, Eduardo Gonzalez <dabar...@gmail.com> wrote: > Hi Akshay. > > Yes, kolla support segregate almost all traffic in different interfaces. > By default all traffic uses network_interface, but you can specify any of > the following variables under Network configuration section. > https://docs.openstack.org/kolla-ansible/latest/admin/ > production-architecture-guide.html > > Regards > > On Mon, Nov 13, 2017, 1:30 PM Goutham Pratapa <pratapagout...@gmail.com> > wrote: > >> Hi all, >> >> Does OpenStack-Kolla support Host-networking (separate network for >> management, traffic, and storage) >> ( >> https://docs.openstack.org/newton/install-guide-rdo/environment-networking.html >> ) >> >> Any ideas ?? >> >> >> Thanks in advance >> >> -- >> Thanks !!! >> Goutham Pratapa >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla] Host networking in Kolla
Hi all, Does OpenStack-Kolla support Host-networking (separate network for management, traffic, and storage) ( https://docs.openstack.org/newton/install-guide-rdo/environment-networking.html ) Any ideas ?? Thanks in advance -- Thanks !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Zuul Error for commits
Hi, It triggers only Jenkins job but not ZUUL jobs Thanks Goutham On Thu, 5 Oct 2017 at 5:26 PM, Kekane, Abhishek <abhishek.kek...@nttdata.com> wrote: > Goutham, > > > > Add ‘recheck’ as a comment. It will retrigger the jenkins jobs. > > > > Thank you, > > > > Abhishek > > > > *From:* Goutham Pratapa [mailto:pratapagout...@gmail.com] > *Sent:* Thursday, October 05, 2017 5:14 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [all] Zuul Error for commits > > > > Hi all, > > I have made a commit to a Kingbird-project and Zuul jobs ran and a job > namely openstack-tox-py27 > <http://logs.openstack.org/13/487813/3/check/openstack-tox-py27/c1e9e14/> > > > > failed with the error *TIMED_OUT** in 2h 32m 23s *which resulted in -1 > how can I retrigger it is > > > > this a known issue?? > > > > Commit for reference: https://review.openstack.org/#/c/487813/ > > > > Any help? > > > > Thanks in advance.. > > > > Cheers !!! > > Goutham Pratapa > > __ > Disclaimer: This email and any attachments are sent in strictest confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then delete > and destroy this email and any attachments without any further use, copying > or forwarding. > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Zuul Error for commits
Hi all, I have made a commit to a Kingbird-project and Zuul jobs ran and a job namely openstack-tox-py27 <http://logs.openstack.org/13/487813/3/check/openstack-tox-py27/c1e9e14/> <http://logs.openstack.org/13/487813/3/check/openstack-tox-py27/c1e9e14/> failed with the error *TIMED_OUT in 2h 32m 23s *which resulted in -1 how can I retrigger it is this a known issue?? Commit for reference: https://review.openstack.org/#/c/487813/ Any help? Thanks in advance.. <http://logs.openstack.org/13/487813/3/check/openstack-tox-py27/c1e9e14/> Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Kingbird UX for Horizon
Hi Beth, It's perfectly fine Kingbird is for multi-region cloud environments. https://wiki.openstack.org/wiki/Kingbird and coming to the horizon thanks for the suggestions I will definitely post questions in Openstack-horizon and get my doubts or issues solved in-case of any. Thanks Goutham Pratapa. On Fri, Sep 15, 2017 at 9:51 AM, Beth Elwell <beth.openst...@gmail.com> wrote: > Hi Goutham, > > I apologise I have not come across Kingbird before but will be interested > to find out more about it! > > To me the UX looks good but I don’t have enough exposure to what Kingbird > is to know if it represents what you will need from a UI. Horizon has lots > of templates and examples of how to build modals and buttons etc as per > your current mocks so please do look at current examples and ask in > #openstack-horizon if you need any help or advise at all. That will save > you work and ensure the UI is consistent and we don’t have lots of > duplicate code and ways of making the same sort of things that could prove > to be confusing for future developers. As I say though, you are always > welcome in channel and there will always be someone around to help you out > and point you in the right direction. > > Hope that helps! > Beth > > > On 14 Sep 2017, at 00:24, Goutham Pratapa <pratapagout...@gmail.com> > wrote: > > HI all, > > Attached are the expected UX screens for Kingbird's horizon please feel > free to provide feedback on this. > > > P.S: *Images are drawn using paint and we will follow all the OpenStack > Horizon standards when we develop* > > -- > Cheers !!! > Goutham Pratapa > ___ > ___ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Kingbird UX for Horizon
HI all, Attached are the expected UX screens for Kingbird's horizon please feel free to provide feedback on this. P.S: *Images are drawn using paint and we will follow all the OpenStack Horizon standards when we develop* -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Queens Goal for Kingbird
Hi joe, Good to hear from you and thanks for the wishes :) On Mon, 4 Sep 2017 at 5:52 AM, joehuang <joehu...@huawei.com> wrote: > Cool, looking forward to the dashboard plugin. > > Best Regards > Chaoyi Huang (joehuang) > ------ > *From:* Goutham Pratapa [pratapagout...@gmail.com] > *Sent:* 01 September 2017 21:05 > *To:* openstack-dev@lists.openstack.org > > *Subject:* [openstack-dev] [all] Queens Goal for Kingbird > Hi all, > > For this Queens cycle, we would like to implement *Kingbird dashboard* so > that it can be used as a *plugin in horizon* using which > > > *- Admin can manage quota across multiple-regions and * > > > > > * - Users can manage their respective resources (for now flavor, image, > keypairs) across multiple regions * > through *front-end*. > > We are planning to extend resource_management to *glance image-metadefs* > as well. > > -- > Thanks!!! > Goutham Pratapa > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cheers !!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Queens Goal for Kingbird
Hi all, For this Queens cycle, we would like to implement *Kingbird dashboard* so that it can be used as a *plugin in horizon* using which *- Admin can manage quota across multiple-regions and * *- Users can manage their respective resources (for now flavor, image, keypairs) across multiple regions* through *front-end*. We are planning to extend resource_management to *glance image-metadefs* as well. -- Thanks!!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
