Re: [openstack-dev] [Magnum] New Core Reviewers
+1 for both On Wed, Nov 9, 2016 at 1:11 PM, Kumari, Madhuri wrote: > +1 for both. > > -Original Message- > From: Adrian Otto [mailto:adrian.o...@rackspace.com] > Sent: Tuesday, November 8, 2016 12:36 AM > To: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [Magnum] New Core Reviewers > > Magnum Core Team, > > I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum > Core Reviewers. Please respond with your votes. > > Thanks, > > Adrian Otto > __ > 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 > __ 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] [magnum] devstack magnum.conf
Perhaps it is better to append details, what error you hit ? and check devstack irc channel if it is not magnum part, and if something like magnum error message, check magnum IRC channel or open a bug. Sounds OK ? On Sat, Aug 6, 2016 at 2:46 AM, Yasemin DEMİRAL (BİLGEM BTE) < yasemin.demi...@tubitak.gov.tr> wrote: > > I follow this page but when I run ./stack command, it gives error. It > didnt create openstack user, the error about rabbitmq connection. > I didnt work successfully :/ > -- > *Kimden: *"Spyros Trigazis" > *Kime: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Gönderilenler: *5 Ağustos Cuma 2016 19:32:11 > *Konu: *Re: [openstack-dev] [magnum] devstack magnum.conf > > > Hi, > > better follow the quickstart guide [1]. > > Cheers, > Spyros > > [1] http://docs.openstack.org/developer/magnum/dev/quickstart.html > > On 5 August 2016 at 06:22, Yasemin DEMİRAL (BİLGEM BTE) < > yasemin.demi...@tubitak.gov.tr> wrote: > >> >> Hi >> >> I try to magnum on devstack, in the manual Configure magnum: section >> has sudo cp etc/magnum/magnum.conf.sample /etc/magnum/magnum.conf command, >> but there is no magnum.conf. >> What should i do ? >> >> Thanks >> >> Yasemin >> >> >> >> __ >> 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 > > > __ > 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
Re: [openstack-dev] [magnum-ui][magnum] Proposed Core addition, and removal notice
+1 Welcome to new one :) Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: 王华 To: "OpenStack Development Mailing List (not for usage questions)" Date: 13/06/2016 05:30 pm Subject:Re: [openstack-dev] [magnum-ui][magnum] Proposed Core addition, and removal notice +1 On Fri, Jun 10, 2016 at 5:32 PM, Shuu Mutou wrote: Hi team, I propose the following changes to the magnum-ui core group. + Thai Tran http://stackalytics.com/report/contribution/magnum-ui/90 I'm so happy to propose Thai as a core reviewer. His reviews have been extremely valuable for us. And he is active Horizon core member. I believe his help will lead us to the correct future. - David Lyle http://stackalytics.com/?metric=marks&project_type=openstack&release=all&module=magnum-ui&user_id=david-lyle No activities for Magnum-UI since Mitaka cycle. - Harsh Shah http://stackalytics.com/report/users/hshah No activities for OpenStack in this year. - Ritesh http://stackalytics.com/report/users/rsritesh No activities for OpenStack in this year. Please respond with your +1 votes to approve this change or -1 votes to oppose. Thanks, Shu __ 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 __ 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] [magnum] How to document 'labels'
I prefer option 1 with 3, which is easy to maintain. and also accounting for user experience. for option 2, is it really good to expose helpful message in API layer ? Thanks. Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Cc: Qun XK Wang/China/IBM@IBMCN Date: 12/05/2016 03:53 am Subject:[openstack-dev] [magnum] How to document 'labels' Hi all, This is a continued discussion from the last team meeting. For recap, ‘labels’ is a property in baymodel and is used by users to input additional key-pair pairs to configure the bay. In the last team meeting, we discussed what is the best way to document ‘labels’. In general, I heard three options: 1. Place the documentation in Magnum CLI as help text (as Wangqun proposed [1][2]). 2. Place the documentation in Magnum server and expose them via the REST API. Then, have the CLI to load help text of individual properties from Magnum server. 3. Place the documentation in a documentation server (like developer.openstack.org/…), and add the doc link to the CLI help text. For option #1, I think an advantage is that it is close to end-users, thus providing a better user experience. In contrast, Tom Cammann pointed out a disadvantage that the CLI help text might be easier to become out of date. For option #2, it should work but incurs a lot of extra work. For option #3, the disadvantage is the user experience (since user need to click the link to see the documents) but it makes us easier to maintain. I am thinking if it is possible to have a combination of #1 and #3. Thoughts? [1] https://review.openstack.org/#/c/307631/ [2] https://review.openstack.org/#/c/307642/ Best regards, Hongbin __ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Mike, Since right now, we have also support bay-update (node_count) I am thinking the following case: 1> baymodel-create have default flavor, and extra labels specify the(other node flavors) requirements, if (other node flavors) count <= bay(node_count), the extra nodes would be created use default flavor if (other node flavors) count > bay(node_count), it should pop error, since it not quite clear why flavor to use 2> magnum bay-update k8sbay replace node_count < existed node_count, it should be OK. same as old behavior if node_count > existed node_count, all new nodes would use default flavor_id, (if not, we need to find what's the better policy to handle that) Refer: https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst What do you think ? Thanks Best Wishes, ------------ Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Ma, Wen-Tao (Mike, HP Servers-PSC-BJ)" To: "openstack-dev@lists.openstack.org" Date: 27/04/2016 03:10 pm Subject:Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Hong bin, Thanks very much. It’s good suggestion, I think it is a good way by using labels for extra flavors. But I notice that there is not the �Cnode-count parameter in baymodel. So I think it doesn’t need specify minion-flavor-0 counts by �Cnode-count. We can specify all of the flavor id and count ratio in the labels. It will check the minion node count with this ratio of labels when creating magnum bay that specified total minion node count . If the node-count in baycreate doesn’t match with the flavor ratio, it will return the ratio match error message. If there is not the multi-flavor-ratio key in lables, it will just use minion-flavor-0 to create 10 minion nodes. $ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0 --labels multi- flavor-ratio=minion-flavor-0:3,minions-flavor-1:5,minion-flavor-2:2 $ magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 10 Do you think about it? > -Original Message- > From: Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) [mailto:wentao...@hpe.com] > Sent: April-26-16 3:01 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to > provision minion nodes > > Hi Hongbin, Ricardo > This is mike, I am working with Gary now. > Thanks for Ricardo's good suggestion. I have tried the "map/index" > method , we can use it to passed the minion_flavor_map and the index > into the minion cluster stack. It does work well. > I think we can update magnum baymodel-create to set the N minion > flavors in the minion_flavor_map and assign minion counts for each > flavor. > For example : > magnum baymodel-create --name k8s-bay-model --flavor-id minion-flavor- > 0:3,minion-flavor-1:5, minion-flavor-2:2. It will create 3 types flavor The suggested approach seems to break the existing behaviour. I think it is better to support this feature in a backward-compatible way. How about using labels: $ magnum baymodel-create --name k8sbaymodel --flavor-id minion-flavor-0 --node-count 3 --labels extra-flavor-ids=minions-flavor-1:5,minion-flavor-2:2 > minion node and total minion nodes count is 10. The magnum baymode.py > will parse this dictionary and pass them to the heat template > parameters minion_flavor_map, minion_flavor_count_map. Then the heat > stack will work well. > > kubecluster-fedora-ironic.yaml > parameters: > minion_flavor_map: > type: json > default: > '0': minion-flavor-0 > '1': minion-flavor-1 > '2': minion-flavor-2 > > minion_flavor_count_map: > type: json > default: > '0': 3 > '1': 5 > '2': 2 > > resources: > kube_minions_flavors: > type: OS::Heat::ResourceGroup > properties: > count: { get_param: minion_flavors_counts } > resource_def: > type: kubecluster-minion-fedora-ironic.yaml > properties: > minion_flavor_map: {get_param: minion_flavor_map} > minion_flavor_count_map: {get_param: minion_flavor_count_map} > minion_flavor_index: '%index%' > > How do you think about this interface in magnum baymodel to support N > falvor to provision minion nodes? Do you have
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Duan Li, We welcome to that contribution if you had. Just make sure that spec can be flexible handle 2 ~ N flavor cases. That could handle future requirements for N flavors, as in the ML, I found some ops had such requirements. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 21/04/2016 02:31 pm Subject:Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Eli, This is exactly what I want. If you guys think this requirement is reasonable, I’d like to commit a design spec so that we could discuss it in details. Regards, Gary Duan From: Eli Qiao [mailto:liyong.q...@intel.com] Sent: Wednesday, April 20, 2016 5:08 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Kannan, I think Duan Li is talking about using both 2 kinds of (secure-booted and non-secure-booted) node deploy *minion* node. The scenario may like this: let say 2 flavors: flavor_secure flavor_none_secure For now, flavor-id in baymodel can only be set as one value, Duan Li's requirement is to using flavor-id = [flavor_none_secure, flavor_secure] and provision one cluster which minion nodes are build from 2 types of flavor, then after cluster(bay ) provision finished , passing lable to let k8s cluster to chose a minion node to start pod on that specific node. For now, Magnum doesn't support it yet, I think it good to have it, but the implementation may be differnece per COE since after we provision bay, the scheduler work are done by k8s/swarm/mesos. Eli. On 2016年04月20日 16:36, Kai Qiang Wu wrote: Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support : https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65 flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For one question about ironic case (I found you deploy on ironic), I did not think Magnum templates now support ironic case now. As ironic VLAN related feature are still developing, and not merged (many patches are under review, pick one for example https://review.openstack.org/#/c/277853) I am not sure how would you use ironic for k8s cluster ? -- Best Regards, Eli Qiao (乔立勇) Intel OTC China __ 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
Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes
Hi Duan Li, Not sure if I get your point very clearly. 1> Magnum did support : https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L65 flavor-id for minion node master-flavor-id for master node So your K8s cluster could have such two kinds of flavors. 2> For one question about ironic case (I found you deploy on ironic), I did not think Magnum templates now support ironic case now. As ironic VLAN related feature are still developing, and not merged(many patches are under review, pick one for example https://review.openstack.org/#/c/277853) I am not sure how would you use ironic for k8s cluster ? Also in this summit https://etherpad.openstack.org/p/magnum-newton-design-summit-topics, we will have session about ironic cases: here it is : Ironic Integration: Add support for Ironic virt-driver If you had ways to make ironic work with Magnum, we welcome your contribution for that topic. Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 20/04/2016 03:46 pm Subject:[openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Folks, We are considering whether Magnum can supports 2 Nova flavors to provision Kubernetes and other COE minion nodes. This requirement comes from the below use cases: - There are 2 kind of baremetal machines in customer site: one is legacy machines which doesn’t support UEFI secure boot and others are new machines which support UEFI secure boot. User want to use Magnum to provisions a Magnum bay of Kubernetes from these 2 kind of baremetal machines and for the machines supporting secure boot, user wants to use UEFI secure boot to boot them up. And 2 Kubernetes label(secure-booted and non-secure-booted) are created and User can deploy their data-senstive/cirtical workload/containers/pods on the baremetal machines which are secure-booted. This requirement requires Magnum to supports 2 Nova flavors(one is “extra_spec: secure_boot=True” and the other doesn’t specify it) based on the Ironic feature( https://specs.openstack.org/openstack/ironic-specs/specs/kilo-implemented/uefi-secure-boot.html ). Could you kindly give me some comments on these requirement or whether it is reasonable from your point? If you agree, we can write design spec and implement this feature? Regards, Gary __ 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
Re: [openstack-dev] [magnum][kuryr] Shared session in design summit
Magnum has some kind of support to provide volume support in containers, also have some proposal topics to integrate Manila if possible. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Zhipeng Huang To: "OpenStack Development Mailing List (not for usage questions)" Cc: Taku Fukushima , Antoni Segura Puimedon , Irena Berezovsky Date: 19/04/2016 06:50 am Subject:Re: [openstack-dev] [magnum][kuryr] Shared session in design summit Thanks Hongbin, Actually we have a new project called Fuxi that sorta like Kuryr for storage, would be glad to discuss the ideas On Tue, Apr 19, 2016 at 5:26 AM, Hongbin Lu wrote: Hi all, The Magnum-Kuryr joined session was scheduled to Thursday 11:50 – 12:30: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9099 . I am looking forward to seeing you all there. In addition, Magnum will have another session for container storage: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9098 . I saw Kuryr recently expanded its scope to storage so it would be great if the relevant Kuryr contributors can join the storage session as well. Best regards, Hongbin From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: March-30-16 10:36 AM To: OpenStack Development Mailing List (not for usage questions); Antoni Segura Puimedon; Fawad Khaliq; Mohammad Banikazemi; Taku Fukushima; Irena Berezovsky; Mike Spreitzer Subject: Re: [openstack-dev] [magnum][kuryr] Shared session in design summit All these slots are fine with me, added Kuryr team as CC to make sure most can attend any of these times. On Wed, Mar 30, 2016 at 5:12 PM, Hongbin Lu wrote: Gal, Thursday 4:10 – 4:50 conflicts with a Magnum workroom session, but we can choose from: · 11:00 – 11:40 · 11:50 – 12:30 · 3:10 – 3:50 Please let us know if some of the slots don’t work well with your schedule. Best regards, Hongbin From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: March-30-16 2:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][kuryr] Shared session in design summit Anything you pick is fine with me, Kuryr fishbowl session is on Thursday 4:10 - 4:50, i personally think the Magnum integration is important enough and i dont mind using this time for the session as well. Either way i am also ok with the 11-11:40 and the 11:50-12:30 sessions or the 3:10-3:50 On Tue, Mar 29, 2016 at 11:32 PM, Hongbin Lu wrote: Hi all, As discussed before, our team members want to establish a shared session between Magnum and Kuryr. We expected a lot of attendees in the session so we need a large room (fishbowl). Currently, Kuryr has only 1 fishbowl session, and they possibly need it for other purposes. A solution is to promote one of the Magnum fishbowl session to be the shared session, or leverage one of the free fishbowl slot. The schedule is as below. Please vote your favorite time slot: http://doodle.com/poll/zuwercgnw2uecs5y . Magnum fishbowl session: · 11:00 - 11:40 (Thursday) · 11:50 - 12:30 · 1:30 - 2:10 · 2:20 - 3:00 · 3:10 - 3:50 Free fishbowl slots: · 9:00 – 9:40 (Thursday) · 9:50 – 10:30 · 3:10 – 3:50 (conflict with Magnum session) · 4:10 – 4:50 (conflict with Magnum session) · 5:00 – 5:40 (conflict with Magnum session) Best regards, Hongbin __ 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 , The G. __ 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 , The G. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstac
Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay
Run both Chronos and Marathon on Mesos and Run Chronos on top of Marathon seems two different cases. I think if #1 Add Chronos to the mesos bay , #2 is possible to archive that. Only if we find frameworks(heat templates) not able to handle that, we could use option #1. But still flexible is better, I think. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Guz Egor To: "OpenStack Development Mailing List (not for usage questions)" Date: 12/04/2016 04:36 am Subject:Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay +1 for "#1: Mesos and Marathon". Most deployments that I am aware of has this setup. Also we can provide several line instructions how to run Chronos on top of Marathon. honestly I don't see how #2 will work, because Marathon installation is different from Aurora installation. --- Egor From: Kai Qiang Wu To: OpenStack Development Mailing List (not for usage questions) Sent: Sunday, April 10, 2016 6:59 PM Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay #2 seems more flexible, and if it be proved it can "make the SAME mesos bay applied with mutilple frameworks." It would be great. Which means, one mesos bay should support multiple frameworks. Thanks Best Wishes, ------------ Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! Hongbin Lu ---11/04/2016 12:06:07 am---My preference is #1, but I don’t feel strong to exclude #2. I would agree to go with #2 for now and From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 11/04/2016 12:06 am Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay My preference is #1, but I don’t feel strong to exclude #2. I would agree to go with #2 for now and switch back to #1 if there is a demand from users. For Ton’s suggestion to push Marathon into the introduced configuration hook, I think it is a good idea. Best regards, Hongbin From: Ton Ngo [mailto:t...@us.ibm.com] Sent: April-10-16 11:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay I would agree that #2 is the most flexible option, providing a well defined path for additional frameworks such as Kubernetes and Swarm. I would suggest that the current Marathon framework be refactored to use this new hook, to serve as an example and to be the supported framework in Magnum. This will also be useful to users who want other frameworks but not Marathon. Ton, Adrian Otto ---04/08/2016 08:49:52 PM---On Apr 8, 2016, at 3:15 PM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: From: Adrian Otto To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: 04/08/2016 08:49 PM Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay On Apr 8, 2016, at 3:15 PM, Hongbin Lu wrote: Hi team, I would like to give an update for this thread. In the last team, we discussed several options to introduce Chronos to our mesos bay: 1. Add Chronos to the mesos bay. With this option, the mesos bay will have two mesos frameworks by default (Marathon and Chronos). 2. Add a configuration hook for users to configure additional mesos frameworks, such as Chronos. With this option, Magnum team doesn’t need to maintain extra framework configuration. However, users need to do it themselves. This is my preference. Adrian 3. Create a dedicated bay type for Chronos. With this option, we separate Marathon and Chronos into two different bay types. As a result, each bay type becomes easier to maintain, but those two mesos framework cannot share resources (a key feature of mesos is to have different frameworks running on the same cluster to increase resource utilization).Which option you prefer? Or you have other suggestions? Advices are welcome. Best regards, Hongbin From: Guz Egor [mailto:guz_e...@yahoo.com] Sent: March-28-16 12:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay Jay
Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay
#2 seems more flexible, and if it be proved it can "make the SAME mesos bay applied with mutilple frameworks." It would be great. Which means, one mesos bay should support multiple frameworks. Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 11/04/2016 12:06 am Subject:Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay My preference is #1, but I don’t feel strong to exclude #2. I would agree to go with #2 for now and switch back to #1 if there is a demand from users. For Ton’s suggestion to push Marathon into the introduced configuration hook, I think it is a good idea. Best regards, Hongbin From: Ton Ngo [mailto:t...@us.ibm.com] Sent: April-10-16 11:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay I would agree that #2 is the most flexible option, providing a well defined path for additional frameworks such as Kubernetes and Swarm. I would suggest that the current Marathon framework be refactored to use this new hook, to serve as an example and to be the supported framework in Magnum. This will also be useful to users who want other frameworks but not Marathon. Ton, Inactive hide details for Adrian Otto ---04/08/2016 08:49:52 PM---On Apr 8, 2016, at 3:15 PM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: From: Adrian Otto To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: 04/08/2016 08:49 PM Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay On Apr 8, 2016, at 3:15 PM, Hongbin Lu wrote: Hi team, I would like to give an update for this thread. In the last team, we discussed several options to introduce Chronos to our mesos bay: 1. Add Chronos to the mesos bay. With this option, the mesos bay will have two mesos frameworks by default (Marathon and Chronos). 2. Add a configuration hook for users to configure additional mesos frameworks, such as Chronos. With this option, Magnum team doesn’t need to maintain extra framework configuration. However, users need to do it themselves. This is my preference. Adrian 3. Create a dedicated bay type for Chronos. With this option, we separate Marathon and Chronos into two different bay types. As a result, each bay type becomes easier to maintain, but those two mesos framework cannot share resources (a key feature of mesos is to have different frameworks running on the same cluster to increase resource utilization). Which option you prefer? Or you have other suggestions? Advices are welcome. Best regards, Hongbin From: Guz Egor [mailto:guz_e...@yahoo.com] Sent: March-28-16 12:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay Jay, just keep in mind that Chronos can be run by Marathon. --- Egor From: Jay Lau To: OpenStack Development Mailing List (not for usage questions) Sent: Friday, March 25, 2016 7:01 PM Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay Yes, that's exactly what I want to do, adding dcos cli and also add Chronos to Mesos Bay to make it can handle both long running services and batch jobs. Thanks, On Fri, Mar 25, 2016 at 5:25 PM, Michal Rostecki < michal.roste...@gmail.com> wrote: On 03/25/2016 07:57 AM, Jay Lau wrote: Hi Magnum, The current mesos bay only include mesos and marathon, it is better to enhance the mesos bay have more components and finally enhance it to a DCOS which focus on container service based on
Re: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core reviewer team
+ 1 for Eli :) Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 01/04/2016 02:20 am Subject:[openstack-dev] [magnum] Proposing Eli Qiao for Magnum core reviewer team Hi all, Eli Qiao has been consistently contributed to Magnum for a while. His contribution started from about 10 months ago. Along the way, he implemented several important blueprints and fixed a lot of bugs. His contribution covers various aspects (i.e. APIs, conductor, unit/functional tests, all the COE templates, etc.), which shows that he has a good understanding of almost every pieces of the system. The feature set he contributed to is proven to be beneficial to the project. For example, the gate testing framework he heavily contributed to is what we rely on every days. His code reviews are also consistent and useful. I am happy to propose Eli Qiao to be a core reviewer of Magnum team. According to the OpenStack Governance process [1], we require a minimum of 4 +1 votes within a 1 week voting window (consider this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get enough votes or there is a veto vote prior to the end of the voting window, Eli is not able to join the core team and needs to wait 30 days to reapply. The voting is open until Thursday April 7st. [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Best regards, Hongbin __ 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
Re: [openstack-dev] [magnum] Discuss the blueprint"support-private-registry"
I agree to that support-private-registry should be secure. As insecure seems not much useful for production use. Also I understood the point setup related CA could be diffcult than normal HTTP, but we want to know if https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig Could address the issue and make templates clearer to understood ? If related patch or spec proposed, we are glad to review and make it better. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Ricardo Rocha To: "OpenStack Development Mailing List (not for usage questions)" Date: 30/03/2016 09:09 pm Subject:Re: [openstack-dev] [magnum] Discuss the blueprint "support-private-registry" Hi. On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao wrote: > > Hi Hongbin > > Thanks for starting this thread, > > > > I initial propose this bp because I am in China which is behind China great > wall and can not have access of gcr.io directly, after checking our > cloud-init script, I see that > > lots of code are *hard coded* to using gcr.io, I personally though this is > not good idea. We can not force user/customer to have internet access in > their environment. > > I proposed to use insecure-registry to give customer/user (Chinese or whom > doesn't have gcr.io access) a chance to switch use their own > insecure-registry to deploy > k8s/swarm bay. > > For your question: >> Is the private registry secure or insecure? If secure, how to handle >> the authentication secrets. If insecure, is it OK to connect a secure bay to >> an insecure registry? > An insecure-resigtry should be 'secure' one, since customer need to setup it > and make sure it's clear one and in this case, they could be a private > cloud. > >> Should we provide an instruction for users to pre-install the private >> registry? If not, how to verify the correctness of this feature? > > The simply way to pre-install private registry is using insecure-resigtry > and docker.io has very simple steps to start it [1] > for other, docker registry v2 also supports using TLS enable mode but this > will require to tell docker client key and crt file which will make > "support-private-registry" complex. > > [1] https://docs.docker.com/registry/ > [2]https://docs.docker.com/registry/deploying/ 'support-private-registry' and 'allow-insecure-registry' sound different to me. We're using an internal docker registry at CERN (v2, TLS enabled), and have the magnum nodes setup to use it. We just install our CA certificates in the nodes (cp to etc/pki/ca-trust/source/anchors/, update-ca-trust) - had to change the HEAT templates for that, and submitted a blueprint to be able to do similar things in a cleaner way: https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig That's all that is needed, the images are then prefixed with the registry dns location when referenced - example: docker.cern.ch/my-fancy-image. Things we found on the way: - registry v2 doesn't seem to allow anonymous pulls (you can always add an account with read-only access everywhere, but it means you need to always authenticate at least with this account) https://github.com/docker/docker/issues/17317 - swarm 1.1 and kub8s 1.0 allow authentication to the registry from the client (which was good news, and it works fine), handy if you want to push/pull with authentication. Cheers, Ricardo > > > > On 2016年03月30日 07:23, Hongbin Lu wrote: > > Hi team, > > > > This is the item we didn’t have time to discuss in our team meeting, so I > started the discussion in here. > > > > Here is the blueprint: > https://blueprints.launchpad.net/magnum/+spec/support-private-registry . Per > my understanding, the goal of the BP is to allow users to specify the url of > their private docker registry where the bays pull the kube/swarm images (if > they are not able to access docker hub or other public registry). An > assumption is that users need to pre-install their own private registry and > upload all the required images to there. There are several potential issues > of this proposal: > > ・ Is the private registry secure or insecure? If secure, how to > handle the authent
Re: [openstack-dev] [magnum] Generate atomic images usingdiskimage-builder
1) +1 diskimage-builder maybe a better place to external consumption. 2) For the image size difference(big), I think we may need to know what's the issue for that. Maybe Redhat guys know something about it. Thanks Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Ton Ngo" To: "OpenStack Development Mailing List \(not for usage questions \)" Date: 24/03/2016 01:12 am Subject:Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder Hi Yolanda, Thank you for making a huge improvement from the manual process of building the Fedora Atomic image. Although Atomic does publish a public OpenStack image that is being considered in this patch: https://review.openstack.org/#/c/276232/ in the past we have come to many situations where we need an image with specific version of certain software for features or bug fixes (Kubernetes, Docker, Flannel, ...). So the automated and customizable build process will be very helpful. With respect to where to land the patch, I think diskimage-builder is a reasonable target. If it does not land there, Magnum does currently have 2 sets of diskimage-builder elements for Mesos image and Ironic image, so it is also reasonable to submit the patch to Magnum. With the new push to reorganize into drivers for COE and distro, the elements would be a natural fit for Fedora Atomic. As for periodic image build, it's a good idea to stay current with the distro, but we should avoid the situation where something new in the image breaks a COE and we are stuck for awhile until a fix is made. So instead of an automated periodic build, we might want to stage the new image to make sure it's good before switching. One question: I notice the image built by DIB is 871MB, similar to the manually built image, while the public image from Atomic is 486MB. It might be worthwhile to understand the difference. Ton Ngo, Inactive hide details for Yolanda Robla Mota ---03/23/2016 04:12:54 AM---Hi I wanted to start a discussion on how Fedora AtomicYolanda Robla Mota ---03/23/2016 04:12:54 AM---Hi I wanted to start a discussion on how Fedora Atomic images are being From: Yolanda Robla Mota To: Date: 03/23/2016 04:12 AM Subject: [openstack-dev] [magnum] Generate atomic images using diskimage-builder Hi I wanted to start a discussion on how Fedora Atomic images are being built. Currently the process for generating the atomic images used on Magnum is described here: http://docs.openstack.org/developer/magnum/dev/build-atomic-image.html. The image needs to be built manually, uploaded to fedorapeople, and then consumed from there in the magnum tests. I have been working on a feature to allow diskimage-builder to generate these images. The code that makes it possible is here: https://review.openstack.org/287167 This will allow that magnum images are generated on infra, using diskimage-builder element. This element also has the ability to consume any tree we need, so images can be customized on demand. I generated one image using this element, and uploaded to fedora people. The image has passed tests, and has been validated by several people. So i'm raising that topic to decide what should be the next steps. This change to generate fedora-atomic images has not already landed into diskimage-builder. But we have two options here: - add this element to generic diskimage-builder elements, as i'm doing now - generate this element internally on magnum. So we can have a directory in magnum project, called "elements", and have the fedora-atomic element here. This will give us more control on the element behaviour, and will allow to update the element without waiting for external reviews. Once the code for diskimage-builder has landed, another step can be to periodically generate images using a magnum job, and upload these images to OpenStack Infra mirrors. Currently the image is based on Fedora F23, docker-host tree. But different images can be generated if we need a better option. As soon as the images are available on internal infra mirrors, the tests can be changed, to consume these internals images. By this way the tests can be a bit faster (i know that the bottleneck is on the functional testing, but if we reduce the download time it can help), and tests can be more reilable, because we will be removing an external dependency. So i'd like to get more feedback on this topic, options and next steps to achieve the goals. Best -- Yolanda Robla M
Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
HI Steve, Some points to highlight here: 1> There are some work discussion about COE dynamic supports across different OS distro. 2> For atomic, we did have many requirements before, it was an old story, seem some not meet our needs (which once asked in atomic IRC channel or community) So we built some images by ourselves. But if atomic community could provide related support, it would more beneficial for both( as we use it, it would be tested by us daily jenkins and developers) Maybe for the requirements, need some clear channel, like: 1> What's the official channel to open requirements to Atomic community ? Is it github or something else which can easily track ? 2> What's the normal process to deal with such requirements, and coordinate ways. 3> Others Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Steve Gordon To: "OpenStack Development Mailing List (not for usage questions)" Date: 17/03/2016 09:24 pm Subject:Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro ----- Original Message - > From: "Kai Qiang Wu" > To: "OpenStack Development Mailing List (not for usage questions)" > Sent: Tuesday, March 15, 2016 3:20:46 PM > Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro > > Hi Stdake, > > There is a patch about Atomic 23 support in Magnum. And atomic 23 uses > kubernetes 1.0.6, and docker 1.9.1. > From Steve Gordon, I learnt they did have a two-weekly release. To me it > seems each atomic 23 release not much difference, (minor change) > The major rebases/updates may still have to wait for e.g. Fedora Atomic 24. Well, the emphasis here is on *may*. As was pointed out in that same thread [1] rebases certainly can occur although those builds need to get karma in the fedora build system to be pushed into updates and subsequently included in the next rebuild (e.g. see [2] for a newer K8S build). The main point is that if a rebase involves introducing some element of backwards incompatibility then that would have to wait to the next major (F24) - outside of that there is some flexibility. > So maybe we not need to test every Atomic 23 two-weekly. > Pick one or update old, when we find it is integrated with new kubernetes > or docker, etcd etc. If other small changes(not include security), seems > not need to update so frequently, it can save some efforts. A question I have posed before and that I think will need to be answered if Magnum is indeed to move towards the model for handling drivers proposed in this thread is what are the expectations Magnum has for each image/coe combination in terms of versions of key components for a given Magnum release, and what are the expectations Magnum has for same when looking forwards to say Newton. Based on our discussion it seemed like there were some issues that mean kubernetes-1.1.0 would be preferable for example (although that it wasn't there was in fact itself a bug it would seem, but regardless it's a valid example), but is that expectation documented somewhere? It seems like based on feature roadmap it should be possible to at least put forward minimum required versions for key components (e.g. docker, k8s, flanel, etcd for the K8S COE)? This would make it easier to guide the relevant upstreams to ensure their images support the Magnum team's needs and at least minimize the need to do custom builds if not eliminate it. -Steve [1] https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/ZJARDKSB3KGMKLACCZSQALZHV54PAJUB/ [2] https://bodhi.fedoraproject.org/updates/FEDORA-2016-a89f5ce5f4 > From: "Steven Dake (stdake)" > To:"OpenStack Development Mailing List (not for usage questions)" > > Date: 16/03/2016 03:23 am > Subject: Re: [openstack-dev] [magnum] Discussion of supporting > single/multiple OS distro > > > > WFM as long as we stick to the spirit of the proposal and don't end up in a > situation where there is only one distribution. Others in the thread had > indicated there would be only one distribution in tree, which I'd find > disturbing for reasons already described on this thread. > > While we are about it, we should move to the latest version of atomic and > chase atomic every two week
Re: [openstack-dev] [Magnum] COE drivers spec
Here are some of my raw points, 1. For the driver mentioned, I think we not necessary use bay-driver here, as have network-driver, volume-driver, maybe it is not needed to introduce driver in bay level.(bay is higher level than network or volume) maybe like coes/ swarm/ mesos/ kubernetes Each coes include, take swarm as example, coes/ swarm/ default/ contrib/ Or we not use contrib here, just like (one is support by default, others are contributed by more contributors and tested in jenkins pipeline) coes/ swarm/ atomic/ ubuntu/ We have BaseCoE, other specific CoE inherit from that, Each CoE have related life management operations, like Create, Update, Get, Delete life cycle management. 2. We need to think more about scale manager, which involves scale cluster up and down, Maybe a related auto-scale and manual scale ways. The user cases, like as a Cloud Administrator, I could easily use OpenStack to provide CoEs cluster, and manage CoE life cycle. and scale CoEs. CoEs could do its best to use OpenStack network, and volume services to provide CoE related network, volume support. Others interesting case(not required), if user just want to deploy one container in Magnum, we schedule it to the right CoE, (if user manual specify, it would schedule to the specific CoE) Or more user cases . Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Jamie Hannaford To: "openstack-dev@lists.openstack.org" Date: 17/03/2016 07:24 pm Subject:[openstack-dev] [Magnum] COE drivers spec Hi all, I'm writing the spec for the COE drivers, and I wanted some feedback about what it should include. I'm trying to reconstruct some of the discussion that was had at the mid-cycle meet-up, but since I wasn't there I need to rely on people who were :) From my perspective, the spec should recommend the following: 1. Change the BayModel `coe` attribute to `bay_driver`, the value of which will correspond to the name of the directory where the COE code will reside, i.e. drivers/{driver_name} 2. Introduce a base Driver class that each COE driver extends. This would reside in the drivers dir too. This base driver will specify the interface for interacting with a Bay. The following operations would need to be defined by each COE driver: Get, Create, List, List detailed, Update, Delete. Each COE driver would implement each operation differently depending on their needs, but would satisfy the base interface. The base class would also contain common logic to avoid code duplication. Any operations that fall outside this interface would not exist in the COE driver class, but rather an extension situated elsewhere. The JSON payloads for requests would differ from COE to COE. Cinder already uses this approach to great effect for volume drivers: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/lvm.py https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py Question: Is this base class a feasible idea for Magnum? If so, do we need any other operations in the base class that I haven't mentioned? 3. Each COE driver would have its own Heat template for creating a bay node. It would also have a template definition that lists the JSON parameters which are fed into the Heat template. Question: From a very top-level POV, what logic or codebase changes would Magnum need Heat templates in the above way? 4. Removal of all old code that does not fit the above paradigm. --- Any custom COE operations that are not common Bay operations (i.e. the six listed in #2) would reside in a COE extension. This is outside of the scope of the COE drivers spec and would require an entirely different spec that utilizes a common paradigm for extensions in OpenStack. Such a spec would also need to cover how the conductor would link off to each COE. Is this summary correct? Does Magnum already have a scale manager? If not, should this be introduced as a separate BP/spec? Is there anything else that a COE drivers spec need to cover which I have not mentioned? Jamie Rackspace International GmbH a company registered in the Canton of Zurich, Switzerland (company identification number CH-020.4.047.077-1) whose registered office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace International GmbH privacy policy can be viewed at www.rackspace.co.uk/legal/swiss-privacy-policy - This e-mail message may contain confidential or privileged information i
Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
Hi Stdake, There is a patch about Atomic 23 support in Magnum. And atomic 23 uses kubernetes 1.0.6, and docker 1.9.1. >From Steve Gordon, I learnt they did have a two-weekly release. To me it seems each atomic 23 release not much difference, (minor change) The major rebases/updates may still have to wait for e.g. Fedora Atomic 24. So maybe we not need to test every Atomic 23 two-weekly. Pick one or update old, when we find it is integrated with new kubernetes or docker, etcd etc. If other small changes(not include security), seems not need to update so frequently, it can save some efforts. What do you think ? Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Steven Dake (stdake)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 16/03/2016 03:23 am Subject:Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro WFM as long as we stick to the spirit of the proposal and don't end up in a situation where there is only one distribution. Others in the thread had indicated there would be only one distribution in tree, which I'd find disturbing for reasons already described on this thread. While we are about it, we should move to the latest version of atomic and chase atomic every two weeks on their release. Thoughts? Regards -steve From: Hongbin Lu Reply-To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: Monday, March 14, 2016 at 8:10 PM To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: March-14-16 4:49 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro Steve, I think you may have misunderstood our intent here. We are not seeking to lock in to a single OS vendor. Each COE driver can have a different OS. We can have multiple drivers per COE. The point is that drivers should be simple, and therefore should support one Bay node OS each. That would mean taking what we have today in our Kubernetes Bay type implementation and breaking it down into two drivers: one for CoreOS and another for Fedora/Atomic. New drivers would start out in a contrib directory where complete functional testing would not be required. In order to graduate one out of contrib and into the realm of support of the Magnum dev team, it would need to have a full set of tests, and someone actively maintaining it. OK. It sounds like the proposal allows more than one OS to be in-tree, as long as the second OS goes through an incubation process. If that is what you mean, it sounds reasonable to me. Multi-personality driers would be relatively complex. That approach would slow down COE specific feature development, and complicate maintenance that is needed as new versions of the dependency chain are bundled in (docker, k8s, etcd, etc.). We have all agreed that having integration points that allow for alternate OS selection is still our direction. This follows the pattern that we set previously when deciding what networking options to support. We will have one that’s included as a default, and a way to plug in alternates. Here is what I expect to see when COE drivers are implemented: Docker Swarm: Default driver Fedora/Atomic Alternate driver: TBD Kubernetes: Default driver Fedora/Atomic Alternate driver: CoreOS Apache Mesos/Marathon: Default driver: Ubuntu Alternate driver: TBD We can allow an arbitrary number of alternates. Those TBD items can be initially added to the contrib directory, and with the right level of community support can be advanced to defaults if shown to work better, be more straightforward to maintain, be more secure, or whatever crite
Re: [openstack-dev] [magnum-ui] Proposed Core addition, and removal notice
+1, Really good contribution. :) Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: 大�V元央 To: "OpenStack Development Mailing List (not for usage questions)" Date: 05/03/2016 06:25 pm Subject:Re: [openstack-dev] [magnum-ui] Proposed Core addition, and removal notice +1, welcome Shu. -Yuanying On Sat, Mar 5, 2016 at 09:37 Bradley Jones (bradjone) wrote: +1 Shu has done some great work in magnum-ui and will be a welcome addition to the core team. Thanks, Brad > On 5 Mar 2016, at 00:29, Adrian Otto wrote: > > Magnum UI Cores, > > I propose the following changes to the magnum-ui core group [1]: > > + Shu Muto > - Dims (Davanum Srinivas), by request - justified by reduced activity level. > > Please respond with your +1 votes to approve this change or -1 votes to oppose. > > Thanks, > > Adrian > __ > 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 __ 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
Re: [openstack-dev] [keystone][nova] Many same "region_name" configuration really meaingful for Multi-region customers?
Hi, From my previous 3K+ nodes 6+ regions OpenStack operations experience in Yandex, I found useless to have Cinder and Neutron services in cross-region manner. BTW, nova-neutron cross-region interactions are still legitimate use case: you may utilize one neutron for many nova regions. >>> Sorry not quite understand here. Do you mean you want this feature cross-region(nova-neutron) ? Or it has been supported now in Openstack nova, neutron ? -- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. On Mar 4, 2016, at 7:43 AM, Dolph Mathews wrote: Unless someone on the operations side wants to speak up and defend cross-region nova-cinder or nova-neutron interactions as being a legitimate use case, I'd be in favor of a single region identifier. However, both of these configuration blocks should ultimately be used to configure keystoneauth, so I would be in favor of whatever solution simplifies configuration for keystoneauth. On Tue, Mar 1, 2016 at 10:01 PM, Kai Qiang Wu wrote: Hi All, Right now, we found that nova.conf have many places for region_name configuration. Check below: nova.conf *** [cinder] os_region_name = *** [neutron] region_name= *** *** From some mult-region environments observation, those two regions would always config same value. Question 1: Does nova support config different regions in nova.conf ? Like below [cinder] os_region_name = RegionOne [neutron] region_name= RegionTwo From Keystone point, I suspect those regions can access from each other. Question 2: If all need to config with same value, why we not use single region_name in nova.conf ? (instead of create many region_name in same file ) Is it just for code maintenance or else consideration ? Could nova and keystone community members help this question ? Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! __ 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 (See attached file: signature.asc) __ 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 signature.asc Description: Binary data __ 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] [keystone][nova] Many same "region_name" configuration really meaingful for Multi-region customers?
Hi Dolph, It seems use one configuration could simply like below: nova.conf: ** client_region_name = RegionOne All clients would use that region instead of create many different section/properties(what nova do now) for that. But I'd like to hear what's nova/keystone developers option for that. Why we design like that ? :) Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Dolph Mathews To: "OpenStack Development Mailing List (not for usage questions)" Date: 04/03/2016 12:46 pm Subject:Re: [openstack-dev] [keystone][nova] Many same "region_name" configuration really meaingful for Multi-region customers? Unless someone on the operations side wants to speak up and defend cross-region nova-cinder or nova-neutron interactions as being a legitimate use case, I'd be in favor of a single region identifier. However, both of these configuration blocks should ultimately be used to configure keystoneauth, so I would be in favor of whatever solution simplifies configuration for keystoneauth. On Tue, Mar 1, 2016 at 10:01 PM, Kai Qiang Wu wrote: Hi All, Right now, we found that nova.conf have many places for region_name configuration. Check below: nova.conf *** [cinder] os_region_name = *** [neutron] region_name= *** *** From some mult-region environments observation, those two regions would always config same value. Question 1: Does nova support config different regions in nova.conf ? Like below [cinder] os_region_name = RegionOne [neutron] region_name= RegionTwo From Keystone point, I suspect those regions can access from each other. Question 2: If all need to config with same value, why we not use single region_name in nova.conf ? (instead of create many region_name in same file ) Is it just for code maintenance or else consideration ? Could nova and keystone community members help this question ? Thanks Best Wishes, ------------ Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! __ 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 __ 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] [keystone][nova] Many same "region_name" configuration really meaingful for Multi-region customers?
Hi All, Right now, we found that nova.conf have many places for region_name configuration. Check below: nova.conf *** [cinder] os_region_name = *** [neutron] region_name= *** *** From some mult-region environments observation, those two regions would always config same value. Question 1: Does nova support config different regions in nova.conf ? Like below [cinder] os_region_name = RegionOne [neutron] region_name= RegionTwo From Keystone point, I suspect those regions can access from each other. Question 2: If all need to config with same value, why we not use single region_name in nova.conf ? (instead of create many region_name in same file ) Is it just for code maintenance or else consideration ? Could nova and keystone community members help this question ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! __ 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] [magnum] Discussion of supporting single/multiple OS distro
I tend to agree that multiple os support is OK (we can limited to popular ones first, like redhat os, ubuntu os) But we not tend to cover all OS, it would much burden for maintain, and extra small requirements should be maintain by 3-rd party if possible(through drivers). Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Steve Gordon To: "OpenStack Development Mailing List (not for usage questions)" Cc: Martin Andre , Josh Berkus Date: 01/03/2016 08:25 pm Subject:Re: [openstack-dev] [magnum]Discussion of supporting single/multiple OS distro - Original Message - > From: "Steve Gordon" > To: "Guz Egor" , "OpenStack Development Mailing List (not for usage questions)" > > > - Original Message - > > From: "Guz Egor" > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > > > Adrian, > > I disagree, host OS is very important for operators because of integration > > with all internal tools/repos/etc. > > I think it make sense to limit OS support in Magnum main source. But not > > sure > > that Fedora Atomic is right choice,first of all there is no documentation > > about it and I don't think it's used/tested a lot by Docker/Kub/Mesos > > community. > > Project Atomic documentation for the most part lives here: > > http://www.projectatomic.io/docs/ > > To help us improve it, it would be useful to know what you think is missing. > E.g. I saw recently in the IRC channel it was discussed that there is no > documentation on (re)building the image but this is the first hit in a > Google search for same and it seems to largely match what has been copied > into Magnum's docs for same: > > http://www.projectatomic.io/blog/2014/08/build-your-own-atomic-centos-or-fedora/ > > I have no doubt that there are areas where the documentation is lacking, but > it's difficult to resolve a claim that there is no documentation at all. I > recently kicked off a thread over on the atomic list to try and relay some > of the concerns that were raised on this list and in the IRC channel > recently, it would be great if Magnum folks could chime in with more > specifics: > > https://lists.projectatomic.io/projectatomic-archives/atomic/2016-February/thread.html#9 > > Separately I had asked about containerization of kubernetes/etcd/flannel > which remains outstanding: > > https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/XICO4NJCTPI43AWG332EIM2HNFYPZ6ON/ > > Fedora Atomic builds do seem to be hitting their planned two weekly update > cadence now though which may alleviate this concern at least somewhat in the > interim: > > https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/CW5BQS3ODAVYJGAJGAZ6UA3XQMKEISVJ/ > https://fedorahosted.org/cloud/ticket/139 > > Thanks, > > Steve I meant to add, I don't believe choosing a single operating system image to support - regardless of which it is - is the right move for users and largely agree with what Ton Ngo put forward in his most recent post in the thread. I'm simply highlighting that there are folks willing/able to work on improving things from the Atomic side and we are endeavoring to provide them actionable feedback from the Magnum community to do so. Thanks, Steve > > It make sense to go with Ubuntu (I believe it's still most adopted > > platform in all three COEs and OpenStack deployments) and CoreOS (is > > highly adopted/tested in Kub community and Mesosphere DCOS uses it as > > well). > > We can implement CoreOS support as driver and users can use it as > > reference > > implementation. > > > > --- Egor > > From: Adrian Otto > > To: OpenStack Development Mailing List (not for usage questions) > > > > Sent: Monday, February 29, 2016 10:36 AM > > Subject: Re: [openstack-dev] [magnum] Discussion of supporting > > single/multiple OS distro > > > > Consider this: Which OS runs on the bay nodes is not important to end > > users. > > What matters to users is the environments their containers execute in, > > which > > has onl
Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro
We found some issue about atomic host run some docker volume plugin, while atomic and docker volume plugin both not sure what's the root cause of that. here is the link https://github.com/docker/docker/issues/18005#issuecomment-190215862 Also I did not find atomic image update quickly, ( but k8s and docker both release quickly, which can lacks of new feature applied in our development), I think atomic have a gap for that. Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Steve Gordon To: Guz Egor , "OpenStack Development Mailing List (not for usage questions)" Cc: Josh Berkus Date: 01/03/2016 08:19 pm Subject:Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro - Original Message - > From: "Guz Egor" > To: "OpenStack Development Mailing List (not for usage questions)" > > Adrian, > I disagree, host OS is very important for operators because of integration > with all internal tools/repos/etc. > I think it make sense to limit OS support in Magnum main source. But not sure > that Fedora Atomic is right choice,first of all there is no documentation > about it and I don't think it's used/tested a lot by Docker/Kub/Mesos > community. Project Atomic documentation for the most part lives here: http://www.projectatomic.io/docs/ To help us improve it, it would be useful to know what you think is missing. E.g. I saw recently in the IRC channel it was discussed that there is no documentation on (re)building the image but this is the first hit in a Google search for same and it seems to largely match what has been copied into Magnum's docs for same: http://www.projectatomic.io/blog/2014/08/build-your-own-atomic-centos-or-fedora/ I have no doubt that there are areas where the documentation is lacking, but it's difficult to resolve a claim that there is no documentation at all. I recently kicked off a thread over on the atomic list to try and relay some of the concerns that were raised on this list and in the IRC channel recently, it would be great if Magnum folks could chime in with more specifics: https://lists.projectatomic.io/projectatomic-archives/atomic/2016-February/thread.html#9 Separately I had asked about containerization of kubernetes/etcd/flannel which remains outstanding: https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/XICO4NJCTPI43AWG332EIM2HNFYPZ6ON/ Fedora Atomic builds do seem to be hitting their planned two weekly update cadence now though which may alleviate this concern at least somewhat in the interim: https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/CW5BQS3ODAVYJGAJGAZ6UA3XQMKEISVJ/ https://fedorahosted.org/cloud/ticket/139 Thanks, Steve > It make sense to go with Ubuntu (I believe it's still most adopted > platform in all three COEs and OpenStack deployments) and CoreOS (is > highly adopted/tested in Kub community and Mesosphere DCOS uses it as well). > We can implement CoreOS support as driver and users can use it as reference > implementation. > --- Egor > From: Adrian Otto > To: OpenStack Development Mailing List (not for usage questions) > > Sent: Monday, February 29, 2016 10:36 AM > Subject: Re: [openstack-dev] [magnum] Discussion of supporting > single/multiple OS distro > > Consider this: Which OS runs on the bay nodes is not important to end users. > What matters to users is the environments their containers execute in, which > has only one thing in common with the bay node OS: the kernel. The linux > syscall interface is stable enough that the various linux distributions can > all run concurrently in neighboring containers sharing same kernel. There is > really no material reason why the bay OS choice must match what distro the > container is based on. Although I’m persuaded by Hongbin’s concern to > mitigate risk of future changes WRT whatever OS distro is the prevailing one > for bay nodes, there are a few items of concern about duality I’d like to > zero in on: > 1) Participation from Magnum contributors to support the CoreOS specific > template features has been weak in recent months. By comparison, > participation relating to Fedora/Atomic have been much stronger. > 2) Properly testing multiple bay node OS distros (would) significantly > incr
Re: [openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id)
Thanks Hongbin for your info. I really think it is not good way for new feature introduced. As new feature introduced often break old work. it more often better with add-in feature is plus, old work still funciton. Or at least, the error should say "swarm bay now requires trust to work, please use trust related access information before deploy a new swarm bay" Thanks -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 26/02/2016 08:02 am Subject:[openstack-dev] [magnum] Failed to create trustee %(username) in domain $(domain_id) Hi team, FYI, you might encounter the following error if you pull from master recently: magnum bay-create --name swarmbay --baymodel swarmbaymodel --node-count 1 Create for bay swarmbay failed: Failed to create trustee %(username) in domain $(domain_id) (HTTP 500)" This is due to a recent commit that added support for trust. In case you don’t know, this error can be resolved by running the following steps: # 1. create the necessary domain and user: export OS_TOKEN=password export OS_URL=http://127.0.0.1:5000/v3 export OS_IDENTITY_API_VERSION=3 openstack domain create magnum openstack user create trustee_domain_admin --password=secret --domain=magnum openstack role add --user=trustee_domain_admin --domain=magnum admin # 2. populate configs source /opt/stack/devstack/functions export MAGNUM_CONF=/etc/magnum/magnum.conf iniset $MAGNUM_CONF trust trustee_domain_id $(openstack domain show magnum | awk '/ id /{print $4}') iniset $MAGNUM_CONF trust trustee_domain_admin_id $(openstack user show trustee_domain_admin | awk '/ id /{print $4}') iniset $MAGNUM_CONF trust trustee_domain_admin_password secret # 3. screen -r stack, and restart m-api and m-cond __ 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
Re: [openstack-dev] [magnum]swarm + compose = k8s?
HongBin, See my replies and questions in line. >> Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 15/02/2016 01:26 am Subject:Re: [openstack-dev] [magnum]swarm + compose = k8s? Kai Qiang, A major benefit is to have Magnum manage the COEs for end-users. Currently, Magnum basically have its end-users manage the COEs by themselves after a successful deployment. This might work well for domain users, but it is a pain for non-domain users to manage their COEs. By moving master nodes out of users’ tenants, Magnum could offer users a COE management service. For example, Magnum could offer to monitor the etcd/swarm-manage clusters and recover them on failure. Again, the pattern of managing COEs for end-users is what Google container service and AWS container service offer. I guess it is fair to conclude that there are use cases out there? >> I am not sure when you talked about domain here, is it keystone domain or other case ? What's the non-domain users case to manage the COEs? If we decide to offer a COE management service, we could discuss further on how to consolidate the IaaS resources for improving utilization. Solutions could be (i) introducing a centralized control services for all tenants/clusters, or (ii) keeping the control services separated but isolating them by containers (instead of VMs). A typical use case is what Kris mentioned below. >> for (i) it is more complicated than (ii), and I did not see much benefits gain for utilization case here for (i), instead it could introduce much burden for upgrade case and service interference for all tenants/clusters Best regards, Hongbin From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: February-13-16 11:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Hi HongBin and Egor, I went through what you talked about, and thinking what's the great benefits for utilisation here. For user cases, looks like following: user A want to have a COE provision. user B want to have a separate COE. (different tenant, non-share) user C want to use existed COE (same tenant as User A, share) When you talked about utilisation case, it seems you mentioned: different tenant users want to use same control node to manage different nodes, it seems that try to make COE openstack tenant aware, it also means you want to introduce another control schedule layer above the COEs, we need to think about the if it is typical user case, and what's the benefit compared with containerisation. And finally, it is a topic can be discussed in middle cycle meeting. Thanks Best Wishes, ------------ Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! Inactive hide details for Hongbin Lu ---13/02/2016 11:02:13 am---Egor, Thanks for sharing your insights. I gave it more thoughtHongbin Lu ---13/02/2016 11:02:13 am---Egor, Thanks for sharing your insights. I gave it more thoughts. Maybe the goal can be achieved with From: Hongbin Lu To: Guz Egor , "OpenStack Development Mailing List (not for usage questions)" Date: 13/02/2016 11:02 am Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Egor, Thanks for sharing your insights. I gave it more thoughts. Maybe the goal can be achieved without implementing a shared COE. We could move all the master nodes out of user tenants, containerize them, and consolidate them into a set of VMs/Physical servers. I think we could separate the discussion into two: 1. Should Magnum introduce a new bay type, in which master nodes are managed by Magnum (not users themselves)? Like what GCE [1] or ECS [2] does. 2. How to consolidate the control services that originally runs on master nodes of each cluster? Note that the proposal is for adding a new COE (not for changing the existing COEs). That means users will continue to provision existing self-managed COE (k8s/swarm/mesos) if they choose to. [1] https://cloud.google
Re: [openstack-dev] [magnum]swarm + compose = k8s?
Hi HongBin and Egor, I went through what you talked about, and thinking what's the great benefits for utilisation here. For user cases, looks like following: user A want to have a COE provision. user B want to have a separate COE. (different tenant, non-share) user C want to use existed COE (same tenant as User A, share) When you talked about utilisation case, it seems you mentioned: different tenant users want to use same control node to manage different nodes, it seems that try to make COE openstack tenant aware, it also means you want to introduce another control schedule layer above the COEs, we need to think about the if it is typical user case, and what's the benefit compared with containerisation. And finally, it is a topic can be discussed in middle cycle meeting. Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: Guz Egor , "OpenStack Development Mailing List (not for usage questions)" Date: 13/02/2016 11:02 am Subject:Re: [openstack-dev] [magnum]swarm + compose = k8s? Egor, Thanks for sharing your insights. I gave it more thoughts. Maybe the goal can be achieved without implementing a shared COE. We could move all the master nodes out of user tenants, containerize them, and consolidate them into a set of VMs/Physical servers. I think we could separate the discussion into two: 1. Should Magnum introduce a new bay type, in which master nodes are managed by Magnum (not users themselves)? Like what GCE [1] or ECS [2] does. 2. How to consolidate the control services that originally runs on master nodes of each cluster? Note that the proposal is for adding a new COE (not for changing the existing COEs). That means users will continue to provision existing self-managed COE (k8s/swarm/mesos) if they choose to. [1] https://cloud.google.com/container-engine/ [2] http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html Best regards, Hongbin From: Guz Egor [mailto:guz_e...@yahoo.com] Sent: February-12-16 2:34 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Hongbin Lu Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Hongbin, I am not sure that it's good idea, it looks you propose Magnum enter to "schedulers war" (personally I tired from these debates Mesos vs Kub vs Swarm). If your concern is just utilization you can always run control plane at "agent/slave" nodes, there main reason why operators (at least in our case) keep them separate because they need different attention (e.g. I almost don't care why/when "agent/slave" node died, but always double check that master node was repaired or replaced). One use case I see for shared COE (at least in our environment), when developers want run just docker container without installing anything locally (e.g docker-machine). But in most cases it's just examples from internet or there own experiments ): But we definitely should discuss it during midcycle next week. --- Egor From: Hongbin Lu To: OpenStack Development Mailing List (not for usage questions) < openstack-dev@lists.openstack.org> Sent: Thursday, February 11, 2016 8:50 PM Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Hi team, Sorry for bringing up this old thread, but a recent debate on container resource [1] reminded me the use case Kris mentioned below. I am going to propose a preliminary idea to address the use case. Of course, we could continue the discussion in the team meeting or midcycle. Idea: Introduce a docker-native COE, which consists of only minion/worker/slave nodes (no master nodes). Goal: Eliminate duplicated IaaS resources (master node VMs, lbaas vips, floating ips, etc.) Details: Traditional COE (k8s/swarm/mesos) consists of master nodes and worker nodes. In these COEs, control services (i.e. scheduler) run on master nodes, and containers run on worker nodes. If we can port the COE control services to Magnum control plate and share them with all tenants, we eliminate the need of master nodes thus improving resource utilization. In the new COE, users create/manage containers through Magnum API endpoints. Magnum is responsible to spin tenant VMs, schedule containers to the VMs, and manage the life-cycle of those containers. Unlike other COEs, containers created by this COE are considered as OpenStack-manage resources. That means they will be tracked in Magnum DB, and accessible by other Open
Re: [openstack-dev] [Magnum] New Core Reviewers
+ 1 for both @Ton and @Egor, they all have good review comments and suggestions. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Adrian Otto To: "openstack-dev@lists.openstack.org" Date: 02/02/2016 12:01 am Subject:[openstack-dev] [Magnum] New Core Reviewers Magnum Core Team, I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. Please respond with your votes. Thanks, Adrian Otto __ 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
Re: [openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?
HI, For Magnum, The community keep upstream development since Kilo. Magnum has some dependence on Keystone, Nova, Glance, Heat, Cinder. If you try to use Liberty Magnum against with Icehouse and Kilo OpenStack. It depends on related if heat templates include any non-icehouse, kilo resources. For example, according to http://docs.openstack.org/developer/heat/template_guide/openstack.html Magnum, mesos support used OS::Heat::SoftwareDeploymentGroup, It is available since Liberty in heat. It means you could not use Magnum to deploy mesos cluster on icehouse or kilo openstack. I suggest you two ways: 1> Try Liberty openstack possible(if you want to Liberty Magnum) Or 2> Check related heat templates in Magnum, and compare related support in heat template guide. if all resources support. It could run. But you need test on that. Hope it can help ! Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Sanjeev Rampal (srampal)" To: "openstack-dev@lists.openstack.org" Date: 28/01/2016 04:10 pm Subject:[openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ? A newbie question … Is it described somewhere what exactly is the set of Liberty dependencies for Magnum ? Since a significant fraction of it is orchestration templates, one would expect it should be possible to run Liberty Magnum bits along with an Icehouse or Kilo version of Openstack. Can someone help clarify the set of dependencies for Magnum on having a Liberty version of Openstack ? Rgds, Sanjeev __ 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
Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs
Hi Adrian, Right now, I think: for the unify-COE-container actions bp, it needs more discussion and good design to make it happen. ( I think spec is needed for this) And for the k8s related objects deprecation, it needs backup instead of directly dropped it. Especially when we not have any spec or design come out for unify-COE-container bp. Right now, the work now mostly happen on UI part, I think for UI, it can have discussion if need to implement those views or not.(instead we directly drop API part while not come out a consistent design on unify-COE-container actions bp) Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Adrian Otto To: "OpenStack Development Mailing List (not for usage questions)" Date: 17/12/2015 07:00 am Subject:Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs Tom, > On Dec 16, 2015, at 9:31 AM, Cammann, Tom wrote: > > I don’t see a benefit from supporting the old API through a microversion > when the same functionality will be available through the native API. +1 [snip] > Have we had any discussion on adding a v2 API and what changes (beyond > removing pod, rc, service) we would include in that change. What sort of > timeframe would we expect to remove the v1 API. I would like to move to a > v2 in this cycle, then we can think about removing v1 in N. Yes, when we drop functionality from the API that’s a contract breaking change, and requires a new API major version. We can drop the v1 API in N if we set expectations in advance. I’d want that plan to be supported with some evidence that maintaining the v1 API was burdensome in some way. Because adoption is limited, deprecation of v1 is not likely to be a contentious issue. Adrian > > Tom > > > > On 16/12/2015, 15:57, "Hongbin Lu" wrote: > >> Hi Tom, >> >> If I remember correctly, the decision is to drop the COE-specific API >> (Pod, Service, Replication Controller) in the next API version. I think a >> good way to do that is to put a deprecated warning in current API version >> (v1) for the removed resources, and remove them in the next API version >> (v2). >> >> An alternative is to drop them in current API version. If we decide to do >> that, we need to bump the micro-version [1], and ask users to specify the >> microversion as part of the requests when they want the removed APIs. >> >> [1] >> http://docs.openstack.org/developer/nova/api_microversions.html#removing-a >> n-api-method >> >> Best regards, >> Hongbin >> >> -Original Message- >> From: Cammann, Tom [mailto:tom.camm...@hpe.com] >> Sent: December-16-15 8:21 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: [openstack-dev] [magnum] Removing pod, rcs and service APIs >> >> I have been noticing a fair amount of redundant work going on in magnum, >> python-magnumclient and magnum-ui with regards to APIs we have been >> intending to drop support for. During the Tokyo summit it was decided >> that we should support for only COE APIs that all COEs can support which >> means dropping support for Kubernetes specific APIs for Pod, Service and >> Replication Controller. >> >> Egor has submitted a blueprint[1] “Unify container actions between all >> COEs” which has been approved to cover this work and I have submitted the >> first of many patches that will be needed to unify the APIs. >> >> The controversial patches are here: >> https://review.openstack.org/#/c/258485/ and >> https://review.openstack.org/#/c/258454/ >> >> These patches are more a forcing function for our team to decide how to >> correctly deprecate these APIs as I mention there is a lot of redundant >> work going on these APIs. Please let me know your thoughts. >> >> Tom >> >> [1] https://blueprints.launchpad.net/magnum/+spec/unified-containers >> __ >> 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 >> __ &g
Re: [openstack-dev] [Infra][nova][magnum] Jenkins failed quite often for "Cannot set up guest memory 'pc.ram': Cannot allocate memory"
Thanks Clark and infra guys to work around that. We would keep track that and see if such issue disappear. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Clark Boylan To: openstack-dev@lists.openstack.org Date: 16/12/2015 06:42 am Subject:Re: [openstack-dev] [Infra][nova][magnum] Jenkins failed quite often for "Cannot set up guest memory 'pc.ram': Cannot allocate memory" On Sun, Dec 13, 2015, at 10:51 AM, Clark Boylan wrote: > On Sat, Dec 12, 2015, at 02:16 PM, Hongbin Lu wrote: > > Hi, > > > > As Kai Qiang mentioned, magnum gate recently had a bunch of random > > failures, which occurred on creating a nova instance with 2G of RAM. > > According to the error message, it seems that the hypervisor tried to > > allocate memory to the nova instance but couldn’t find enough free memory > > in the host. However, by adding a few “nova hypervisor-show XX” before, > > during, and right after the test, it showed that the host has 6G of free > > RAM, which is far more than 2G. Here is a snapshot of the output [1]. You > > can find the full log here [2]. > If you look at the dstat log > http://logs.openstack.org/07/244907/5/check/gate-functional-dsvm-magnum-k8s/5305d7a/logs/screen-dstat.txt.gz > the host has nowhere near 6GB free memory and less than 2GB. I think you > actually are just running out of memory. > > > > Another observation is that most of the failure happened on a node with > > name “devstack-trusty-ovh-*” (You can verify it by entering a query [3] > > at http://logstash.openstack.org/ ). It seems that the jobs will be fine > > if they are allocated to a node other than “ovh”. > I have just done a quick spot check of the total memory on > devstack-trusty hosts across HPCloud, Rackspace, and OVH using `free -m` > and the results are 7480, 7732, and 6976 megabytes respectively. Despite > using 8GB flavors in each case there is variation and OVH comes in on > the low end for some reason. I am guessing that you fail here more often > because the other hosts give you just enough extra memory to boot these > VMs. To follow up on this we seem to have tracked this down to how the linux kernel restricts memory at boot when you don't have a contiguous chunk of system memory. We have worked around this by increasing the memory restriction to 9023M at boot which gets OVH inline with Rackspace and slightly increases available memory on HPCloud (because it actually has more of it). You should see this fix in action after image builds complete tomorrow (they start at 1400UTC ish). > > We will have to look into why OVH has less memory despite using flavors > that should be roughly equivalent. > > > > Any hints to debug this issue further? Suggestions are greatly > > appreciated. > > > > [1] http://paste.openstack.org/show/481746/ > > [2] > > http://logs.openstack.org/48/256748/1/check/gate-functional-dsvm-magnum-swarm/56d79c3/console.html > > [3] https://review.openstack.org/#/c/254370/2/queries/1521237.yaml __ 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
[openstack-dev] [Infra][nova][magnum] Jenkins failed quite often for "Cannot set up guest memory 'pc.ram': Cannot allocate memory"
Hi All, I am not sure what changes these days, We found quite often now, the Jenkins failed for: http://logs.openstack.org/07/244907/5/check/gate-functional-dsvm-magnum-k8s/5305d7a/logs/libvirt/libvirtd.txt.gz 2015-12-09 08:52:27.892+: 22957: debug : qemuMonitorJSONCommandWithFd:264 : Send command '{"execute":"qmp_capabilities","id":"libvirt-1"}' for write with FD -1 2015-12-09 08:52:27.892+: 22957: debug : qemuMonitorSend:959 : QEMU_MONITOR_SEND_MSG: mon=0x7fa66400c6f0 msg= {"execute":"qmp_capabilities","id":"libvirt-1"} fd=-1 2015-12-09 08:52:27.941+: 22951: debug : virNetlinkEventCallback:347 : dispatching to max 0 clients, called from event watch 6 2015-12-09 08:52:27.941+: 22951: debug : virNetlinkEventCallback:360 : event not handled. 2015-12-09 08:52:27.941+: 22951: debug : virNetlinkEventCallback:347 : dispatching to max 0 clients, called from event watch 6 2015-12-09 08:52:27.941+: 22951: debug : virNetlinkEventCallback:360 : event not handled. 2015-12-09 08:52:27.941+: 22951: debug : virNetlinkEventCallback:347 : dispatching to max 0 clients, called from event watch 6 2015-12-09 08:52:27.941+: 22951: debug : virNetlinkEventCallback:360 : event not handled. 2015-12-09 08:52:28.070+: 22951: error : qemuMonitorIORead:554 : Unable to read from monitor: Connection reset by peer 2015-12-09 08:52:28.070+: 22951: error : qemuMonitorIO:690 : internal error: early end of file from monitor: possible problem: Cannot set up guest memory 'pc.ram': Cannot allocate memory It not hit such resource issue before. I am not sure if Infra or nova guys know about it ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! __ 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] [magnum]storage for docker-bootstrap
HI Hua, From my point of view, not everything needed to be put in container. Let's make the initial start (be simple)to work and then discussed other options if needed in IRC or weekly meeting. Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: 王华 To: Egor Guz Cc: "openstack-dev@lists.openstack.org" Date: 07/12/2015 10:10 am Subject:Re: [openstack-dev] [magnum]storage for docker-bootstrap Hi all, If we want to run etcd and flannel in container, we will introduce docker-bootstrap which makes setup become more complex as Egor pointed out. Should we pay for the price? On Sat, Nov 28, 2015 at 8:45 AM, Egor Guz wrote: Wanghua, I don’t think moving flannel to the container is good idea. This is setup great for dev environment, but become too complex from operator point of view (you add extra Docker daemon and need extra Cinder volume for this daemon, also keep in mind it makes sense to keep etcd data folder at Cinder storage as well because etcd is database). flannel has just there files without extra dependencies and it’s much easy to download it during cloud-init ;) I agree that we have pain with building Fedora Atomic images, but instead of simplify this process we should switch to another more “friendly” images (e.g. Fedora/CentOS/Ubuntu) which we can easy build with disk builder. Also we can fix CoreOS template (I believe people more asked about it instead of Atomic), but we may face similar to Atomic issues when we will try to integrate not CoreOS products (e.g. Calico or Weave) — Egor From: 王华 mailto:wanghua.hum...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Thursday, November 26, 2015 at 00:15 To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap Hi Hongbin, The docker in master node stores data in /dev/mapper/atomicos-docker--data and metadata in /dev/mapper/atomicos-docker--meta. /dev/mapper/atomicos-docker--data and /dev/mapper/atomicos-docker--meta are logic volumes. The docker in minion node store data in the cinder volume, but /dev/mapper/atomicos-docker--meta and /dev/mapper/atomicos-docker--meta are not used. If we want to leverage Cinder volume for docker in master, should we drop /dev/mapper/atomicos-docker--meta and /dev/mapper/atomicos-docker--meta? I think it is not necessary to allocate a Cinder volume. It is enough to allocate two logic volumes for docker, because only etcd, flannel, k8s run in the docker daemon which need not a large amount of storage. Best regards, Wanghua On Thu, Nov 26, 2015 at 12:40 AM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: Here is a bit more context. Currently, at k8s and swarm bay, some required binaries (i.e. etcd and flannel) are built into image and run at host. We are exploring the possibility to containerize some of these system components. The rationales are (i) it is infeasible to build custom packages into an atomic image and (ii) it is infeasible to upgrade individual component. For example, if there is a bug in current version of flannel and we know the bug was fixed in the next version, we need to upgrade flannel by building a new image, which is a tedious process. To containerize flannel, we need a second docker daemon, called docker-bootstrap [1]. In this setup, pods are running on the main docker daemon, and flannel and etcd are running on the second docker daemon. The reason is that flannel needs to manage the network of the main docker daemon, so it needs to run on a separated daemon. Daneyon, I think it requires separated storage because it needs to run a separated docker daemon (unless there is a way to make two docker daemons share the same storage). Wanghua, is it possible to leverage Cinder volume for that. Leveraging external storage is always preferred [2]. [1] http://kubernetes.io/v1.1/docs/getting-started-guides/docker-multinode.html#bootstrap-docker [2] http://www.projectatomic.io/docs/docker-storage-recommendation/ Best regards, Hongbin From: Daneyon Hansen (danehans) [mailto:daneh...@cisco.com] Sent: November-25-15 11:10 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap From: 王华 mailto:wangh
Re: [openstack-dev] [Magnum] 'fixed_network' actually means 'fixed_subnet'. Which way is better to fix this?
Hi HouMing, I checked the heat templates again, and check with heat developers. For heat stack creation now, it can not directly use existed network when create new stack. which means, it need create a new net and subnet. So for fixed_network, the name is still need. just like when you create network in neutron, you need network and subnet. I think right now, so for magnum point of view what can be controlled is, 1. network name related properties settting. 2. subnetwork related properties. like CIDR. So for fixed_network, give it still what role should be. Add a new fixed_subnet for that. Of course, this can also be discussed in weekly meeting if needed. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hou Ming Wang To: openstack-dev@lists.openstack.org Date: 01/12/2015 05:49 pm Subject:[openstack-dev] [Magnum] 'fixed_network' actually means 'fixed_subnet'. Which way is better to fix this? Hi All, I'm working on API related enhancement and encountered the following issue: bay-creation return 400 Bad Request with a valid fixed-network in baymodel( https://bugs.launchpad.net/magnum/+bug/1519748 ) The 'fixed_network' actually means 'fixed_network_cidr', or more precisely 'fixed_subnet'. There're 2 possible ways to fix this: 1. Rename the 'fixed_network' to 'fixed_subnet', in Baymodel DB, Baymodel Object and MagnumClient. 2. Leave 'fixed_network' alone, add a new field 'fixed_subnet' to Baymodel, and use the 'fixed_subnet' to take the place of current 'fixed_network'. Please don't hesitate to give some inputs of which one is better, by comment in the bug or reply this mail. Thanks & Best regards, HouMing Wang __ 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
Re: [openstack-dev] [magnum] Using docker container to run COE daemons
Hi Jay, For the Kubernetes COE container ways, I think @Hua Wang is doing that. For the swarm COE, the swarm already has master and agent running in container For the mesos, it still not have container work until now, Maybe someone already draft bp on it ? Not quite sure Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Jay Lau To: OpenStack Development Mailing List Date: 26/11/2015 07:15 am Subject:[openstack-dev] [magnum] Using docker container to run COE daemons Hi, It is becoming more and more popular to use docker container run some applications, so what about leveraging this in Magnum? What I want to do is that we can put all COE daemons running in docker containers, because now Kubernetes, Mesos and Swarm support running in docker container and there are already some existing docker images/dockerfiles which we can leverage. So what about update all COE templates to use docker container to run COE daemons and maintain some dockerfiles for different COEs in Magnum? This can reduce the maintain effort for COE as if there are new versions and we want to upgrade, just update the dockerfile is enough. Comments? -- Thanks, Jay Lau (Guangya Liu) __ 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
Re: [openstack-dev] [Magnum] Why set DEFAULT_DOCKER_TIMEOUT = 10 in docker client?
Hi, I think out docker all call, use docker_for_bay, which use CONF.docker.default_timeout. And default_timeout can be changed any value. User can customized it per case. For why set 10, maybe it was because someone local test OK. So use that value. I think for jenkins, it can use CONF override value to make it work. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Qiao,Liyong" To: "OpenStack Development Mailing List (not for usage questions)" Date: 25/11/2015 03:24 pm Subject:[openstack-dev] [Magnum] Why set DEFAULT_DOCKER_TIMEOUT = 10 in docker client? hi all In Magnum code, we hardcode it as DEFAULT_DOCKER_TIMEOUT = 10 This bring troubles in some bad networking environment (or bad performance swarm master) At least it doesn't work on our gate. Here is the test patch on gate https://review.openstack.org/249522 , I set it as 180 to make sure the failure it due to time_out parameter passed to docker client, but we need to chose a suitble one I check docker client's default value, DEFAULT_TIMEOUT_SECONDS = 60 , I wonder why we overwrite it as 10? Please let me know what's your though? My suggestion is we set DEFAULT_DOCKER_TIMEOUT as long as our rpc time_out. -- BR, Eli(Li Yong)Qiao [attachment "liyong_qiao.vcf" deleted by Kai Qiang Wu/China/IBM] __ 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
Re: [openstack-dev] [magnum] Mesos Conductor
@bharath, 1) actually, if you mean use container-create(delete) to do on mesos bay for apps. I am not sure how different the interface between docker interface and mesos interface. One point that when you introduce that feature, please not make docker container interface more complicated than now. I worried that because it would confuse end-users a lot than the unified benefits. (maybe as optional parameter to pass one json file to create containers in mesos) 2) For the unified interface, I think it need more thoughts, we need not bring more trouble to end-users to learn new concepts or interfaces, except we could have more clear interface, but different COES vary a lot. It is very challenge. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: bharath thiruveedula To: OpenStack Development Mailing List not for usage questions Date: 19/11/2015 10:31 am Subject:Re: [openstack-dev] [magnum] Mesos Conductor @hongin, @adrian I agree with you. So can we go ahead with magnum container-create(delete) ... for mesos bay (which actually create mesos (marathon) app internally)? @jay, yes we multiple frameworks which are using mesos lib. But the mesos bay we are creating uses marathon. And we had discussion in irc on this topic, and I was asked to implement initial version for marathon. And agree with you to have unified client interface for creating pod,app. Regards Bharath T Date: Thu, 19 Nov 2015 10:01:35 +0800 From: jay.lau@gmail.com To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum] Mesos Conductor +1. One problem I want to mention is that for mesos integration, we cannot limited to Marathon + Mesos as there are many frameworks can run on top of Mesos, such as Chronos, Kubernetes etc, we may need to consider more for Mesos integration as there is a huge eco-system build on top of Mesos. On Thu, Nov 19, 2015 at 8:26 AM, Adrian Otto wrote: Bharath, I agree with Hongbin on this. Let’s not expand magnum to deal with apps or appgroups in the near term. If there is a strong desire to add these things, we could allow it by having a plugin/extensions interface for the Magnum API to allow additional COE specific features. Honestly, it’s just going to be a nuisance to keep up with the various upstreams until they become completely stable from an API perspective, and no additional changes are likely. All of our COE’s still have plenty of maturation ahead of them, so this is the wrong time to wrap them. If someone really wants apps and appgroups, (s)he could add that to an experimental branch of the magnum client, and have it interact with the marathon API directly rather than trying to represent those resources in Magnum. If that tool became popular, then we could revisit this topic for further consideration. Adrian > On Nov 18, 2015, at 3:21 PM, Hongbin Lu wrote: > > Hi Bharath, > > I agree the “container” part. We can implement “magnum container-create ..” for mesos bay in the way you mentioned. Personally, I don’t like to introduce “apps” and “appgroups” resources to Magnum, because they are already provided by native tool [1]. I couldn’t see the benefits to implement a wrapper API to offer what native tool already offers. However, if you can point out a valid use case to wrap the API, I will give it more thoughts. > > Best regards, > Hongbin > > [1] https://docs.mesosphere.com/using/cli/marathonsyntax/ > > From: bharath thiruveedula [mailto:bharath_...@hotmail.com] > Sent: November-18-15 1:20 PM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [magnum] Mesos Conductor > > Hi all, > > I am working on the blueprint [1]. As per my understanding, we have two resources/objects in mesos+marathon: > > 1)Apps: combination of instances/containers running on multiple hosts representing a service.[2] > 2)Application Groups: Group of apps, for example we can have database application group which consists mongoDB app and MySQL App.[3] > > So I think we need to have two resources 'apps' and 'appgroups' in mesos conductor like we have pod and rc for k8s. And regarding 'magnum container' com
Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing ongate.
Right now, we seems can not reduce devstack runtime. ANd @Ton, yes, download image time seems OK in jenkins job, it found about 4~5 mins But bay-creation time is interesting topic, it seems something related with heat or VM setup time consumption. But needs some investigation. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Ton Ngo" To: "OpenStack Development Mailing List \(not for usage questions \)" Date: 13/11/2015 01:13 pm Subject:Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing on gate. Thanks Eli for the analysis. I notice that the time to download the image is only around 1:15 mins out of some 21 mins to set up devstack. So it seems trying to reduce the size of the image won't make a significant improvement in the devstack time. I wonder how the image size affects the VM creation time for the cluster. If we can look at the Heat event stream, we might get an idea. Ton, Inactive hide details for Egor Guz ---11/12/2015 05:25:15 PM---Eli, First of all I would like to say thank you for your effort Egor Guz ---11/12/2015 05:25:15 PM---Eli, First of all I would like to say thank you for your effort (I never seen so many path sets ;)), From: Egor Guz To: "openstack-dev@lists.openstack.org" Date: 11/12/2015 05:25 PM Subject: Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing on gate. Eli, First of all I would like to say thank you for your effort (I never seen so many path sets ;)), but I don’t think we should remove “tls_disabled=True” tests from gates now (maybe in L). It’s still vey commonly used feature and backup plan if TLS doesn’t work for some reasons. I think it’s good idea to group tests per pipeline we should definitely follow it. ― Egor From: "Qiao,Liyong" mailto:liyong.q...@intel.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org >> Date: Wednesday, November 11, 2015 at 23:02 To: "openstack-dev@lists.openstack.org< mailto:openstack-dev@lists.openstack.org>" mailto:openstack-dev@lists.openstack.org >> Subject: [openstack-dev] [Magnum][Testing] Reduce Functional testing on gate. hello all: I will update some Magnum functional testing status, functional/integration testing is important to us, since we change/modify the Heat template rapidly, we need to verify the modification is correct, so we need to cover all templates Magnum has. and currently we only has k8s testing(only test with atomic image), we need to add more, like swarm(WIP), mesos(under plan), also , we may need to support COS image. lots of work need to be done. for the functional testing time costing, we discussed during the Tokyo summit, Adrian expected that we can reduce the timing cost to 20min. I did some analyses on the functional/integrated testing on gate pipeline. the stages will be follows: take k8s functional testing for example, we did follow testing case: 1) baymodel creation 2) bay(tls_disabled=True) creation/deletion 3) bay(tls_disabled=False) creation to testing k8s api and delete it after testing. for each stage, the time costing is follows: * devstack prepare: 5-6 mins * Running devstack: 15 mins(include downloading atomic image) * 1) and 2) 15 mins * 3) 15 +3 mins totally about 60 mins currently a example is 1h 05m 57s see http://logs.openstack.org/10/243910/1/check/gate-functional-dsvm-magnum-k8s/5e61039/console.html for all time stamps. I don't think it is possible to reduce time to 20 mins, since devstack setup will take 20 mins already. To reduce time, I suggest to only create 1 bay each pipeline and do vary kinds of testing on this bay, if want to test some specify bay (for example, network_driver etc), create a new pipeline . So, I think we can delete 2), since 3) will do similar things (create/delete), the different is 3) use tls_disabled=False. what do you think ? see https://review.openstack.org/244378 for the time costing, will reduce to 45 min (48m 50s in the example.) = For other related functional testing works: I 'v done the split of functional testing per COE, we have pipeline as: * gate-functional-dsvm-magnum-api 30 mins * gate-functional-dsvm-magnum-k8s 60 mins And for swam pipeline, patches is done, under reviewing now(works fine on gate) https://review.openstac
Re: [openstack-dev] [Magnum] [RFC] split pip line of functional testing
Hi eliqiao, 1) I think there are many openstack projects constructed multi-pipeline for different purpose, for example test different os distro pipelines. It is good to refer them. 2) we are construct new envs for different COE, I think it is easy to maintain. 3) yes, for code restructure, sorts different tests is a good idea. functional/swarm functional/mesos functional/k8s functional/common Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Qiao,Liyong" To: openstack-dev@lists.openstack.org, "Qiao, Liyong" Date: 03/11/2015 06:13 pm Subject:[openstack-dev] [Magnum] [RFC] split pip line of functional testing hi Magnum hackers: Currently there is a pip line on project-config to do magnum functional testing [1] on summit, we've discussed that we need to split it per COE[2], we can do this by adding new pip line to testing. - '{pipeline}-functional-dsvm-magnum{coe}{job-suffix}': coe could be swarm/mesos/k8s, then passing coe in our post_test_hook.sh [3], is this a good idea? and I still have others questions need to be addressed before split functional testing per COE: 1 how can we pass COE parameter to tox in [4], or add some new envs like [testenv:functional-swarm] [testenv:functional-k8s] etc? stupid? 2 also there are some common testing cases, should we run them in all COE ?(I think so) but how to construct the source code tree? /functional/swarm /functional/k8s /functional/common .. [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/projects.yaml#L2288 [2]https://etherpad.openstack.org/p/mitaka-magnum-functional-testing [3] https://github.com/openstack/magnum/blob/master/magnum/tests/contrib/post_test_hook.sh#L100 [4]https://github.com/openstack/magnum/blob/master/tox.ini#L19 -- BR, Eli(Li Yong)Qiao[attachment "liyong_qiao.vcf" deleted by Kai Qiang Wu/China/IBM] __ 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
Re: [openstack-dev] [magnum][kolla] Stepping down as a Magnum core reviewer
Hi Stdake, You really did a fantastic job on Magnum, and your bright ideas and thoughts help Magnum to grow. It was sad to hear your stepping down from Magnum Core at the first time, However, after read your messages from heart, I think you are following your heart. I will wish you new success on more areas(include Kolla and many new coming projects :). I want to think you for your help on me while in Magnum. Thanks very much :) Wish you bigger and more bright future ! Looking forward to receive your any thoughts on Magnum. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Steven Dake (stdake)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 26/10/2015 09:22 am Subject:[openstack-dev] [magnum][kolla] Stepping down as a Magnum core reviewer Hey folks, It is with sadness that I find myself under the situation to have to write this message. I have the privilege of being involved in two of the most successful and growing projects (Magnum, Kolla) in OpenStack. I chose getting involved in two major initiatives on purpose, to see if I could do the job; to see if I could deliver two major initiatives at the same time. I also wanted it to be a length of time that was significant �C 1+ year. I found indeed I was able to deliver both Magnum and Kolla, however, the impact on my personal life has not been ideal. The Magnum engineering team is truly a world class example of how an Open Source project should be constructed and organized. I hope some young academic writes a case study on it some day but until then, my gratitude to the Magnum core reviewer team is warranted by the level of their sheer commitment. I am officially focusing all of my energy on Kolla going forward. The Kolla core team elected me as PTL (or more accurately didn’t elect anyone else;) and I really want to be effective for them, especially in what I feel is Kolla’s most critical phase of growth. I will continue to fight for engineering resources for Magnum internally in Cisco. Some of these have born fruit already including the Heat resources, the Horizon plugin, and of course the Networking plugin system. I will also continue to support Magnum from a resources POV where I can do so (like the fedora image storage for example). What I won’t be doing is reviewing Magnum code (serving as a gate), or likely making much technical contribution to Magnum in the future. On the plus side I’ve replaced myself with many many more engineers from Cisco who should be much more productive combined then I could have been alone ;) Just to be clear, I am not abandoning Magnum because I dislike the people or the technology. I think the people are fantastic! And the technology �C well I helped design the entire architecture! I am letting Magnum grow up without me as I have other children that need more direct attention. I think this viewpoint shows trust in the core reviewer team, but feel free to make your own judgements ;) Finally I want to thank Perry Myers for influencing me to excel at multiple disciplines at once. Without Perry as a role model, Magnum may have never happened (or would certainly be much different then it is today). Being a solid hybrid engineer has a long ramp up time and is really difficult, but also very rewarding. The community has Perry to blame for that ;) Regards -steve __ 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
Re: [openstack-dev] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs
Hi Sean, Do you mean all other projects, like Barbican (non-standard implementation with copy/paste ways) would break in devstack ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Sean Dague To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/10/2015 07:13 pm Subject:[openstack-dev] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs Before we had devstack plugins, we had a kind of janky extras.d mechanism. A bunch of projects implemented some odd copy / paste mechanism in test jobs to use that in unexpected / unsupported ways. We've had devstack plugins for about 10 months. They provide a very "pro user" experience by letting you enable arbitrary plugins with: enable_plugin $name git://git.openstack.org/openstack/$project [$branch] They have reasonable documentation here http://docs.openstack.org/developer/devstack/plugins.html We're now getting to the point where some projects like Magnum are getting into trouble trying to build jobs with projects like Barbican, because Magnum uses devstack plugins, and Barbican has some odd non plugin copy paste method. Building composite test jobs are thus really wonky. This is a heads up that at Mitaka 1 milestone the extras.d support will be removed. The copy / paste method was never supported, and now it will explicitly break. Now would be a great time for teams to prioritize getting to the real plugin architecture. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] Adding 'server_type' field to Baymodel
HI Vikas, The server_type (old name was platform, we corrected it to be more proper, 'server_type') was introduced for wide support, like baremetal cases, etc. For other parts it is hardcode 'vm' now, as 'vm' was and still are supported.(it is widely used for VM cases in dev/test) For baremetal, I did some work before, but consider time and priority, not did it now. Details can be checked before like review.openstack.org/#/c/198984 If you have further questions, you can check with me in IRC channel. Thanks Best Wishes, ------------ Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Vikas Choudhary To: openstack-dev@lists.openstack.org Date: 01/09/2015 11:50 am Subject:[openstack-dev] Adding 'server_type' field to Baymodel Hi Team, I have a doubt.What all values 'server type' field that is being used in below function call can have? get_template_definition(cls, server_type, os, coe) Everywhere in code currently its value is 'vm' only. for example in classes representing template definitions(mesos, k8s and swarm): class AtomicSwarmTemplateDefinition(BaseTemplateDefinition): provides = [ {'server_type': 'vm', 'os': 'fedora-atomic', 'coe': 'swarm'}, ] os and coe are already fields of baymodel.Should not 'server_type' also be another field in baymodel? what i understand server-type can be baremetal_node also atleast. please correct me if i am wrong. Regards Vikas Choudhary __ 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
Re: [openstack-dev] [Magnum] Consistent functional test failures
I have checked with infra team members. For two instances, 10GB each should be OK. So I add some steps to create magnum specific flavor(8 GB disk), instead of use the existed devstack flavors (m1.small needs 20GB, m1.tiny can not be used) Magnum creates one for jenkins job and delete it when tests finished. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Clark Boylan To: openstack-dev@lists.openstack.org Date: 08/14/2015 08:05 AM Subject:Re: [openstack-dev] [Magnum] Consistent functional test failures On Thu, Aug 13, 2015, at 03:13 AM, Tom Cammann wrote: > Hi Team, > > Wanted to let you know why we are having consistent functional test > failures in the gate. > > This is being caused by Nova returning "No valid host" to heat: > > 2015-08-13 08:26:16.303 31543 INFO heat.engine.resource [-] CREATE: > Server "kube_minion" [12ab45ef-0177-4118-9ba0-3fffbc3c1d1a] Stack > "testbay-y366b2atg6mm-kube_minions-cdlfyvhaximr-0-dufsjliqfoet" > [b40f0c9f-cb54-4d75-86c3-8a9f347a27a6] > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource Traceback (most > recent call last): > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File > "/opt/stack/new/heat/heat/engine/resource.py", line 625, in > _action_recorder > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File > "/opt/stack/new/heat/heat/engine/resource.py", line 696, in _do_action > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield > self.action_handler_task(action, args=handler_args) > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File > "/opt/stack/new/heat/heat/engine/scheduler.py", line 320, in wrapper > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource step = > next(subtask) > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File > "/opt/stack/new/heat/heat/engine/resource.py", line 670, in > action_handler_task > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource while not > check(handler_data): > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File > "/opt/stack/new/heat/heat/engine/resources/openstack/nova/server.py", > line 759, in check_create_complete > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource return > self.client_plugin()._check_active(server_id) > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File > "/opt/stack/new/heat/heat/engine/clients/os/nova.py", line 232, in > _check_active > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource 'code': > fault.get('code', _('Unknown')) > 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource > ResourceInError: Went to status ERROR due to "Message: No valid host was > found. There are not enough hosts available., Code: 500" > > And this in turn is being caused by the compute instance running out of > disk space: > > 2015-08-13 08:26:15.216 DEBUG nova.filters > [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Starting with 1 > host(s) get_filtered_objects /opt/stack/new/nova/nova/filters.py:70 > 2015-08-13 08:26:15.217 DEBUG nova.filters > [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter > RetryFilter returned 1 host(s) get_filtered_objects > /opt/stack/new/nova/nova/filters.py:84 > 2015-08-13 08:26:15.217 DEBUG nova.filters > [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter > AvailabilityZoneFilter returned 1 host(s) get_filtered_objects > /opt/stack/new/nova/nova/filters.py:84 > 2015-08-13 08:26:15.217 DEBUG nova.filters > [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter RamFilter > returned 1 host(s) get_filtered_objects > /opt/stack/new/nova/nova/filters.py:84 > 2015-08-13 08:26:15.218 DEBUG nova.scheduler.filters.disk_filter > [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] > (devstack-trusty-rax-dfw-4299602, devstack-trusty-rax-dfw-4299602) > ram:5172 disk:17408 io_ops:0 instances:1 does not have 20480 MB usable > disk, it only has 17408.0 MB usable disk. host_passes > /opt/stack/new/nova/nova/scheduler/filters/disk_filter.py:60 > 2015-08-13 08:26:15.218 INFO nova.filters > [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter DiskFilter > returne
Re: [openstack-dev] [Magnum] Consistent functional test failures (seems infra not have enough resource)
Hi Tom, I did talked to infra, which I think it is resource issue, But they thought it is nova issue, For we boot k8s bay, we use baymodel with falvor m1.small, you can find devstack +-+---+---+--+---+--+---+-+---+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +-+---+---+--+---+--+---+-+---+ | 1 | m1.tiny | 512 | 1| 0 | | 1 | 1.0 | True | | 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | | 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | | 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | | 42 | m1.nano | 64| 0| 0 | | 1 | 1.0 | True | | 451 | m1.heat | 512 | 0| 0 | | 1 | 1.0 | True | | 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | | 84 | m1.micro | 128 | 0| 0 | | 1 | 1.0 | True | +-+---+---+--+---+--+---+-+---+ From logs below: [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] (devstack-trusty-rax-dfw-4299602, devstack-trusty-rax-dfw-4299602) ram:5172 disk:17408 io_ops:0 instances:1 does not have 20480 MB usable disk, it only has 17408.0 MB usable disk. host_passes /opt/stack/new/nova/nova/scheduler/filters/disk_filter.py:60 2015-08-13 08:26:15.218 INFO nova.filters [req-e It is 20GB disk space, so failed for that. I think it is related with this, the jenkins allocated VM disk space is not large. I am curious why it failed so often recently. Does os-infra changed something ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Tom Cammann To: "OpenStack Development Mailing List (not for usage questions)" Date: 08/13/2015 06:24 PM Subject:[openstack-dev] [Magnum] Consistent functional test failures Hi Team, Wanted to let you know why we are having consistent functional test failures in the gate. This is being caused by Nova returning "No valid host" to heat: 2015-08-13 08:26:16.303 31543 INFO heat.engine.resource [-] CREATE: Server "kube_minion" [12ab45ef-0177-4118-9ba0-3fffbc3c1d1a] Stack "testbay-y366b2atg6mm-kube_minions-cdlfyvhaximr-0-dufsjliqfoet" [b40f0c9f-cb54-4d75-86c3-8a9f347a27a6] 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource Traceback (most recent call last): 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File "/opt/stack/new/heat/heat/engine/resource.py", line 625, in _action_recorder 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File "/opt/stack/new/heat/heat/engine/resource.py", line 696, in _do_action 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield self.action_handler_task(action, args=handler_args) 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File "/opt/stack/new/heat/heat/engine/scheduler.py", line 320, in wrapper 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource step = next(subtask) 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File "/opt/stack/new/heat/heat/engine/resource.py", line 670, in action_handler_task 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource while not check(handler_data): 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File "/opt/stack/new/heat/heat/engine/resources/openstack/nova/server.py", line 759, in check_create_complete 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource return self.client_plugin()._check_active(server_id) 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File "/opt/stack/new/heat/heat/engine/clients/os/nova.py", line 232, in _check_active 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource 'code': fault.get('code', _('Unknown')) 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource ResourceInError: Went to status ERROR due to "Message: No valid host was found. There are not enough hosts available., Code: 500" And this in turn is being caused by the compute instance running out of disk space: 2015-08-13 08:26:15.216 DEBUG nova.filters [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Starting with 1 host(s) get_filter
Re: [openstack-dev] [magnum]problems for horizontal scale
hi Hua, My comments in blue below. please check. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: 王华 To: "OpenStack Development Mailing List (not for usage questions)" Date: 08/13/2015 03:32 PM Subject:Re: [openstack-dev] [magnum]problems for horizontal scale Hi Kai Qiang Wu, I have some comments in line. On Thu, Aug 13, 2015 at 1:32 PM, Kai Qiang Wu wrote: Hi Hua, I have some comments about this: A> remove heat poller can be a way, but some of its logic needs to make sure it work and performance not burden. 1) for old heat poller it is quick loop, with fixed interval, to make sure stack status update quickly can be reflected in bay status 2) for periodic task running, it seems dynamic loop, and period is long, it was added for some stacks creation timeout, 1) loop exit, this 2) loop can help update the stack and also conductor crash issue It is not necessary to remove heat poller, so we can keep it. It would be ideal to put in one place for looping over the stacks, but periodic tasks need to consider if it really just need to loop IN_PROGRESS status stack ? And what's the interval for loop that ? (60s or short, loop performance) It is necessary to loop IN_PROGRESS status stack for conductor crash issue. Does heat have other status transition path, like delete_failed --> (status reset) --> become OK. etc. It needs to be made sure. B> For remove db operation in bay_update case. I did not understand your suggestion. bay_update include update_stack and poll_and_check(it is in heat poller), if you removed heat poller to periodic task(as you said in your 3). It still needs db operations. Race conditions occur in periodic tasks too. If we save the stack params such as node_count in bay_update and race condition occurs, then the node_count in db is wrong and the status is UPDATE_COMPLETE. And there is no way to correct it. If we save stack params in periodic tasks and race condition occurs, the node_count in db is still wrong and status is UPDATE_COMPLETE. We can correct it in the next periodic task if race condition does not occur. The solution I proposed can not promise the data in db is always right. Yes, it can help some, when you talked periodic task, I checked that, filters = [bay_status.CREATE_IN_PROGRESS, bay_status.UPDATE_IN_PROGRESS, bay_status.DELETE_IN_PROGRESS] bays = objects.Bay.list_all(ctx, filters=filters) If UPDATE_COMPLETE, I did not find it would sync it in this task. Do you mean add that status check in this periodic task ? C> For allow admin user to show stacks in other tenant, it seems OK. Does other projects try this before? Is it reasonable case for customer ? Nova allow admin user to show instances in other tenant. Neutron allow admin user to show ports in other tenant, nova uses it to sync up network info for instance from neutron. That would be OK, I think Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! Inactive hide details for 王华 ---08/13/2015 11:31:53 AM---any comments on this? On Wed, Aug 12, 2015 at 2:50 PM, 王华 wrote: From: 王华 To: openstack-dev@lists.openstack.org Date: 08/13/2015 11:31 AM Subject: Re: [openstack-dev] [magnum]problems for horizontal scale any comments on this? On Wed, Aug 12, 2015 at 2:50 PM, 王华 wrote: Hi All, In order to prevent race conditions due to multiple conductors, my solution is as blew: 1. remove the db operation in bay_update to prevent race conditions.Stack operation is atomic. Db operation is atomic. But the two operations together are not atomic.So the data in the db may be wrong. 2. sync up stack status and stack parameters(now only node_count) from heat by periodic tasks. bay_update can change stack parameters, so we need to sync up them. 3. remove heat poller, because we have periodic tasks. To sync up stack parameters from heat
Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint
Hi Stdake and Vilobh, If I get what you proposed below, you means pod/rc/service would not be stored in magnum side, Just retrieved and updated in k8s side ? For now, if magnum not add any specific logic to pod/rc/service, that can be OK. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Steven Dake (stdake)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 08/12/2015 11:52 PM Subject:Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint From: Akash Gangil Reply-To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: Wednesday, August 12, 2015 at 1:37 AM To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint Hi, I have a few questions. inline. Problem :- Currently objects (pod/rc/service) are read from the database. In order for native clients to work, they must be read from the ReST bay endpoint. To execute native clients, we must have one truth of the state of the system, not two as in its current state of art. What is meant by the "native" clients here? Can you give an example? Native client is docker binary or kubectl from those various projects. We also need to support python-magnumclient operations to support further Heat integration, which allows Magnum to be used well with proprietary software implementations that may be doing orchestration via Heat. A] READ path needs to be changed : 1. For python clients :- python-magnum client->rest api->conductor->rest-endpoint-k8s-api handler In its present state of art this is python-magnum client->rest api->db 2. For native clients :- native client->rest-endpoint-k8s-api If native client can get all the info through the rest-endpoint-k8s handler, why in case of magnum client do we need to go through rest-api-> conductor? Do we parse or modify the k8s-api data before responding to the python-magnum client? Kubernetes has a rest API endpoint running in the bay. This is different from the Magnum rest API. This is what is referred to above. B] WRITE operations need to happen via the rest endpoint instead of the conductor. If we completely bypass the conductor, is there any way to keep a track of trace of how a resource was modified? Since I presume now magnum doesn't have that info, since we talk to k8s-api directly? Or is this irrelevant? C] Another requirement that needs to be satisfied is that data returned by magnum should be the same whether its created by native client or python-magnum client. I don't understand why is the information duplicated in the magnum db and k8s data source in first place? From what I understand magnum has its own database which is with k8s-api responses? The reason it is duplicated is because when I wrote the original code, I didn’t forsee this objective. Essentially I’m not perfect ;) The fix will make sure all of the above conditions are met. Need your input on the proposed approach. ACK accurate of my understanding of the proposed approach :) -Vilobh [1] https://blueprints.launchpad.net/magnum/+spec/objects-from-bay __ 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 -- Akash __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.or
Re: [openstack-dev] [magnum]problems for horizontal scale
Hi Hua, I have some comments about this: A> remove heat poller can be a way, but some of its logic needs to make sure it work and performance not burden. 1) for old heat poller it is quick loop, with fixed interval, to make sure stack status update quickly can be reflected in bay status 2) for periodic task running, it seems dynamic loop, and period is long, it was added for some stacks creation timeout, 1) loop exit, this 2) loop can help update the stack and also conductor crash issue It would be ideal to put in one place for looping over the stacks, but periodic tasks need to consider if it really just need to loop IN_PROGRESS status stack ? And what's the interval for loop that ? (60s or short, loop performance) Does heat have other status transition path, like delete_failed --> (status reset) --> become OK. etc. B> For remove db operation in bay_update case. I did not understand your suggestion. bay_update include update_stack and poll_and_check(it is in heat poller), if you removed heat poller to periodic task(as you said in your 3). It still needs db operations. C> For allow admin user to show stacks in other tenant, it seems OK. Does other projects try this before? Is it reasonable case for customer ? Thanks Best Wishes, ------------ Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: 王华 To: openstack-dev@lists.openstack.org Date: 08/13/2015 11:31 AM Subject:Re: [openstack-dev] [magnum]problems for horizontal scale any comments on this? On Wed, Aug 12, 2015 at 2:50 PM, 王华 wrote: Hi All, In order to prevent race conditions due to multiple conductors, my solution is as blew: 1. remove the db operation in bay_update to prevent race conditions.Stack operation is atomic. Db operation is atomic. But the two operations together are not atomic.So the data in the db may be wrong. 2. sync up stack status and stack parameters(now only node_count) from heat by periodic tasks. bay_update can change stack parameters, so we need to sync up them. 3. remove heat poller, because we have periodic tasks. To sync up stack parameters from heat, we need to show stacks using admin_context. But heat don't allow to show stacks in other tenant. If we want to show stacks in other tenant, we need to store auth context for every bay. That is a problem. Even if we store the auth context, there is a timeout for token. The best way I think is to let heat allow admin user to show stacks in other tenant. Do you have a better solution or any improvement for my solution? Regards, Wanghua __ 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
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Suro and Jay, I checked discussion below, and I do believe we also need service-list(for just magnum-api and magnum-conductor), but not so emergent requirement. I also think service-list should not bind to k8s or swarm etc. (can use coe-service etc.) But I have more for below: 1) For k8s or swarm or mesos, I think magnum can expose through the coe-service-list. But if right now, we fetched status from DB for pods/rcs status, It seems not proper to do that, as DB has old data. We need to fetch that through k8s/swarm API endpoints. 2) It can also expose that through k8s/swarm/mesos client tools. If users like that. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Jay Lau To: "OpenStack Development Mailing List (not for usage questions)" Date: 08/04/2015 05:51 AM Subject:Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Suro, Yes, I did not see a strong reason for adding "service-list" to show all of magnum system services, but it is nice to have. But I did see a strong reason to rename "service-list" to "coe-service-list" or others which might be more meaningful as I was often asked by someone why does "magnum service-list" is showing some services in kubernetes but not magnum system itself? This command always make people confused. Thanks! 2015-08-03 15:36 GMT-04:00 SURO : Hi Jay, Thanks for clarifying the requirements further. I do agree with the idea of having 'magnum service-list' and 'magnum coe-service-list' to distinguish that coe-service is a different concept. BUT, in openstack space, I do not see 'service-list' as a standardized function across other APIs - 1. 'nova service-list' => Enlists services like api, conductor etc. 2. neutron does not have this option. 3. 'heat service-list' => Enlists available engines. 4. 'keystone service-list' => Enlists services/APIs who consults keystone. Now in magnum, we may choose to model it after nova, but nova really has a bunch of backend services, viz. nova-conductor, nova-cert, nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum not. For magnum, at this point creating 'service-list' only for api/conductor - do you see a strong need? Regards, SURO irc//freenode: suro-patz On 8/3/15 12:00 PM, Jay Lau wrote: Hi Suro and others, comments on this? Thanks. 2015-07-30 5:40 GMT-04:00 Jay Lau : Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the "magnum service-list" with "magnum coe-service-list". service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO : Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s, as the other COEs may very well converge onto similar/same concepts. Regards, SURO irc//freenode: suro-patz On 7/29/15 2:21 PM, Hongbin Lu wrote: Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin From: SURO [mailto:suro.p...@gmail.com] Sent: July-29-15 4:03 PM To: Jay Lau Cc: s...@yahoo-inc.com; OpenStack Development Mailing List (not for
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper
Hi Peng, As @Adrian pointed it out: My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. I remembered you or other guys in your company proposed one bp about nova virt driver for Hyper. What's the status of the bp now? Is it accepted by nova projects or cancelled ? Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Adrian Otto To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/19/2015 11:18 PM Subject:Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Containers with OpenStack in a meaningful way a full year earlier. Please pay attention closely. 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will get killed. Operators matter. 2) Cloud Operators need a consistent way to bill for the IaaS services the provide. Nova emits all of the RPC messages needed to do this. Having a second nova that does this slightly differently is a really annoying problem that will make Operators hate the software. It's better to use nova, have things work consistently, and plug in virt drivers to it. 3) Creation of a host is only part of the problem. That's the easy part. Nova also does a bunch of other things too. For example, say you want to live migrate a guest from one host to another. There is already functionality in Nova for doing that. 4) Resources need to be capacity managed. We call this scheduling. Nova has a pluggable scheduler to help with the placement of guests on hosts. Magnum will not. 5) Hosts in a cloud need to integrate with a number of other services, such as an image service, messaging, networking, storage, etc. If you only think in terms of host creation, and do something without nova, then you need to re-integrate with all of these things. Now, I probably left out examples of lots of other things that Nova does. What I have mentioned us enough to make my point that there are a lot of things that Magnum is intentionally NOT doing that we expect to get from Nova, and I will block all code that gratuitously duplicates functionality that I believe belongs in Nova. I promised our community I would not duplicate existing functionality without a very good reason, and I will keep that promise. Let's find a good way to fit Hyper with OpenStack in a way that best leverages what exists today, and is least likely to be rejected. Please note that the proposal needs to be changed from where it is today to achieve this fit. My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. Thanks, Adrian Original message From: Peng Zhao Date: 07/19/2015 5:36 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hong Bin, I have some online discussion with Peng, seems hyper is now integrating with Kubernetes and also have plan integrate with mesos for scheduling. Once mesos integration finished, we can treat mesos+hyper as another kind of bay. Thanks 2015-07-19 4:15 GMT+08:00 Hongbin Lu : Peng, Several questions Here. You mentioned that HyperStack is a single big “bay”. Then, who is doing the multi-host scheduling, Hyper or something else? Were you suggesting to integrate Hyper with Magnum directly? Or you were suggesting to integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)? Best regards, Hongbin From: Peng Zhao [mailto:p...@hyper.sh] Sent: July-17-15 12:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magn
Re: [openstack-dev] [magnum]
My thoughts: I think we'd better check what google will do after such official announcement. As community changes fast, and we'd really welcome someone to contributing it consistently and actively. Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Daneyon Hansen (danehans)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/18/2015 12:46 AM Subject:[openstack-dev] [magnum] All, Does anyone have insight into Google's plans for contributing to containers within OpenStack? http://googlecloudplatform.blogspot.tw/2015/07/Containers-Private-Cloud-Google-Sponsors-OpenStack-Foundation.html Regards, Daneyon Hansen __ 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
Re: [openstack-dev] [magnum] [nova] Magnum template manage use platform VS others as a type?
Hi Fox and Adrian, Let me summarize, 1) We all agree to replace 'platform' word to 'server_type' (let's not discuss this anymore) 2) For bay-creation now in magnum, We pass it to baymodel. Cloud Operators created lots of baymodels, maybe, like kubernets-vm-baymodel, kubernetes-baremetal-baymodel. Cloud Users just select what kinds of baymodels they like(or they can create themselves, which depend on policy files) For example, magnum baymodel-create --name k8sbaymodel \ --image-id fedora-21-atomic-3 \ --keypair-id testkey \ --external-network-id ${NIC_ID} \ --dns-nameserver 8.8.8.8 \ --flavor-id m1.small \ --docker-volume-size 5 \ --coe kubernetes One question for if user want to create a kubernetes-baremetal-baymodel, he should input flavor-id with baremetal flavor. Magnum template selection now: baymodel = conductor_utils.retrieve_baymodel(context, bay) cluster_distro = baymodel.cluster_distro cluster_coe = baymodel.coe definition = TDef.get_template_definition('vm', cluster_distro, cluster_coe) You can find 'vm' is hardcode now, since ironic template not fully supported before. When I introduce ironic templates management. My first thought is here 'vm' should be code with baymodel.server_type. So I propose to create baymodel with one parameter --server_type baremetal (default is 'vm', if user not specified). This solution is simple, I think not make cloud-users confused. For example, if user want to deploy baremetal. they need specify baremeatl flavor. If they not know which flavor is baremetal, how can they boot baremetal instances? If they know they used baremetal flavor, they also know server_type is 'baremetal', not 'vm'. It seems not complicated. The nova support now for ironic, it needs customized flavors. need some metadata input. You can not boot successfully baremetal instance with m1.small flavors I think, as nova scheduling would thought it is not right. 3) For you suppose use nova flavor, definition = TDef.get_template_definition('vm', cluster_distro, cluster_coe) Replace 'vm' to be with if baymodel.flavor.metadata['***'], server_type = 'baremeatal' else server_type = 'vm' definition = TDef.get_template_definition(server_type, cluster_distro, cluster_coe) I think it seems not stable, Because 'vm' flavor can also have metadata. Does 'baremetal' metadatas have consistent tagging(officially released) ? (for x86, arm. power arch all applies) I am open to use flavors to detect baremetal or 'vm', if metadata has consistent reliable fields. Thanks! Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Fox, Kevin M" To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/17/2015 08:30 AM Subject:Re: [openstack-dev] [magnum] [nova] Magnum template manage use platform VS others as a type? Adrian, I know for sure you can attach key=value metadata to the flavors. I just looked up in the admin guide, ( http://docs.openstack.org/admin-guide-cloud/content/customize-flavors.html) and it mentions that the extra_specs key=value pairs are just used for scheduling though. :/ So, Nova would have to be extended to support a non scheduled type of metadata (That could be useful for other things too...), but doesn't seem to exist today. One other possibility would be, if a nova scheduling filter can remove things from the extra_specs metadata before it hits the next plugin, we could slide in a MagnumFilter at the beginning of scheduler_default_filters that removes the magnum_server_type entry. Looking through the code, I think it would work, but makes me feel a little dirty too. I've attached an example that might be close to working for that... Maybe the Nova folks would like to weigh in if its a good plan or not? But, if the filter doesn't fly, then for Liberty it looks like your config option plan seems to be the best way to go. I like the plan, especially the default flavor/image. That should make it much easier to use if the user tr
Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?
+ 1 about server_type. I also think it is OK. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Adrian Otto To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/16/2015 03:18 PM Subject:Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? I’d be comfortable with server_type. Adrian On Jul 15, 2015, at 11:51 PM, Jay Lau wrote: After more thinking, I agree with Hongbin that instance_type might make customer confused with flavor, what about using server_type? Actually, nova has concept of server group, the "servers" in this group can be vm. pm or container. Thanks! 2015-07-16 11:58 GMT+08:00 Kai Qiang Wu : Hi Hong Bin, Thanks for your reply. I think it is better to discuss the 'platform' Vs instance_type Vs others case first. Attach: initial patch (about the discussion): https://review.openstack.org/#/c/200401/ My other patches all depend on above patch, if above patch can not reach a meaningful agreement. My following patches would be blocked by that. Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! Hongbin Lu ---07/16/2015 11:47:30 AM---Kai, Sorry for the confusion. To clarify, I was thinking how to name the field you proposed in baymo From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/16/2015 11:47 AM Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? Kai, Sorry for the confusion. To clarify, I was thinking how to name the field you proposed in baymodel [1]. I prefer to drop it and use the existing field ‘flavor’ to map the Heat template. [1] https://review.openstack.org/#/c/198984/6 From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: July-15-15 10:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? Hi HongBin, I think flavors introduces more confusion than nova_instance_type or instance_type. As flavors not have binding with 'vm' or 'baremetal', Let me summary the initial question: We have two kinds of templates for kubernetes now, (as templates in heat not flexible like programming language, if else etc. And separate templates are easy to maintain) The two kinds of kubernets templates, One for boot VM, another boot Baremetal. 'VM' or Baremetal here is just used for heat template selection. 1> If used flavor, it is nova specific concept: take two as example, m1.small, or m1.middle. m1.small < 'VM' m1.middle < 'VM' Both m1.small and m1.middle can be used in 'VM' environment. So we should not use m1.small as a template identification. That's why I think flavor not good to be used. 2> @Adrian, we have --flavor-id field for baymodel now, it would picked up by heat-templates, and boot instances with such flavor. 3> Finally, I think instance_type is better. instance_type can be used as heat templates identification parameter. instance_type = 'vm', it means such templates fit for normal 'VM' heat stack deploy instance_type = 'baremetal', it means such templates fit for ironic baremetal heat stack deploy. Thanks! Best Wishes, Kai Qiang Wu (吴开强 Kennan
Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?
Hi Hong Bin, Thanks for your reply. I think it is better to discuss the 'platform' Vs instance_type Vs others case first. Attach: initial patch (about the discussion): https://review.openstack.org/#/c/200401/ My other patches all depend on above patch, if above patch can not reach a meaningful agreement. My following patches would be blocked by that. Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/16/2015 11:47 AM Subject:Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? Kai, Sorry for the confusion. To clarify, I was thinking how to name the field you proposed in baymodel [1]. I prefer to drop it and use the existing field ‘flavor’ to map the Heat template. [1] https://review.openstack.org/#/c/198984/6 From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: July-15-15 10:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? Hi HongBin, I think flavors introduces more confusion than nova_instance_type or instance_type. As flavors not have binding with 'vm' or 'baremetal', Let me summary the initial question: We have two kinds of templates for kubernetes now, (as templates in heat not flexible like programming language, if else etc. And separate templates are easy to maintain) The two kinds of kubernets templates, One for boot VM, another boot Baremetal. 'VM' or Baremetal here is just used for heat template selection. 1> If used flavor, it is nova specific concept: take two as example, m1.small, or m1.middle. m1.small < 'VM' m1.middle < 'VM' Both m1.small and m1.middle can be used in 'VM' environment. So we should not use m1.small as a template identification. That's why I think flavor not good to be used. 2> @Adrian, we have --flavor-id field for baymodel now, it would picked up by heat-templates, and boot instances with such flavor. 3> Finally, I think instance_type is better. instance_type can be used as heat templates identification parameter. instance_type = 'vm', it means such templates fit for normal 'VM' heat stack deploy instance_type = 'baremetal', it means such templates fit for ironic baremetal heat stack deploy. Thanks! Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! Inactive hide details for Hongbin Lu ---07/16/2015 04:44:14 AM---+1 for the idea of using Nova flavor directly. Why we introducHongbin Lu ---07/16/2015 04:44:14 AM---+1 for the idea of using Nova flavor directly. Why we introduced the “platform” field to indicate “v From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: 07/16/2015 04:44 AM Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? +1 for the idea of using Nova flavor directly. Why we introduced the “platform” field to indicate “vm” or “baremetel” is that magnum need to map a bay to a Heat template (which will be used to provision the bay). Currently, Magnum has three layers of mapping: ・ platform: vm or baremetal ・ os: atomic, coreos, … ・ coe: kubernetes, swarm or mesos I think we could just replace “platform” with “flavor”, if we can populate a list of flovars for VM and another list of flavors for baremetal (We may need an additional list of flavors for container in the future for the nested container use case). Then, the new three layers would be: ・ flavor: baremetal, m1.small, m1.medium, … ・ os: atomic, coreos, ... ・ coe: kubernetes, swarm or mesos This approach can avoid introducing a new field in baymodel to indicate what Nova flavor already indicates. Best regards, Hongbin From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent:
Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?
Hi HongBin, I think flavors introduces more confusion than nova_instance_type or instance_type. As flavors not have binding with 'vm' or 'baremetal', Let me summary the initial question: We have two kinds of templates for kubernetes now, (as templates in heat not flexible like programming language, if else etc. And separate templates are easy to maintain) The two kinds of kubernets templates, One for boot VM, another boot Baremetal. 'VM' or Baremetal here is just used for heat template selection. 1> If used flavor, it is nova specific concept: take two as example, m1.small, or m1.middle. m1.small < 'VM' m1.middle < 'VM' Both m1.small and m1.middle can be used in 'VM' environment. So we should not use m1.small as a template identification. That's why I think flavor not good to be used. 2> @Adrian, we have --flavor-id field for baymodel now, it would picked up by heat-templates, and boot instances with such flavor. 3> Finally, I think instance_type is better. instance_type can be used as heat templates identification parameter. instance_type = 'vm', it means such templates fit for normal 'VM' heat stack deploy instance_type = 'baremetal', it means such templates fit for ironic baremetal heat stack deploy. Thanks! Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/16/2015 04:44 AM Subject:Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? +1 for the idea of using Nova flavor directly. Why we introduced the “platform” field to indicate “vm” or “baremetel” is that magnum need to map a bay to a Heat template (which will be used to provision the bay). Currently, Magnum has three layers of mapping: ・ platform: vm or baremetal ・ os: atomic, coreos, … ・ coe: kubernetes, swarm or mesos I think we could just replace “platform” with “flavor”, if we can populate a list of flovars for VM and another list of flavors for baremetal (We may need an additional list of flavors for container in the future for the nested container use case). Then, the new three layers would be: ・ flavor: baremetal, m1.small, m1.medium, … ・ os: atomic, coreos, ... ・ coe: kubernetes, swarm or mesos This approach can avoid introducing a new field in baymodel to indicate what Nova flavor already indicates. Best regards, Hongbin From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: July-15-15 12:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? Maybe somehow I missed the point, but why not just use raw Nova flavors? They already abstract away irconic vs kvm vs hyperv/etc. Thanks, Kevin From: Daneyon Hansen (danehans) [daneh...@cisco.com] Sent: Wednesday, July 15, 2015 9:20 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? All, IMO virt_type does not properly describe bare metal deployments. What about using the compute_driver parameter? compute_driver = None (StrOpt) Driver to use for controlling virtualization. Options include: libvirt.LibvirtDriver, xenapi.XenAPIDriver, fake.FakeDriver, baremetal.BareMetalDriver, vmwareapi.VMwareVCDriver, hyperv.HyperVDriver http://docs.openstack.org/kilo/config-reference/content/list-of-compute-config-options.html http://docs.openstack.org/developer/ironic/deploy/install-guide.html From: Adrian Otto Reply-To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: Tuesday, July 14, 2015 at 7:44 PM To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? One drawback to virt_type if not seen in the context of the acceptable values, is that it should be set to values like libvirt, xen, ironic, etc. That might actually be good. Instead of using the values 'vm' or 'baremetal', we use the name of the nova virt driver, and interpret those to be vm or baremetal types. So if I set the value to
[openstack-dev] [magnum] Magnum template manage use platform VS others as a type?
Hi Magnum Guys, I want to raise this question through ML. In this patch https://review.openstack.org/#/c/200401/ For some old history reason, we use platform to indicate 'vm' or 'baremetal'. This seems not proper for that, @Adrian proposed nova_instance_type, and someone prefer other names, let me summarize as below: 1. nova_instance_type 2 votes 2. instance_type 2 votes 3. others (1 vote, but not proposed any name) Let's try to reach the agreement ASAP. I think count the final votes winner as the proper name is the best solution(considering community diversity). BTW, If you not proposed any better name, just vote to disagree all, I think that vote is not valid and not helpful to solve the issue. Please help to vote for that name. Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle!__ 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] [Magnum] Magnum Quick-Start: Need clarification on Kubernetes/Redis example
Hi Dane, I did not try redis-cli recently, But it seems redis-cli example issue. Did you check with kubernetes guys? At the same time, we could discuss this in IRC channel #openstack-containers, as some guys are familiar with that templates, and did change that before. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Dane Leblanc (leblancd)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/14/2015 12:59 AM Subject:[openstack-dev] [Magnum] Magnum Quick-Start: Need clarification on Kubernetes/Redis example Does anyone have recent experience getting the Kubernetes/Redis example to work in the Magnum developer Quick-Start guide?: https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-quickstart.rst#exercising-the-services-using-devstack I can get everything in the Kubernetes/Redis example to work except for the last step. Here’s what the quick-start guide says for this step: “Now log into one of the other container hosts and access a redis slave from there: ssh minion@$(nova list | grep 10.0.0.4 | awk '{print $13}') REDIS_ID=$(docker ps | grep redis:v1 | grep k8s_redis | tail -n +2 | awk '{print $1}') docker exec -i -t $REDIS_ID redis-cli 127.0.0.1:6379> get replication:test "true" ^D exit There are four redis instances, one master and three slaves, running across the bay, replicating data between one another.” What I’m seeing is a bit different: (1)I have to use ‘sudo docker’ instead of ‘docker’. (No big deal.) (2)I see one master redis instance on one minion and one slave redis instance on a second minion (each has its own associated sentinel container as expected). (3)The redis-cli command times out with “Could not connect to Redis at 127.0.0.1:6379: Connection refused”. HOWEVER, if I add a host IP and port for the redis master minion (“-h 10.100.84.2 -p 6379 ”), the example works. Here is the failing case, without the host/port arguments: [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ REDIS_ID= $(sudo docker ps | grep redis:v1 | grep k8s_redis | awk '{print $1}') [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ sudo docker exec -i -t $REDIS_ID redis-cli Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected> [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ And here is the working case, using “-h 10.100.84.2 -p 6379“: [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ REDIS_ID= $(sudo docker ps | grep redis:v1 | grep k8s_redis | awk '{print $1}') [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ sudo docker exec -i -t $REDIS_ID redis-cli -h 10.100.84.2 -p 6379 10.100.84.2:6379> get replication:test "true" 10.100.84.2:6379> Note that I determined the ’10.100.84.2’ address for the redis master by running the following on the master minion: [minion@k8-4gmqfvntvm-1-6pnrx2hnxa3d-kube-minion-bh6nynhayhfy ~]$ sudo docker exec -i -t $REDIS_ID ip addr show dev eth0 5: eth0: mtu 1472 qdisc noqueue state UP link/ether 02:42:0a:64:54:02 brd ff:ff:ff:ff:ff:ff inet 10.100.84.2/24 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::42:aff:fe64:5402/64 scope link valid_lft forever preferred_lft forever [minion@k8-4gmqfvntvm-1-6pnrx2hnxa3d-kube-minion-bh6nynhayhfy ~]$ So I’m looking for confirmation as to whether or not using the “-h 10.100.84.2 -p 6379“ arguments is the right way to test this configuration? Is this a successful test? Thanks, Dane __ 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
Re: [openstack-dev] [magnum] Tom Cammann for core
+1 from me. Good review comments! @Tom Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Adrian Otto To: OpenStack Development Mailing List Date: 07/10/2015 10:25 AM Subject:[openstack-dev] [magnum] Tom Cammann for core Team, Tom Cammann (tcammann) has become a valued Magnum contributor, and consistent reviewer helping us to shape the direction and quality of our new contributions. I nominate Tom to join the magnum-core team as our newest core reviewer. Please respond with a +1 vote if you agree. Alternatively, vote -1 to disagree, and include your rationale for consideration. Thanks, Adrian __ 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
Re: [openstack-dev] [magnum] Magnum Midcycle Event Scheduling Doodle Poll closes July 7th
Hi Stdake, If remote participation, do I need to vote for http://doodle.com/pinkuc5hw688zhxw ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Steven Dake (stdake)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/02/2015 02:06 AM Subject:[openstack-dev] [magnum] Magnum Midcycle Event Scheduling Doodle Poll closes July 7th Apologies for double post �C left off [magnum] prior by error. Ton Ngo of IBM Silicon Valley Research has graciously offered to host the 2 day Magnum midcycle event at IBM’s facilities. The sessions will run from 9AM �C 5PM and catered lunch and refreshments (soda/water) will be provided. The mid-cycle will be a standard mid-cycle with a 1 hour introduction followed by two days of design sessions. Please cast your votes on any days you can make. http://doodle.com/pinkuc5hw688zhxw There are ~25 seats available. Preference will be given to in-person core reviewers, followed by any folks that have made commits to the repository. After dates are settled, a separate eventbrite event will be setup to sort out the specifics such as dietary needs, etc and confirm in-person seating if we are past capacity limits. We will make remote participation available, but the experience will likely be less then optimal for remote participants. Regards -steve __ 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
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
For @Tom's suggestion, I +1 about it, maintain a separate heat-coe-templates is very inefficient.[As @HongBin's comments below] Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Fox, Kevin M" To: "OpenStack Development Mailing List (not for usage questions)" Date: 06/30/2015 11:40 PM Subject:Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates Whats the timeframe? I was really hoping for Liberty but its sounding like thats unlikely? M then? The app catalog really needs conditionals for the same reason. :/ Thanks, Kevin From: Angus Salkeld [asalk...@mirantis.com] Sent: Monday, June 29, 2015 6:56 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M wrote: Needing to fork templates to tweak things is a very common problem. Adding conditionals to Heat was discussed at the Summit. ( https://etherpad.openstack.org/p/YVR-heat-liberty-template-format). I want to say, someone was going to prototype it using YAQL, but I don't remember who. I was going to do that, but I would not expect that ready in a very short time frame. It needs some investigation and agreement from others. I'd suggest making you decision based on what we have now. -Angus Would it be reasonable to keep if conditionals worked? Thanks, Kevin From: Hongbin Lu [hongbin...@huawei.com] Sent: Monday, June 29, 2015 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates Agree. The motivation of pulling templates out of Magnum tree is hoping these templates can be leveraged by a larger community and get more feedback. However, it is unlikely to be the case in practise, because different people has their own version of templates for addressing different use cases. It is proven to be hard to consolidate different templates even if these templates share a large amount of duplicated code (recall that we have to copy-and-paste the original template to add support for Ironic and CoreOS). So, +1 for stopping usage of heat-coe-templates. Best regards, Hongbin -Original Message- From: Tom Cammann [mailto:tom.camm...@hp.com] Sent: June-29-15 11:16 AM To: openstack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Magnum] Continuing with heat-coe-templates Hello team, I've been doing work in Magnum recently to align our templates with the "upstream" templates from larsks/heat-kubernetes[1]. I've also been porting these changes to the stackforge/heat-coe-templates[2] repo. I'm currently not convinced that maintaining a separate repo for Magnum templates (stackforge/heat-coe-templates) is beneficial for Magnum or the community. Firstly it is very difficult to draw a line on what should be allowed into the heat-coe-templates. We are currently taking out changes[3] that introduced "useful" autoscaling capabilities in the templates but that didn't fit the Magnum plan. If we are going to treat the heat-coe-templates in that way then this extra repo will not allow organic development of new and old container engine templates that are not tied into Magnum. Another recent change[4] in development is smart autoscaling of bays which introduces parameters that don't make a lot of sense outside of Magnum. There are also difficult interdependency problems between the templates and the Magnum project such as the parameter fields. If a required parameter is added into the template the Magnum code must be also updated in the same commit to avoid functional test failures. This can be avoided using "Depends-On: #xx" feature of gerrit, but it is an additional overhead and will require some CI setup. Additionally we would have to version the templates, which I assume would be necessary to allow for packaging. This brings with it is own problems. As far as I am aware there are no other people using the heat-coe-templates beyond the Magnum team, if we want independent growth of this repo it will need to be adopted by other people rather than Magnum commiters. I don't see the heat templates as a dependency of Magnum, I see them as a truly fundamental part of Mag
Re: [openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint
Hi Adrian, If I summarize your option, it would be, 1) Have a function like this, magnum bay-create --name swarmbay --baymodel swarmbaymodel --baymodel-property-override apiserver_port=8766 And then magnum pass that property to override baymodel default properties, and create the bay. 2) You talked another BP, about adjust bay api_address to be a URL, For bay attribute api_address should be return format like following tcp://192.168.45.12:7622 or http://192.168.45.12:8234 Is it ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Adrian Otto To: "OpenStack Development Mailing List (not for usage questions)" Date: 06/13/2015 02:04 PM Subject:Re: [openstack-dev] [Magnum]Discuss configurable-coe-api-port Blueprint Hongbin, Good use case. I suggest that we add a parameter to magnum bay-create that will allow the user to override the baymodel.apiserver_port attribute with a new value that will end up in the bay.api_address attribute as part of the URL. This approach assumes implementation of the magnum-api-address-url blueprint. This way we solve for the use case, and don't need a new attribute on the bay resource that requires users to concatenate multiple attribute values in order to get a native client tool working. Adrian On Jun 12, 2015, at 6:32 PM, Hongbin Lu wrote: A use case could be the cloud is behind a proxy and the API port is filtered. In this case, users have to start the service in an alternative port. Best regards, Hongbin From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: June-12-15 2:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint Thanks for raising this for discussion. Although I do think that the API port humber should be expressed in a URL that the local client can immediately use for connecting a native client to the API, I am not convinced that this needs to be a separate attribute on the Bay resource. In general, I think it’s a reasonable assumption that nova instances will have unique IP addresses assigned to them (public or private is not an issue here) so unique port numbers for running the API services on alternate ports seems like it may not be needed. I’d like to have input from at least one Magnum user explaining an actual use case for this feature before accepting this blueprint. One possible workaround for this would be to instruct those who want to run nonstandard ports to copy the heat template, and specify a new heat template as an alternate when creating the BayModel, which can implement the port number as a parameter. If we learn that this happens a lot, we should revisit this as a feature in Magnum rather than allowing it through an external workaround. I’d like to have a generic feature that allows for arbitrary key/value pairs for parameters and values to be passed to the heat stack create call so that this, and other values can be passed in using the standard magnum client and API without further modification. I’m going to look to see if we have a BP for this, and if not, I will make one. Adrian On Jun 11, 2015, at 6:05 PM, Kai Qiang Wu(Kennan) < wk...@cn.ibm.com> wrote: If I understand the bp correctly, the apiserver_port is for public access or API call service endpoint. If it is that case, user would use that info htttp(s)://: so port is good information for users. If we believe above assumption is right. Then 1) Some user not needed to change port, since the heat have default hard code port in that 2) If some users want to change port, (through heat, we can do that) We need add such flexibility for users. That's bp https://blueprints.launchpad.net/magnum/+spec/configurable-coe-api-port try to solve. It depends on how end-users use with magnum. Welcome to more inputs about this, If many of us think it is not necessary to customize the ports. we can drop the bp. Thanks
Re: [openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint
If I understand the bp correctly, the apiserver_port is for public access or API call service endpoint. If it is that case, user would use that info htttp(s)://: so port is good information for users. If we believe above assumption is right. Then 1) Some user not needed to change port, since the heat have default hard code port in that 2) If some users want to change port, (through heat, we can do that) We need add such flexibility for users. That's bp https://blueprints.launchpad.net/magnum/+spec/configurable-coe-api-port try to solve. It depends on how end-users use with magnum. Welcome to more inputs about this, If many of us think it is not necessary to customize the ports. we can drop the bp. Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Jay Lau To: "OpenStack Development Mailing List (not for usage questions)" Date: 06/11/2015 01:17 PM Subject:Re: [openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint I think that we have a similar bp before: https://blueprints.launchpad.net/magnum/+spec/override-native-rest-port I have some discussion before with Larsks, it seems that it does not make much sense to customize this port as the kubernetes/swarm/mesos cluster will be created by heat and end user do not need to care the ports,different kubernetes/swarm/mesos cluster will have different IP addresses so there will be no port conflict. 2015-06-11 9:35 GMT+08:00 Kai Qiang Wu : I’m moving this whiteboard to the ML so we can have some discussion to refine it, and then go back and update the whiteboard. Source: https://blueprints.launchpad.net/magnum/+spec/configurable-coe-api-port @Sdake and I have some discussion now, but may need more input from your side. 1. keep apserver_port in baymodel, it may only allow admin to have (if we involved policy) create that baymodel, have less flexiblity for other users. 2. apiserver_port was designed in baymodel, if moved from baymodel to bay, it is big change, and if we have other better ways. (it also may apply for other configuration fileds, like dns-nameserver etc.) Thanks Best Wishes, -------- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! __ 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 -- Thanks, Jay Lau (Guangya Liu) __ 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
[openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint
I’m moving this whiteboard to the ML so we can have some discussion to refine it, and then go back and update the whiteboard. Source: https://blueprints.launchpad.net/magnum/+spec/configurable-coe-api-port @Sdake and I have some discussion now, but may need more input from your side. 1. keep apserver_port in baymodel, it may only allow admin to have (if we involved policy) create that baymodel, have less flexiblity for other users. 2. apiserver_port was designed in baymodel, if moved from baymodel to bay, it is big change, and if we have other better ways. (it also may apply for other configuration fileds, like dns-nameserver etc.) Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle!__ 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] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum
Thanks All Magnum Guys, It is my honor to work with all of you to make Magnum Better. :) Thanks Stdake. Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Steven Dake (stdake)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 06/07/2015 08:03 AM Subject:Re: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum Kennan, Welcome to the magnum-core team! Regards -steve From: Steven Dake Reply-To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: Saturday, May 30, 2015 at 10:56 PM To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Subject: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum Hi core team, Kennan (Kai Qiang Wu’s nickname) has really done a nice job in Magnum contributions. I would like to propose Kennan for the core reviewer team. I don’t think we necessarily need more core reviewers on Magnum, but Kennan has demonstrated a big commitment to Magnum and is a welcome addition in my opinion. For the lifetime of the project, Kennan has contributed 8% of the reviews, and 8% of the commits. Kennan is also active in IRC. He meets my definition of what a core developer for Magnum should be. Consider my proposal to be a +1 vote. Please vote +1 to approve or vote �C1 to veto. A single �C1 vote acts as a veto, meaning Kennan would not be approved for the core team. I believe we require 3 +1 core votes presently, but since our core team is larger now then when we started, I’d like to propose at our next team meeting we formally define the process by which we accept new cores post this proposal for Magnum into the magnum-core group and document it in our wiki. I’ll leave voting open for 1 week until June 6th to permit appropriate time for the core team to vote. If there is a unanimous decision or veto prior to that date, I’ll close voting and make the appropriate changes in gerrit as appropriate. Thanks -steve __ 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
Re: [openstack-dev] [Magnum] Discuss mesos-bay-type Blueprint
Hi All, For mesos bay, I think what we should implement depends on user-cases. If users use magnum to create mesos-bay, what would they do with mesos in following steps ? 1. If they go to mesos (framework or anything) directly, we'd better not involve any new mesos objects, but use container if possible. 2. If they'd like to operate with mesos through magnum, and it is easy to do that, we could provide some objects operation. Ideally, it is good to reuse containers api if possible. If not, we'd better find ways to mesos mapping(api passthrough, instead add redundant objects in magnum side) Thanks Best Wishes, ------------ Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 06/02/2015 06:15 AM Subject:Re: [openstack-dev] [Magnum] Discuss mesos-bay-type Blueprint Hi Jay, For your question “what is the mesos object that we want to manage”, the short answer is it depends. There are two options I can think of: 1. Don’t manage any object from Marathon directly. Instead, we can focus on the existing Magnum objects (i.e. container), and implements them by using Marathon APIs if it is possible. Use the abstraction ‘container’ as an example. For a swarm bay, container will be implemented by calling docker APIs. For a mesos bay, container could be implemented by using Marathon APIs (it looks the Marathon’s object ‘app’ can be leveraged to operate a docker container). The effect is that Magnum will have a set of common abstractions that is implemented differently by different bay type. 2. Do manage a few Marathon objects (i.e. app). The effect is that Magnum will have additional API object(s) that is from Marathon (like what we have for existing k8s objects: pod/service/rc). Thoughts? Thanks Hongbin From: Jay Lau [mailto:jay.lau@gmail.com] Sent: May-29-15 1:35 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Discuss mesos-bay-type Blueprint I want to mention that there is another mesos framework named as chronos: https://github.com/mesos/chronos , it is used for job orchestration. For others, please refer to my comments in line. 2015-05-29 7:45 GMT+08:00 Adrian Otto : I’m moving this whiteboard to the ML so we can have some discussion to refine it, and then go back and update the whiteboard. Source: https://blueprints.launchpad.net/magnum/+spec/mesos-bay-type My comments in-line below. Begin forwarded message: From: hongbin Subject: COMMERCIAL:[Blueprint mesos-bay-type] Add support for mesos bay type Date: May 28, 2015 at 2:11:29 PM PDT To: Reply-To: hongbin Blueprint changed by hongbin: Whiteboard set to: I did a preliminary research on possible implementations. I think this BP can be implemented in two steps. 1. Develop a heat template for provisioning mesos cluster. 2. Implement a magnum conductor for managing the mesos cluster. Agreed, thanks for filing this blueprint! For 2, the conductor is mainly used to manage objects for CoE, k8s has pod, service, rc, what is the mesos object that we want to manage? IMHO, mesos is a resource manager and it needs to be worked with some frameworks to provide services. First, I want to emphasis that mesos is not a service (It looks like a library). Therefore, mesos doesn't have web API, and most users don't use mesos directly. Instead, they use a mesos framework that is on top of mesos. Therefore, a mesos bay needs to have a mesos framework pre- configured so that magnum can talk to the framework to manage the bay. There are several framework choices. Below is a list of frameworks that look like a fit (in my opinion). A exhaustive list of framework can be found here [1]. 1. Marathon [2] This is a framework controlled by a company (mesosphere [3]). It is open source through. It supports running app on clusters of docker containers. It is probably the most widely-used mesos framework for long-running application. Marathon offers a REST API, whereas Aroura does not (unless one has materialized in the last month). This was the one we discussed in our Vancouver design summit, and we agreed that those wanting to use Apache Mesos are probably expecting this framework. 2. Aurora [4] This is a framework governed by Apache Software Foundation. It looks very similar to Marathon, but maybe more advanced in nature. It has been used by Twitt
Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel
+1 about Jay option. BTW, as nova and glance all allow same name for instance or image, So name seems not need to be unique, it is OK I think. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Jay Lau To: "OpenStack Development Mailing List (not for usage questions)" Date: 06/01/2015 11:17 PM Subject:Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel 2015-06-01 21:54 GMT+08:00 Jay Pipes : On 05/31/2015 05:38 PM, Jay Lau wrote: Just want to use ML to trigger more discussion here. There are now bugs/patches tracing this, but seems more discussions are needed before we come to a conclusion. https://bugs.launchpad.net/magnum/+bug/1453732 https://review.openstack.org/#/c/181839/ https://review.openstack.org/#/c/181837/ https://review.openstack.org/#/c/181847/ https://review.openstack.org/#/c/181843/ IMHO, making the Bay/Baymodel name as a MUST will bring more flexibility to end user as Magnum also support operating Bay/Baymodel via names and the name might be more meaningful to end users. Perhaps we can borrow some iead from nova, the concept in magnum can be mapped to nova as following: 1) instance => bay 2) flavor => baymodel So I think that a solution might be as following: 1) Make name as a MUST for both bay/baymodel 2) Update magnum client to use following style for bay-create and baymodel-create: DO NOT add "--name" option You should decide whether name would be unique -- either globally or within a tenant. Note that Nova's instance names (the display_name model field) are *not* unique, neither globally nor within a tenant. I personally believe this was a mistake. The decision affects your data model and constraints. Yes, my thinking is to enable Magnum has same behavior with nova. The name can be managed by the end user and the end user can specify the name as they want, it is end user's responsibility to make sure there are no duplicate names. Actually, I think that the name do not need to be unique but UUID. Best, -jay __ 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 -- Thanks, Jay Lau (Guangya Liu) __ 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
Re: [openstack-dev] [Magnum] Magnum installation problem with devstack kilo
Hi BaoHua, For kilo you test, I am not sure what's the steps you did, as the dev-guide is for master branch development. If you have any questions, you can ask in #openstack-containers IRC channel or file bug in launchpad. Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: "Steven Dake (stdake)" To: "OpenStack Development Mailing List (not for usage questions)" Date: 06/01/2015 01:37 PM Subject:Re: [openstack-dev] [Magnum] Magnum installation problem with devstack kilo I have this same problem with devstack master. I’m not sure what it is other then it involves the requirements repo possibly not containing oslo.versionedobjects on my system. Dims has a suggestion to do something about it, but I didn’t get back to it. Try joining channel #openstack-containers and hunting down dims. Regards -steve From: Baohua Yang Reply-To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: Sunday, May 31, 2015 at 10:08 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Magnum] Magnum installation problem with devstack kilo Hi, all I am following http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst to install magnum with openstack kilo version. At the end, there are error messages like python update.py /opt/stack/magnum ... Syncing /opt/stack/magnum/requirements.txt 2015-05-29 12:50:28.075 | 'oslo.versionedobjects' is not in global-requirements.txt 2015-05-29 12:50:28.083 | + exit_trap 2015-05-29 12:50:28.083 | + local r=1 2015-05-29 12:50:28.084 | ++ jobs -p 2015-05-29 12:50:28.085 | + jobs= 2015-05-29 12:50:28.085 | + [[ -n '' ]] 2015-05-29 12:50:28.085 | + kill_spinner 2015-05-29 12:50:28.085 | + '[' '!' -z '' ']' 2015-05-29 12:50:28.085 | + [[ 1 -ne 0 ]] 2015-05-29 12:50:28.085 | + echo 'Error on exit' 2015-05-29 12:50:28.085 | Error on exit 2015-05-29 12:50:28.085 | + [[ -z /opt/stack/logs ]] 2015-05-29 12:50:28.085 | + /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs 2015-05-29 12:50:28.122 | df: '/run/user/1000/gvfs': Permission denied 2015-05-29 12:50:28.165 | + exit 1 This repeats several times, does any one know the reason? Thanks! -- Best wishes! Baohua __ 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
Re: [openstack-dev] Please stop reviewing code while asking questions
+1 about Dan's comments. 1. We should not discourage all cases for -1 for questions. Because it often leads more discussion about the code issue, it is helpful for such case. Of course, it is diffcult to find a balance point, what can -1, what can 0. I don't think 0 in gerrit works well, because sometimes authors not care about that. 2. Also, for typos in comments and message, -1 makes sense too. Because 0 in gerrit means no need to improve the message and everything is good. It can lead many bad cases for cores, and non-cores. It means it doesn't matter if spell right or wrong. Best Wishes, Follow your heart. You are miracle! From: Dan Smith To: "OpenStack Development Mailing List (not for usage questions)" Date: 04/24/2015 10:48 PM Subject:Re: [openstack-dev] Please stop reviewing code while asking questions > In defense of those of us asking questions, I'll just point out > that as a core reviewer I need to be sure I understand the intent > and wide-ranging ramifications of patches as I review them. Especially > in the Oslo code, what appears to be a small local change can have > unintended consequences when the library gets out into the applications. > > I will often ask questions like, "what is going to happen in X > situation if we change this default" or "how does this change in > behavior affect the case where Y happens, which isn't well tested > in our unit tests." If those details aren't made clear by the commit > message and comments in the code, I consider that a good reason to > include a -1 with a request for the author to provide more detail. > Often these are cases I'm not intimately familiar with, so I ask a > question rather than saying outright that I think something is > broken because I expect to learn from the answer but I still have > doubts that I want to indicate with the -1. > > Most of the time the author has thought about the issues and worked > out a reason they are not a problem, but they haven't explained > that anywhere. On the other hand, it is frequently the case that > someone *hasn't* understood why a change might be bad and the > question ends up leading to more research and discussion. Right, and -1 makes the comment much more visible to both other cores and the reviewer. Questions which rightly point out something which would lead to what the OP considers a legit -1 can *easily* get missed in the wash of review comments on a bug. If you leave a -1 for a question and never come back to drop it when the answer is provided, then that's bad and you should stop doing that. However, I'm really concerned about the suggestion to not -1 for questions in general because of the visibility we lose. I also worry that more non-core people will feel even less likely to -1 a patch for something they feel is just their failing to understand, when in fact it's valuable feedback that the code is obscure. As a core, I don't exclude all reviews with a -1, and doing so is pretty dangerous behavior, IMHO. I'm not sure if the concern of -1s for questions is over dropping the review out of the hitlist for cores, or if it's about hurting the feelings of the submitter. I'm not in favor of discouraging -1s for either problem. --Dan __ 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
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
Hi Madhuri, 1) I think we'd better not jump to v1beta3 API if our image not updated. In release, we need to provide person with easy to use and function works well. As you mentioned, the v1beta3 not work with our image with many issues. 2) If we could update our image, which integrate the latests k8s 0.15.0 release, I support to use v1beta3. @sdake may knows how to update image, maybe others also, I not know much about it how to update such image. Thanks Best Wishes, ---- Kai Qiang Wu (吴开强 Kennan) Follow your heart. You are miracle! From: Madhuri Rai To: "OpenStack Development Mailing List (not for usage questions)" Date: 04/22/2015 05:36 PM Subject:Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient Hi All, As we are using fedora-21-atomic-2 image and that has Kubernetes v0.11.0, I tried to run v1beta3 APIs on it. Some of the APIs failed. The Kubernetes developer said "v1beta3 wasn't fully supported until the 0.15.0 release". Hence this is causing some APIs to fail. Below are the failures: 1. service-create API fail(422 status) with v1beta3 request format. The request format has changed from v1beta1 to v1beta3. https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/api.md#v1beta3-conversion-tips I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7157 2. pod-create API fail(500 status) with invalid request format. While doing negative testing, I found that pod-create API fails with 500 status. It should actually fail with 400 status. I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7087 3. pod-update API fail(404). While trying to update a pod, it failed with status 404 even if the pod exists. This is due to duplicate replacePod API in Kubernetes Client code. I have logged an issue for the same at GoogleCloudPlatform/Kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/issues/7100 4. All APIs fail with json manifest. All Kubernetes resources(pod, rc, service) now fails with json format manifest due to issue in swagger-codegen generated Kubernetes Client code. It doesn't support unicode string. After all this issues, can we really switch to Kubernetes Client in this release or should we wait for the Fedora image with Kubernetes 0.15.0 release that has full support of v1beta3? Please provide your suggestions on this so that I can proceed further. Thanks & Regards Madhuri Kumari On Tue, Mar 24, 2015 at 10:37 AM, Madhuri Rai wrote: Hi Hongbin, On Tue, Mar 24, 2015 at 12:37 AM, Hongbin Lu wrote: Hi Madhuri, Amazing work! I wouldn't concern the code duplication and modularity issue since the codes are generated. However, there is another concern here: if we find a bug/improvement of the generated code, we probably need to modify the generator. The question is if the upstream will accept the modifications? If yes, how fast the patch will go through. I would prefer to maintain a folk of the generator. By this way, we would have full control of the generated code. Thoughts? I agree that's a concern. I will try to fix the pep8 error upstream to look how it take to push a change upstream. Thanks, Hongbin On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) wrote: From: Madhuri Rai Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Monday, March 23, 2015 at 1:53 AM To: "openstack-dev@lists.openstack.org" < openstack-dev@lists.openstack.org> Subject: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient Hi All, This is to have a discussion on the blueprint for implementing python-k8client for magnum. https://blueprints.launchpad.net/magnum/+spec/python-k8sclient I have committed the code generated by swagger-codegen at https://review.openstack.org/#/c/166720/. But I feel the quality of the code generated by swagger-codegen is not good. Some of the points: 1) There is lot of code duplication. If we want to generate code for two or more versions, same code is duplicated for each API version. 2) There is no modularity. CLI code for all the APIs are written in same file. So, I would like your opinion on this. How should we proceed further? Madhuri, First off, spectacular that you figured out how to do this! Great great job!