Re: [openstack-dev] [tricircle] Nominate change in tricircle core team
+1. Baisen has contributed lots of patches in Tricircle. Best Regards Chaoyi Huang (joehuang) From: Vega Cai [luckyveg...@gmail.com] Sent: 12 March 2018 9:04 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tricircle] Nominate change in tricircle core team Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle core reviewer. Baisen has actively joined the discussion of feature development and has contributed important patches since Queens, like resource deletion reliability and openstack-sdk new version adaption. I really think his experience will help us substantially improve tricircle. BR Zhiyuan -- BR Zhiyuan __ 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] [sdk][masakari][tricircle] Inclusion of SDK classes in openstacksdk tree
Hello, Monty, Tricircle did not develop any extra Neutron network resources, Tricircle provide plugins under Neutron, and same support resources as Neutron have. To ease the management of multiple Neutron servers, one Tricircle Admin API is provided to manage the resource routings between local neutron(s) and central neutron, it's one standalone service, and only for cloud administrator, therefore python-tricircleclient adn CLI were developed to support these administration functions. do you mean to put Tricircle Admin API sdk under openstacksdk tree? Best Regards Chaoyi Huang (joehuang) From: Monty Taylor [mord...@inaugust.com] Sent: 21 January 2018 1:22 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [sdk][masakari][tricircle] Inclusion of SDK classes in openstacksdk tree Hey everybody, Wanted to send a quick note to let people know that all OpenStack services are more than welcome to put any openstacksdk proxy and resource classes they have directly into the openstacksdk tree. Looking through codesearch.openstack.org, masakariclient and tricircle each have SDK-related classes in their trees. You don't HAVE to put the code into openstacksdk. In fact, I wrote a patch for masakariclient to register the classes with openstack.connection.Connection: https://review.openstack.org/#/c/534883/ But I wanted to be clear that the code is **welcome** directly in tree, and that anyone working on an OpenStack service is welcome to put support code directly in the openstacksdk tree. Monty PS. Joe - you've also got some classes in the tricircle test suite extending the network service. I haven't followed all the things ... are the tricircle network extensions done as neutron plugins now? (It looks like they are) If so, why don't we figure out getting your network resources in-tree as well. __ 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] [tricircle]Distinguish the direction of requests
Hello, As you are talking about how to distinguish the request to local Neutron and central Neutron, do you mean how to set the "USER_AGENT" in the request header, and how to extract the "USER_AGENT" and stored it in the context? Though it's mentioned in https://developer.openstack.org/sdks/python/openstacksdk/users/connection.html This field has not been extracted neither in oslo.context, nor neutron-lib context: https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py May be we can add it in oslo.context? Best Regards Chaoyi Huang (joehuang) From: XuZhuang [xu_ly...@163.com] Sent: 01 November 2017 19:49 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [tricircle]Distinguish the direction of requests Hello, I have some questions in how to distinguish the direction of requests between local neutron and central neutron. There is the preliminary plan 1. For how to distinguish the requests in central neutron we can add a filter in neutron/…./etc/api-paste.ini. Using this filter we can get some values about the source. But the question is that the process of loading filter is in Neutron. Without changing Neutron how could we add a filter? Could we change Neutron? 2. For how to add a signal in the requests The module of common.client in Tricircle is responsible for sending requests. So we can add a signal in the header of requests. And central plugin will get this signal using the filter. Best Regards Zhuangzhuang Xu (Lyman Xu) __ 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] [ptls] Sydney Forum Project Onboarding Rooms
Hello, Kendall, Tricircle would like to have an on-boarding session too, if there is still time slot left and not conflict with other my three sessions: ( Mon 6 , 1:55pm-2:15pm, Tricircle - Project Update; Mon 6 , 1:55pm-2:15pm, Move mission critical application to multi-site, what we learned; Wed 8 , 2:05pm-2:15pm Edge Computing (Platform) as a Service powered by OpenStack. ) Thank you well in advance. Best Regards Chaoyi Huang (joehuang) From: Jeffrey Zhang [zhang.lei@gmail.com] Sent: 13 October 2017 8:50 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms Hi Kendall, Kolla project would like to have a on-boarding session too. thanks. On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson mailto:kennelso...@gmail.com>> wrote: Added Nova to my list with Dan, Melanie, and Ed as speakers. Thanks Matt, -Kendall (diablo_rojo) On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann mailto:mriede...@gmail.com>> wrote: On 10/9/2017 4:24 PM, Kendall Nelson wrote: > Wanted to keep this thread towards the top of inboxes for those I > haven't heard from yet. > > About a 1/4 of the way booked, so there are still slots available! > > -Kendall (diablo_rojo) I've tricked the following people into running a Nova on-boarding room: - "Super" Dan Smith mailto:dansm...@redhat.com>> - Melanie "Structured Settlement" Witt mailto:melwi...@gmail.com>> - Ed "Alternate Hosts" Leafe mailto:e...@leafe.com>> -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Jeffrey Zhang Blog: http://xcodest.me<http://xcodest.me/> __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc][election] TC non-candidacy
Thank you very much, Monty. You always provide great help if needed, friendly. Best Regards Chaoyi Huang (joehuang) From: Monty Taylor [mord...@inaugust.com] Sent: 11 October 2017 7:40 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tc][election] TC non-candidacy Hey everybody! I have decided not to seek reelection for the TC. I have had the honor and privilege of serving you on the TC and it's predecessor the PPB since the fall of 2011 (with one six month absence that I blame on Jay Pipes) There are a wealth of amazing people running for the TC this cycle, many of whom have a different genetic, cultural or geographic background than I do. I look forward to seeing how they shepherd our amazing community. I am not going anywhere. We're just getting Zuul v3 rolled out, there's a pile of work to do to merge and rationalize shade and openstacksdk and I managed to sign myself up to implement application credentials in Keystone. I still haven't even managed to convince all of you that Floating IPs are a bad idea... Thank you, from the bottom of my heart, for the trust you have placed in me. I look forward to seeing as many of you as I can in Sydney, Vancouver, Berlin and who knows where else. Monty __ 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] Queens Goal for Kingbird
Cool, looking forward to the dashboard plugin. Best Regards Chaoyi Huang (joehuang) From: Goutham Pratapa [pratapagout...@gmail.com] Sent: 01 September 2017 21:05 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [all] Queens Goal for Kingbird Hi all, For this Queens cycle, we would like to implement Kingbird dashboard so that it can be used as a plugin in horizon using which - Admin can manage quota across multiple-regions and - Users can manage their respective resources (for now flavor, image, keypairs) across multiple regions through front-end. We are planning to extend resource_management to glance image-metadefs as well. -- Thanks!!! Goutham Pratapa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tricircle]stable/pike brach has been created.
Hello, all, Thank you all for the great contribution, stable/pike has been created on Aug.18: https://git.openstack.org/cgit/openstack/tricircle/log/?h=stable/pike Release notes could be found here: https://docs.openstack.org/releasenotes/tricircle/pike.html Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle-North South Networking via Direct Provider Networks]
Hello, Meher, By default, only one nic will come up for the instance from cirros image. You can log into the instance, follow this mail thread to bring up the second nic. http://lists.openstack.org/pipermail/openstack-dev/2014-October/048574.html Best Regards Chaoyi Huang(joehuang) 发件人:meher.h...@orange.com 收件人:openstack-dev 时间:2017-08-18 23:30:01 主题:[openstack-dev] [tricircle-North South Networking via Direct Provider Networks] Hello everyone, Still in the test phase of the scenarios proposed by the Tricircle documentation, I try to do "North South Networking via Direct Provider Networks" but I failed to start an instance with 2 NICs, apparently the Cirros image does not support this option by default. So I will add a new image and so I need the horizon service which is disabled when installing Tricircle. Thanks in advance for giving me an idea on how to add the dashboard without re-deploying! Best regards, Meher [Logo Orange]<http://www.orange.com/> Meher Hihi Intern ORANGE/IMT/OLN/WTC/CMA/MAX Fixe : +33 2 96 07 03 71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371> Mobile : +33 7 58 38 68 87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887> meher.h...@orange.com<mailto:meher.h...@orange.com> _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. __ 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] [releases]pike release notes missing in Tricircle
Not an issue. Just found that the patch needs to be approved by reviewer(s), it's not merged automatically. Best Regards Chaoyi Huang (joehuang) From: joehuang Sent: 18 August 2017 8:47 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev][releases]pike release notes missing in Tricircle Hello, The patch to update the reno( https://review.openstack.org/#/c/494565/ ) has been merged after Tricircle stable/pike branch is created, and the gate-tricircle-releasenotes<http://docs-draft.openstack.org/65/494565/1/check/gate-tricircle-releasenotes/088a2a1//releasenotes/build/html/> also worked fine, but the pike release notes is missing in https://docs.openstack.org/releasenotes/tricircle/ I found that pike release notes are visible both in Nova/Cinder project (https://docs.openstack.org/releasenotes/cinder/ https://docs.openstack.org/releasenotes/nova/) Is there something need to do to make pike release notes appearing in the site? Best Regards Chaoyi Huang (joehuang) __ 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] [releases]pike release notes missing in Tricircle
Hello, The patch to update the reno( https://review.openstack.org/#/c/494565/ ) has been merged after Tricircle stable/pike branch is created, and the gate-tricircle-releasenotes<http://docs-draft.openstack.org/65/494565/1/check/gate-tricircle-releasenotes/088a2a1//releasenotes/build/html/> also worked fine, but the pike release notes is missing in https://docs.openstack.org/releasenotes/tricircle/ I found that pike release notes are visible both in Nova/Cinder project (https://docs.openstack.org/releasenotes/cinder/ https://docs.openstack.org/releasenotes/nova/) Is there something need to do to make pike release notes appearing in the site? Best Regards Chaoyi Huang (joehuang) __ 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] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
Features for tricircle pike has been freezed, and no exception was asked until now, as you proposed, If neutron can have branch this week, we can cut branch earlier. Thank you, TTX. From: Thierry Carrez [thie...@openstack.org] Sent: 10 August 2017 20:39 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst... joehuang wrote: > Tricircle plans to cut stable/pike branch on August 22nd, it has dependency > on Neutron stable/pike creation. That sounds a bit late to create your release branch. It doesn't give you a lot of time to react to critical issues discovered in that release, as August 24 is the final date to submit new releases for inclusion before Pike is formally declared released. My advice would be to do a X.Y.0 release as soon as you can freeze features (neutron should have their branch this week), and have some time to produce a X.Y.1 bugfix release if you detect critical issues in testing. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
Hello, Tricircle plans to cut stable/pike branch on August 22nd, it has dependency on Neutron stable/pike creation. Best Regards Chaoyi Huang (joehuang) From: Tony Breeds [t...@bakeyournoodle.com] Sent: 10 August 2017 13:46 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst... Hi All, In an effort to qualify which projects are likley to be affected if when we open the requirements repo I generated a list of all repos that: 1. Subscribe to requirements management 2. Do not already have a stable/pike branch 3. Do not follow the cycle-with-milestones, cycle-trailing or independent release models 4. Are not a 'branchless' project (tempest or tempest-plugin) These repos I believe *should* have a stable/pike branch or will see problems when we open openstack/requirements. Those issues were described in [1] It turns out close to 1/3rd of projects that subscribe to requirements management are not ready for us to re-open for master. So we need you help to get that number down to a much more acceptable number. The good news is it's pretty easy to fix this with the cool tools and workflow in the releases repo[2]. I suspect that the 'service' will take care of themselves, and the horizon-plugins are waiting to horizon to cut RC1. Repos with type: horizon-plugin ironic-ui ironic manila-ui manila monasca-ui monasca neutron-fwaas-dashboardneutron solum-dashboardsolum tacker-horizon tacker watcher-dashboard watcher zun-ui zun Repos with type: other python-openstackclient OpenStackClient patroleQuality Assurance heat-agentsheat ironic-inspector ironic ironic-python-agentironic kuryr-kubernetes kuryr monasca-common monasca monasca-notification monasca monasca-persister monasca monasca-transform monasca Repos with type: service ironic ironic monasca-apimonasca monasca-log-apimonasca swift swift tricircle tricircle vitragevitrage watcherwatcher zunzun Those are the easy items. The following repos don't seem to use the openstack/releases repo so I have less information there. i18n I18n almanach blazar blazar-nova compute-hyperv ekko gce-api glare ironic-staging-drivers kosmos masakari masakari-monitors mixmatch mogan nemesis networking-dpm networking-fujitsu networking-generic-switch networking-l2gw networking-powervm neutron-vpnaas neutron-vpnaas-dashboard nova-dpm nova-lxd nova-powervm os-xenapi python-blazarclient python-cratonclient python-glareclient python-kingbirdclient python-masakariclient python-moganclient python-oneviewclient python-openstacksdk python-valenceclient swauth tap-as-a-service trio2o valence vmware-nsx vmware-nsxlib openstackclientOpenStackClient anchor Security ceilometer-powervm Telemetry ec2-apiec2-api horizon-cisco-ui horizon bifrostironic ironic-python-agent-builderironic magnum magnum magnum-ui magnum manila-image-elements manila murano-agent murano octavia-dashboard octavia senlin-dashboard senlin tacker tacker networking-hyperv winstackers It'd be great to get some of these repos represented in openstack/releases. Having a confirmed release-model would go a long way to clearing up the list
Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes
Except webhook, how about custom module(call keystone API directly from custom module) for authorization? ( https://kubernetes.io/docs/admin/authorization/#custom-modules ) Webhook: Pros.: http calling, loose coupling, more flexible configuration. Cons.: Degraded performance, one more hop custom module: Pros.: direct function call, better performance, less process to maintain. Cons.: coupling, built-in module. Best Regards Chaoyi Huang (joehuang) From: Morgan Fainberg [morgan.fainb...@gmail.com] Sent: 09 August 2017 12:26 To: OpenStack Development Mailing List (not for usage questions) Cc: kubernetes-sig-openst...@googlegroups.com Subject: Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes I shall take a look at the webhooks and see if I can help on this front. --Morgan On Tue, Aug 8, 2017 at 6:34 PM, joehuang wrote: > Dims, > > Integration of keystone and kubernetes is very cool and in high demand. Thank > you very much. > > Best Regards > Chaoyi Huang (joehuang) > > > From: Davanum Srinivas [dava...@gmail.com] > Sent: 01 August 2017 18:03 > To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing > List (not for usage questions) > Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone > based Authentication and Authorization for Kubernetes > > Team, > > Having waded through the last 4 attempts as seen in kubernetes PR(s) > and Issues and talked to a few people on SIG-OpenStack slack channel, > the consensus was that we should use the Webhook mechanism to > integrate Keystone and Kubernetes. > > Here's the experiment : https://github.com/dims/k8s-keystone-auth > > Anyone interested in working on / helping with this? Do we want to > create a repo somewhere official? > > Thanks, > Dims > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes
Dims, Integration of keystone and kubernetes is very cool and in high demand. Thank you very much. Best Regards Chaoyi Huang (joehuang) From: Davanum Srinivas [dava...@gmail.com] Sent: 01 August 2017 18:03 To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes Team, Having waded through the last 4 attempts as seen in kubernetes PR(s) and Issues and talked to a few people on SIG-OpenStack slack channel, the consensus was that we should use the Webhook mechanism to integrate Keystone and Kubernetes. Here's the experiment : https://github.com/dims/k8s-keystone-auth Anyone interested in working on / helping with this? Do we want to create a repo somewhere official? Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ 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] [tricircle]pike-3 released
Hello, Tricircle 3.4.0 (pike-3) released[1], it's time to do regression test and fix bugs, next milestone is pike-rc. [1]https://review.openstack.org/#/c/488904/ Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]
Hello, Meher, For the second node, the devstack configuration file local.conf should be configured carefully, especially for the keystone part(sample file https://github.com/openstack/tricircle/blob/master/devstack/local.conf.node_2.sample): HOST_IP=10.250.201.25 REGION_NAME=RegionTwo KEYSTONE_REGION_NAME=RegionOne SERVICE_HOST=$HOST_IP KEYSTONE_SERVICE_HOST=10.250.201.24 KEYSTONE_AUTH_HOST=10.250.201.24 HOST_IP is the second node's IP, KEYSTONE_SERVICE_HOST/KEYSTONE_AUTH_HOST should be configured with the first node's IP. Best Regards Chaoyi Huang (joehuang) From: meher.h...@orange.com [meher.h...@orange.com] Sent: 31 July 2017 21:31 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [tricircle] Hello everybody, I just installed Tricirle on a single node. Now I'm trying to install it on two nodes (two VMs), everything was fine with the first node, Tricirle is well installed, on the second node, at the end of the script install it stops on An error "Failed to discover available versions when contacting http://192.168.123.129/identity. Attempting to parse version from URL.” So it seems that there is a connection problem with the keystone service on the first machine, as far as the connectivity between the 2 nodes is concerned, it is perfect. I am sending you this mail to find out if anyone can help me on this. I thank you in advance! Regards, Meher [Logo Orange]<http://www.orange.com/> Meher Hihi Intern ORANGE/IMT/OLN/WTC/CMA/MAX Fixe : +33 2 96 07 03 71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371> Mobile : +33 7 58 38 68 87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887> meher.h...@orange.com<mailto:meher.h...@orange.com> _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. __ 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] [release]need help for python-tricircleclient
Hello, Very sorry for the deadline missing even if it's few hours, and won't let it happen next time. I was waiting for one patch about pagination support in tricircle ( not python-tricircleclient). If pagination for resource routing and job have not been supported well in tricircle, it's not good to publish these features in python-tricircleclient: python-tricircleclient will list resource routing and job from Tricircle Admin API, if there are huge amount of resource routing and job records, without pagination support, a query will easily lead to the db server keep in busy status: the list operation will make db server eat too much resources, even make the db server stopping response for other request. Because the patch is almost done, so extra few hours were paid to this patch, so that python-tricircleclient can include these useful features in pike, otherwise only pod management feature can be included in python-tricircleclient. Best Regards Chaoyi Huang (joehuang) From: Thierry Carrez [thie...@openstack.org] Sent: 31 July 2017 21:04 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [release]need help for python-tricircleclient joehuang wrote: > The patch [1] is to add a tag for python-tricircleclient after new > features were added to it since last release. But unfortunately, a > branch called "stable/pike" was there in Apr., and lead to the patch can > not pass the gate test. This release request missed the deadline for client libraries releases (if only by a few hours), so we already created the stable/pike branch from the last available Pike release (0.1.1 from April 2017). Given (1) that the deadline was not missed by much, (2) that the last available release was quite old, and (3) that no other project depends on python-tricircleclient, damage would be limited in cutting 0.2.0 now and recreating stable/pike from it. We'll coordinate with infra to make it happen. Next time, please don't miss the deadline and create additional work for the release team ! -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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] [release]need help for python-tricircleclient
Hello, The patch [1] is to add a tag for python-tricircleclient after new features were added to it since last release. But unfortunately, a branch called "stable/pike" was there in Apr., and lead to the patch can not pass the gate test. "deliverables/pike/python-tricircleclient.yaml: openstack/python-tricircleclient 563f700b62de6b57671ec077293da6fa348c250a not present in pike branch" Shall I cherry pick all latest introduced patches from master to the stable/pike branch, or the old branch which was created in Apr. should be renamed? [1] https://review.openstack.org/#/c/488903/ Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]PTL non-candidacy
Hello, all, Next cycle PTL nomination is approaching, as I announced in the last weekly meeting, I am not planning to run for Queen PTL position. It's exciting and joyful journey to work in the Tricircle project, not only for the interesting features, but also for the excellent team: 1) Basic tenant L2/L3 networking among OpenStack regions can work now, and it's quite useful to help applications achieve cloud level high availability: https://www.youtube.com/watch?v=tbcc7-eZnkY 2) Tricircle+Neutron can also work with Nova cells V2 to scale single OpenStack, it's something more than what we have planned. I would like to thank everyone who has contributed/is contributing in Tricricle, and I'm sure community can continue making it even better. Nomination period will start soon, whoever the next PTL might be, I'll continue serving as core reviewer to help the project. Thank you very much and best wishes. Best Regards Chaoyi Huang (joehuang) __ 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] TR: [tricircle]
Hi Meher, Yes, as Victor pointed out, it should be done by the devstack script. But in our daily development, I use (maybe most of us) Ubuntu to install Tricircle through devstack, so not sure whether there is some bug under RHEL, and I have no RHEL distribution. Best Regards Chaoyi Huang (joehuang) From: Morales, Victor [victor.mora...@intel.com] Sent: 12 July 2017 0:13 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] TR: [tricircle] Hi Meher, I don’t think that you need to create those folders or at least that it’s shown in the devstack functions[1]. Regards/Saludos Victor Morales [1] https://github.com/openstack-dev/devstack/blob/master/lib/apache#L178-L192 From: "meher.h...@orange.com" Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Tuesday, July 11, 2017 at 7:51 AM To: "openstack-dev@lists.openstack.org" Subject: [openstack-dev] TR: [tricircle] [ogo Orange]<http://www.orange.com/> Meher Hihi Intern ORANGE/IMT/OLN/WTC/CMA/MAX Fixe : +33 2 96 07 03 71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371> Mobile : +33 7 58 38 68 87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887> meher.h...@orange.com<mailto:meher.h...@orange.com> De : HIHI Meher IMT/OLN Envoyé : mardi 11 juillet 2017 14:50 À : HIHI Meher IMT/OLN Objet : RE: [openstack-dev][tricircle] Hi Zhiyuan, Thank you for the response! So, in this case, I just need to create two "sites-available" and "sites-enabled" folders under /etc/ httpd and put in the config files found in /etc/httpd/conf.d/? Regards, Meher [ogo Orange]<http://www.orange.com/> Meher Hihi Intern ORANGE/IMT/OLN/WTC/CMA/MAX Fixe : +33 2 96 07 03 71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371> Mobile : +33 7 58 38 68 87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887> meher.h...@orange.com<mailto:meher.h...@orange.com> De : HIHI Meher IMT/OLN Envoyé : lundi 10 juillet 2017 16:10 À : 'openstack-dev@lists.openstack.org' Objet : RE: [openstack-dev][tricircle] Hello everybody, I posted before a problem related to installing the tricircle on a single node, the script stopped with a keystone startup. You advised me to see the / etc / apache2 / sites-enabled folder to see if the keystone config files are included. But, I have not found this folder, yet the httpd service is properly installed, the name of this file changes according to the distribution? I use RHEL 7, thank you in advance! Meher [ogo Orange]<http://www.orange.com/> Meher Hihi Intern ORANGE/IMT/OLN/WTC/CMA/MAX Fixe : +33 2 96 07 03 71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371> Mobile : +33 7 58 38 68 87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887> meher.h...@orange.com<mailto:meher.h...@orange.com> De : HIHI Meher IMT/OLN Envoyé : mercredi 28 juin 2017 15:12 À : 'openstack-dev@lists.openstack.org' Objet : [openstack-dev][tricircle] Hello everyone, I introduce myself; Meher Hihi; I am doing my internship at Orange Labs Networks Lannion-France for the diploma of computer network and telecommunications engineer. I am working on innovative distribution solutions for the virtualization infrastructure of the network functions and more specifically on the Openstack Tricircle solution, which is why I join your community to participate in your discussions and learn from your advice. Indeed, I try to install Tricircle on a single node by following this documentation “https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack”. I managed to install Devstack without any problems, but when I modify the local.conf file by adding the Tricircle plugin integration and the HOST_IP, the script does not want to work and stops on an error of Start of the Keystone service. I wanted to know if the problem is with my config file that is attached or I lack other things to configure. You will also find in the file the IP address of the machine. I thank y
Re: [openstack-dev] [tricircle]
Hello, Meher Except checking the sites-enabled in Apache, because single-node installation is mainly for very limited feature development, multi-node installation is recommended: https://docs.openstack.org/developer/tricircle/installation-guide.html#multi-pod-installation-with-devstack If you only have one node, you don't need to install the second node even if you follow the multi-node guide. You can also talk to us directly through IRC channel #openstack-tricircle in freenode. Best Regards Chaoyi Huang (joehuang) From: Vega Cai [luckyveg...@gmail.com] Sent: 29 June 2017 10:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tricircle] Hi Meher, Welcome to join Tricircle! Both Keystone and Tricircle services are running under Apache, so if Keystone failed to start after enabling Tricircle, I guess there might be some problems of Apache configuration. You can check what services are enabled in Apache by listing this folder: /etc/apache2/sites-enabled. tricircle@zhiyuan-1:~/devstack$ ls /etc/apache2/sites-enabled/ keystone-wsgi-admin.conf keystone-wsgi-public.conf nova-placement-api.conf tricircle-api.conf Above is the result from my Ubuntu machine. Also, could you provide me the log of DevStack after enabling Tricircle so I can get more hints. BR Zhiyuan On Wed, 28 Jun 2017 at 21:17 mailto:meher.h...@orange.com>> wrote: Hello everyone, I introduce myself; Meher Hihi; I am doing my internship at Orange Labs Networks Lannion-France for the diploma of computer network and telecommunications engineer. I am working on innovative distribution solutions for the virtualization infrastructure of the network functions and more specifically on the Openstack Tricircle solution, which is why I join your community to participate in your discussions and learn from your advice. Indeed, I try to install Tricircle on a single node by following this documentation “https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack”. I managed to install Devstack without any problems, but when I modify the local.conf file by adding the Tricircle plugin integration and the HOST_IP, the script does not want to work and stops on an error of Start of the Keystone service. I wanted to know if the problem is with my config file that is attached or I lack other things to configure. You will also find in the file the IP address of the machine. I thank you in advance for the help you will bring me. Sincerely, Best regards, Meher <http://www.orange.com/> Meher Hihi Intern ORANGE/IMT/OLN/WNI/ODIS/NAVI Fixe : +33 2 96 07 03 71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371> Mobile : +33 7 58 38 68 87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887> meher.h...@orange.com<mailto:meher.h...@orange.com> _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- BR Zhiyuan __ 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] [tricircle] Tricircle vs Trio2o
Hello, Silvia, Thank you for your interest in Tricircle and Trio2o. See inline comments. Best Regards Chaoyi Huang (joehuang) From: Silvia Fichera [fichera@gmail.com] Sent: 28 June 2017 5:16 To: OpenStack Development Mailing List (not for usage questions); openst...@lists.openstack.org Subject: [openstack-dev] [tricircle] Tricircle vs Trio2o Hi all, I would like to build up a multi-region openstack and I read that both tricircle and trio2o are the most suitable solutions. I have few questions: - from the wikis I couldn't deeply understand the differences between the two: ad far as I understood tricircle deploys a shared neutron module, trio2o provides a gateway in the case of a single nova/glance module.Is it right? [joehuang] Yes, Tricircle is to provide networking capability across multiple neutron servers in OpenStack mult-region deployment or Nova cells V2 multi-cell deployment, one shared Neutron module providing such cross Neutron server functionalities and provide the API entrance. For trio2o, it's major purpose is to gateway, and it's not active after it's moved outside from Tricircle, during the Tricricle bightent application, some TCs were worried about the API consistency if one gateway layer is there, so it's not accepted into OpenStack. Though I know many cloud operators expressed the need for single API entry point for multiple OpenStack instances. [/joehuang] - Could you better explain the architecture? For instance: where is the Controller? Are the compute nodes the same of the one site implementation? [joehuang] for the architecture and work flow, you can refer to the slides and video we presented in OPNFV Beijing summit: video https://www.youtube.com/watch?v=tbcc7-eZnkY , slides https://docs.google.com/presentation/d/1WBdra-ZaiB-K8_m3Pv76o_jhylEqJXTTxzEZ-cu8u2A/ , https://www.slideshare.net/JoeHuang7/shared-networks-to-support-vnf-high-availability-across-openstack-multiregion-deployment-77283728 I don't know what do you mean for Controller, Tricircle only provides plugins to Neutron: Neutron server with different plugin plays different role, for central Neutron with Tricicle central plugin, it'll play as the networking coordination for multiple local Neutrons which will be installed with Tricircle local plugin. Each local Neutron work as usual with ML2 plugin/OVS backend or SDN controller backend, just install one slim hook layer of Tricircle local Neutron plugin. You can experience it through the guide: https://docs.openstack.org/developer/tricircle/installation-guide.html#multi-pod-installation-with-devstack [/joehuang] - Is it possible to connect distributed compute nodes with an SDN network, in order to use it as data plane? [joehuang] Yes, it's possible with an SDN network, currently we use in-tree OVS implemetation to connect distributed compute nodes, Tricricle is able to carry shadow port/shadow agent information to other Neutron servers, so SDN controller can use these information to build cross Neutron network. If SDN controller can communicate with each other by themselves, and establish cross Neutron network, it's also fine, Tricircle support this mode. During OPNFV summit, Vikram and I had one idea to see if OVN can work together with Tricircle. Could you describe your idea for the SDN network in more detail, then I can check whether my understanding is correct, and provide my valuable comment. [/joehuang] - If not, what kind of network is in the middle? I suppose that a network is necessary to connect the different pod. [joehuang] Please refer to the last comment [/joehuang] Could you please clarify these points? Thanks a lot -- Silvia Fichera __ 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] [tricircle]weekly meeting of Jun.28
Hello, team, Agenda of Jun.28 weekly meeting: 1. feature implementation review 2. Community wide goals, PTG and Sydney summit topics 3. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 1:00. Best Regards Chaoyi Huang (joehuang) __ 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] An idea about how to deploy multi Nova cells v2 using devstack
Hello, Currently Nova has one patch in review to deploy multi-cells for Cells V2, https://review.openstack.org/#/c/436094/ And Tricircle also provide one documentation on how how to deploy nova cells v2 + Tricricle: https://docs.openstack.org/developer/tricircle/installation-guide.html#work-with-nova-cell-v2-experiment . And there are may be some issue will happen, you can refer to the trouble shooting section. Best Regards Chaoyi Huang (joehuang) From: David Mckein [davidmck...@gmail.com] Sent: 23 June 2017 10:24 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] An idea about how to deploy multi Nova cells v2 using devstack Hello, I would like to experiment multi Nova cells v2. I found some references about Nova cells v2. But It's not about multi cells v2 and how to deploy it. I really want to know if there is a document or idea about how to deploy multi Nova cells v2. I want to know where I can refer and what is going on, please. Yours Truly David Mckein __ 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] [neutron] Do we still support core plugin not based on the ML2 framework?
Hi, Tricricle is based on core plugin interface, so if you want to refactory the interface, let us know whether it'll break Tricricle. And I don't know whether there other plugins are using this interface. And there is one conclusion in this document(https://github.com/openstack/neutron-specs/blob/master/specs/newton/neutron-stadium.rst): To provide composable networking solutions: the ML2/Service plugin framework was introduced many cycles ago to enable users with freedom of choice. Many solutions have switched to using ML2/Service plugins for high level services over the years. Although some plugins still use the core plugin interface to provide end-to-end solutions, the criterion to enforce the adoption of ML2 and service plugins for Neutron Stadium projects does not invalidate, nor does make monolithic solutions deprecated. It is simply a reflection of the fact that the Neutron team stands behind composability as one of the promise of open networking solutions. During code review the Neutron team will continue to ensure that changes and design implications do not have a negative impact on out of tree code irrespective of whether it is part of the Stadium project or not. Best Regards Chaoyi Huang (joehuang) From: Édouard Thuleau [edouard.thul...@gmail.com] Sent: 21 June 2017 16:45 To: OpenStack Development Mailing List (not for usage questions); ke...@benton.pub Cc: Sachin Bansal Subject: Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework? Ok, we would like to help on that. How we can start? I think the issue I raise in that thread must be the first point to address and my second proposition seems to be the correct one. What do you think? But it will needs some time and not sure we'll be able to fix all service plugins loaded by default before the next Pike release. I like to propose a workaround until all default service plugins will be compatible with non-DB core plugins. We can continue to load that default service plugins list but authorizing a core plugin to disable it completely with a private attribut on the core plugin class like it's done for bulk/pagination/sorting operations. Of course, we need to add the ability to report any regression on that. I think unit tests will help and we can also work on a functional test based on a fake non-DB core plugin. Regards, Édouard. On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton wrote: > The issue is mainly developer resources. Everyone currently working upstream > doesn't have the bandwidth to keep adding/reviewing the layers of interfaces > to make the DB optional that go untested. (None of the projects that would > use them run a CI system that reports results on Neutron patches.) > > I think we can certainly accept patches to do the things you are proposing, > but there is no guarantee that it won't regress to being DB-dependent until > there is something reporting results back telling us when it breaks. > > So it's not that the community is against non-DB core plugins, it's just > that the people developing those plugins don't participate in the community > to ensure they work. > > Cheers > > > On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau > wrote: >> >> Oops, sent too fast, sorry. I try again. >> >> Hi, >> >> Since Mitaka release, a default service plugins list is loaded when >> Neutron >> server starts [1]. That list is not editable and was extended with few >> services >> [2]. But all of them rely on the Neutron DB model. >> >> If a core driver is not based on the ML2 core plugin framework or not >> based on >> the 'neutron.db.models_v2' class, all that service plugins will not work. >> >> So my first question is Does Neutron still support core plugin not based >> on ML2 >> or 'neutron.db.models_v2' class? >> >> If yes, I would like to propose two solutions: >> - permits core plugin to overload the service plugin class by it's own >> implementation and continuing to use the actual Neutron db based services >> as >> default. >> - modifying all default plugin service to use service plugin driver >> framework [3], and set the actual Neutron db based implementation as >> default driver for services. That permits to core drivers not based on the >> Neutron DB to specify a driver. We can see that solution was adopted in >> the >> networking-bgpvpn project, where can find two abstract driver classes, one >> for >> core driver based on Neutron DB model [4] and one used by core driver not >> based >> on the DB [5] as the Contrail driver [6]. >> >> [1] >> https://github.com/openstack/neutron/com
Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology
Hi, If we just want to replace "bigtent" concept to another concept which mentioned in this thread, many of them gave me the impression that there are still some projects more important than others, so that's why I suggest to use flat project list, and put stress "OPEN" stack here. Best Regards Chaoyi Huang (joehuang) From: Flavio Percoco [fla...@redhat.com] Sent: 21 June 2017 15:44 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all][tc] Moving away from "bigtent" terminology On 21/06/17 06:18 +, joehuang wrote: >hello, Flavio, Hi :D >This thread is to discuss moving away from the "big tent" term, not removing >some project. >Removing a project will make this flavor disappear from the ice-cream counter, >but this thread, >it's to use another concept to describe projects under openstack project >governance. >If we don't want to use "big tent" for those projects staying in the counter, >I hope all projects could be treated in flat, just like different flavor >ice-creams are flat in the >same counter, kid can make choice by themselves. > >Even Nova may be only "core" to some cloud operators, but not always for all >cloud operators, >for example, those who only run object storage service, hyper.sh also not use >Nova, some day may >some cloud operators only use Zun or K8S instead for computing, it should not >be an issue >to OpenStack community. I think you misunderstood my message. I'm not talking about removing projects, I'm talking about the staging of these projects to join the "Big tent" - regardless of how we call it. The distinction *is* important and we ought to find a way to preserve it and communicate it so that there's the least amount of confusion possible. >OpenStack should be "OPEN" stack for infrastructure, just like kid can choose >how many >balls of ice-cream, cloud operators can make decision to choose which project >to use or >not to manage his infrastructure. You keep mentioning "OPEN stack" as if we weren't being open (enough?) and I think I'm failing to see why you think that. Could you please elaborate more? What you're describing seems to be the current status. Flavio >Best Regards >Chaoyi Huang (joehuang) > > >From: Flavio Percoco [fla...@redhat.com] >Sent: 20 June 2017 17:44 >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [all][tc] Moving away from "bigtent" >terminology > >On 20/06/17 00:33 +, joehuang wrote: >>I think openstack community provides a flat project market place for >>infrastructure is good enough: >> >>all projects are just some "goods" in the market place, let the cloud >>operators to select projects >>from the project market place for his own infrastructure. >> >>We don't have to mark a project a core project or not, only need to tag >>attribute of a project, for >>example how mature it is, how many "like" they have, what the cloud operator >>said for the project. etc. >> >>All flat, just let people make decision by themselves, they are not idiot, >>they have wisdom >>on building infrastructure. >> >>Not all people need a package: you bought a package of ice-cream, but not all >>you will like it, >>If they want package, distribution provider can help them to define and >>customize a package, if >>you want customization, you will decide which ball of cream you want, isn't >>it? > >The flavors you see in a ice-creem shop counter are not there by accident. >Those >flavors have gone through a creation process, they have been tested and they >have also survived over the years. Some flavors are removed with time and some >others stay there forever. > >Unfortunately, tagging those flavors won't cut it, which is why you don't see >tags in their labels when you go to an ice-cream shop. Some tags are implied, >other tags are inferred and other tags are subjective. > >Experimenting with new flavors doesn't happen overnight in some person's >bedroom. The new flavors are tested using the *same* infrastructure as the >other >flavors and once they reach a level of maturity, they are exposed in the >counter >so that customers will able to consume them. > >Ultimately, experimentation is part of the ice-cream shop's mission and it >requires time, effort and resources but not all experiments end well. At the >end, though, what really ma
Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology
hello, Flavio, This thread is to discuss moving away from the "big tent" term, not removing some project. Removing a project will make this flavor disappear from the ice-cream counter, but this thread, it's to use another concept to describe projects under openstack project governance. If we don't want to use "big tent" for those projects staying in the counter, I hope all projects could be treated in flat, just like different flavor ice-creams are flat in the same counter, kid can make choice by themselves. Even Nova may be only "core" to some cloud operators, but not always for all cloud operators, for example, those who only run object storage service, hyper.sh also not use Nova, some day may some cloud operators only use Zun or K8S instead for computing, it should not be an issue to OpenStack community. OpenStack should be "OPEN" stack for infrastructure, just like kid can choose how many balls of ice-cream, cloud operators can make decision to choose which project to use or not to manage his infrastructure. Best Regards Chaoyi Huang (joehuang) From: Flavio Percoco [fla...@redhat.com] Sent: 20 June 2017 17:44 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all][tc] Moving away from "bigtent" terminology On 20/06/17 00:33 +, joehuang wrote: >I think openstack community provides a flat project market place for >infrastructure is good enough: > >all projects are just some "goods" in the market place, let the cloud >operators to select projects >from the project market place for his own infrastructure. > >We don't have to mark a project a core project or not, only need to tag >attribute of a project, for >example how mature it is, how many "like" they have, what the cloud operator >said for the project. etc. > >All flat, just let people make decision by themselves, they are not idiot, >they have wisdom >on building infrastructure. > >Not all people need a package: you bought a package of ice-cream, but not all >you will like it, >If they want package, distribution provider can help them to define and >customize a package, if >you want customization, you will decide which ball of cream you want, isn't it? The flavors you see in a ice-creem shop counter are not there by accident. Those flavors have gone through a creation process, they have been tested and they have also survived over the years. Some flavors are removed with time and some others stay there forever. Unfortunately, tagging those flavors won't cut it, which is why you don't see tags in their labels when you go to an ice-cream shop. Some tags are implied, other tags are inferred and other tags are subjective. Experimenting with new flavors doesn't happen overnight in some person's bedroom. The new flavors are tested using the *same* infrastructure as the other flavors and once they reach a level of maturity, they are exposed in the counter so that customers will able to consume them. Ultimately, experimentation is part of the ice-cream shop's mission and it requires time, effort and resources but not all experiments end well. At the end, though, what really matters is that all these flavors serve the same mission and that's why they are sold at the ice-cream shop, that's why they are exposed in the counter. Customer's of the ice-cream shop know they can trust what's in the counter. They know the exposed flavors serve their needs at a high level and they can now focus on their specific needs. So, do you really think it's just a set of flavors and it doesn't really matter how those flavors got there? Flavio -- @flaper87 Flavio Percoco __ 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] [tricircle]weekly meeting of Jun.21
Hello, team, Agenda of Jun.21 weekly meeting: 1. summary of tricircle demo in OPNFV summit 3. feature implementation review 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 1:00. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]weekly meeting of Jun.21
Hello, team, Agenda of Jun.20 weekly meeting: 1. summary of tricircle demo in OPNFV summit 3. feature implementation review 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 1:00. Best Regards Chaoyi Huang (joehuang) __ 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] [nova][tricircle] CellsV2 in Pike?
Thank you very much, Matt, that's great news. Best Regards Chaoyi Huang (joehuang) From: Matt Riedemann [mriede...@gmail.com] Sent: 20 June 2017 9:29 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][tricircle] CellsV2 in Pike? On 6/19/2017 8:02 PM, joehuang wrote: > Hello, > > In May, Tricircle has done some work to make Nova cells V2 + Neutron + > Tricircle work together[1]: each cell will have corresponding local > Neutron with Tricricle local plugin installed, and one central Neutron > server work together with Nova API server, where the Tricricle central > plugin installed. > > Would like to know how far multi-cells will be supported for CellsV2 in > Pike release, so that Tricircle can do more verification of this > deployment option. > > [1]http://lists.openstack.org/pipermail/openstack-dev/2017-May/117599.html > > Best Regards > Chaoyi Huang (joehuang) > > > __ > 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 > Hi Joe, Tempest is passing on this devstack change [1] which enables a multi-cell environment. We're still finding some random things that need to be aware of a multi-cell deployment and are working through those, but at this point we expect to be able to declare support for multiple cells v2 cells in Pike. [1] https://review.openstack.org/#/c/436094/ -- Thanks, Matt __ 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] [nova][tricircle] CellsV2 in Pike?
Hello, In May, Tricircle has done some work to make Nova cells V2 + Neutron + Tricircle work together[1]: each cell will have corresponding local Neutron with Tricricle local plugin installed, and one central Neutron server work together with Nova API server, where the Tricricle central plugin installed. Would like to know how far multi-cells will be supported for CellsV2 in Pike release, so that Tricircle can do more verification of this deployment option. [1]http://lists.openstack.org/pipermail/openstack-dev/2017-May/117599.html Best Regards Chaoyi Huang (joehuang) __ 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][tc] Moving away from "big tent" terminology
I think openstack community provides a flat project market place for infrastructure is good enough: all projects are just some "goods" in the market place, let the cloud operators to select projects from the project market place for his own infrastructure. We don't have to mark a project a core project or not, only need to tag attribute of a project, for example how mature it is, how many "like" they have, what the cloud operator said for the project. etc. All flat, just let people make decision by themselves, they are not idiot, they have wisdom on building infrastructure. Not all people need a package: you bought a package of ice-cream, but not all you will like it, If they want package, distribution provider can help them to define and customize a package, if you want customization, you will decide which ball of cream you want, isn't it? openstack is "OPEN" stack. Best Regards Chaoyi Huang (joehuang) From: Matt Riedemann [mriede...@gmail.com] Sent: 19 June 2017 22:56 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology On 6/17/2017 10:55 AM, Jay Bryant wrote: > > I am responding under Tim's note because I think it gets at what we > really want to communicate and takes me to what we have presented in > OUI. We have Core OpenStack Projects and then a whole community of > additional projects that support cloud functionality. > > So, without it being named, or cutesy, though I liked "Friends of > Openstack", can we go with "OpenStack Core Projects" and "Peripheral > OpenStack Projects"? Because then you have to define what "core" means, and how you get to be "core", which is like the old system of integrated and incubated projects. I agree that a "core" set of projects is more understandable at first, probably most for an outsider. But it gets confusing from a governance perspective within the community. And if you want to run just containers with Kubernetes and you want to use Keystone and Cinder with it, you don't need Nova, so is Nova "core" or not? This is probably where the constellations idea comes in [1]. At the end of the day it's all OpenStack to me if it's hosted on OpenStack infra, but I'm not the guy making budget decisions at a company determining what to invest in. I think Doug has tried to explain that perspective a bit elsewhere in this thread, and it sounds like that's the key issue, the outside perspective from people making budget decisions. [1] https://review.openstack.org/#/c/453262/ -- Thanks, Matt __ 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] [nova][neutron]Nova cells v2+Neutron+Tricircle, it works
Hello, Matt, See inline comments with [joehuang] Best Regards Chaoyi Huang (joehuang) From: Matt Riedemann [mriede...@gmail.com] Sent: 07 June 2017 10:09 To: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org Subject: Re: [openstack-dev] [nova][neutron]Nova cells v2+Neutron+Tricircle, it works On 5/28/2017 6:58 PM, joehuang wrote: > Hello, > > There is one session in OpenStack Boston summit about Neutron > multi-site, and discuss how to make Neutron cells-aware[1]. > > We have done experiment how Nova cells v2 + Neutron + Tricircle can work > very well: Thanks for testing this out Joe. It's great to get some feedback about people experimenting with cells v2, especially this close to master - we generally seem to have a 12-18 month latency on feedback for big things like this so it's hard to react quickly to something a year old. :) > > Follow the guide[2], you will have one two cells environment: cell1 in > node1 and cell2 in node2, and Nova-api/scheduler/conductor/placement in > node1. To simplify the integration, the region for Nova-api is > registered as CentralRegion in KeyStone. This sounds sort of like what Dan Smith is doing in devstack for upstream CI: https://review.openstack.org/#/c/436094/ That's a 2-node job so we have to turn it into multi-cell with just those two nodes, and one has to be running the controller services. > > At the same time, the tricircle devstack plugin will also install > RegionOne Neutron in node1 to work with cell1, RegionTwo Neutron in > node2, i,e, we'll have one local Neutron with one cell, the neutron > endpoint url in cell's compute node will be configured to local Neutron. > each local Neutron will be configured with Tricircle local Neutron plugin. > > We just mentioned that Nova-API is registered as CentralRegion, the > tricircle devstack plugin will also start a central Neutron server and > register it in CentralRegion( same region as Nova-API), the central > Neutron server will be installed with Tricircle central Neutron plugin. > In Nova-api's configuration nova.conf, the neutron endpoint url is > configured to the central Neutron server's url. If I'm understanding this correctly, nova-api will talk to Tricircle which is federating the networking API for Neutron across the two regions for "local" Neutron, right? [joehuang] nova-api talk to central Neutron server, but not Tricircle. The central neutron server is installed with Tricircle central plugin But what about nova-compute running within the cells? Are those talking *only* to the Neutron deployed local to the same cell that nova-compute is in? Or can each nova-compute talk to the central Neutron server? [joehuang] nova-compute talking *only* to the Neutron deployed local to the same cell that nova-compute is in I think most of us in Nova have been considering external services as global to Nova, so Neutron, Glance, Placement, Keystone and Cinder. We don't support move operations, e.g. live migration, for server instances across cells yet, but when we do we'd need to know the Neutron topology to know which hosts we can send an instance to. This is sort of touched on in the Neutron routed networks spec for Nova, which involves using the Placement service for defining aggregate associations between compute hosts and pools of network resources: https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html [joehuang] routed network can address neutron scalability to some extent, but it just leaves the tenant network isolation and management to the outside world. The complexity is still there, but just outside Neutron/Nova, if we don't care about tenant's network isolation, then it's ok. For tricircle support VxLAN, the overlay network can be extended to the host you want to migrate to. In routed network , You have to know the network topology, because the network connectivity is defined outside Neutron, but not inside Neutron, some host may be not connected to this network. So compared to routed network, Tricircle provides more flexible and tenant isolated networking capability through Neutron. > > In both central Neutron server and local Neutron, the nova endpoint url > configuration will be pointed to central Nova-api url, it's for > call-back message to Nova-API. Yup, so either Neutron sends an event to the central nova-api endpoint which knows which cell an instance is in and can route the message appropriately. I'm thinking of the os-server-external-events API in this case. > > After the installation, now you have one CentralRegion with one Nova API > and one Neutron Server, and regard to Nova multi-cells, each cell is > accompanied with one local Neutron. ( It's not necessary for 1
[openstack-dev] [nova][neutron]Nova cells v2+Neutron+Tricircle, it works
Hello, There is one session in OpenStack Boston summit about Neutron multi-site, and discuss how to make Neutron cells-aware[1]. We have done experiment how Nova cells v2 + Neutron + Tricircle can work very well: Follow the guide[2], you will have one two cells environment: cell1 in node1 and cell2 in node2, and Nova-api/scheduler/conductor/placement in node1. To simplify the integration, the region for Nova-api is registered as CentralRegion in KeyStone. At the same time, the tricircle devstack plugin will also install RegionOne Neutron in node1 to work with cell1, RegionTwo Neutron in node2, i,e, we'll have one local Neutron with one cell, the neutron endpoint url in cell's compute node will be configured to local Neutron. each local Neutron will be configured with Tricircle local Neutron plugin. We just mentioned that Nova-API is registered as CentralRegion, the tricircle devstack plugin will also start a central Neutron server and register it in CentralRegion( same region as Nova-API), the central Neutron server will be installed with Tricircle central Neutron plugin. In Nova-api's configuration nova.conf, the neutron endpoint url is configured to the central Neutron server's url. In both central Neutron server and local Neutron, the nova endpoint url configuration will be pointed to central Nova-api url, it's for call-back message to Nova-API. After the installation, now you have one CentralRegion with one Nova API and one Neutron Server, and regard to Nova multi-cells, each cell is accompanied with one local Neutron. ( It's not necessary for 1:1 mapping between cell and local Neutron, may multi-cells mapped to one local Neutron). If you create network/router without availability-zone specified, global network/router is applied, all instances from any cell can be attached to. If you create network/router with availability-zone specified, you can get scoped network/router, i.e, the network/router can only be presented in regarding cells. Note: 1. Because Nova multi-cells is still under development, there will be some issue in deployment and experience, some typical trouble shooting has been provided in the document[2]. 2. For the RegionOne and RegionTwo name which is registered by local Neutron, you can change it to other better name if needed, for example "cell1-subregion", "cell2-subregion", etc. Feedback and contribution are welcome to make this mode works. [1]http://lists.openstack.org/pipermail/openstack-dev/2017-May/116614.html [2]https://docs.openstack.org/developer/tricircle/installation-guide.html#work-with-nova-cell-v2-experiment Best Regards Chaoyi Huang (joehuang) __ 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][cinder][glance][neutron][horizon][policy] defining admin-ness
I think a option 2 is better. Best Regards Chaoyi Huang (joehuang) From: Lance Bragstad [lbrags...@gmail.com] Sent: 25 May 2017 3:47 To: OpenStack Development Mailing List (not for usage questions); openstack-operat...@lists.openstack.org Subject: Re: [openstack-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness I'd like to fill in a little more context here. I see three options with the current two proposals. Option 1 Use a special admin project to denote elevated privileges. For those unfamiliar with the approach, it would rely on every deployment having an "admin" project defined in configuration [0]. How it works: Role assignments on this project represent global scope which is denoted by a boolean attribute in the token response. A user with an 'admin' role assignment on this project is equivalent to the global or cloud administrator. Ideally, if a user has a 'reader' role assignment on the admin project, they could have access to list everything within the deployment, pending all the proper changes are made across the various services. The workflow requires a special project for any sort of elevated privilege. Pros: - Almost all the work is done to make keystone understand the admin project, there are already several patches in review to other projects to consume this - Operators can create roles and assign them to the admin_project as needed after the upgrade to give proper global scope to their users Cons: - All global assignments are linked back to a single project - Describing the flow is confusing because in order to give someone global access you have to give them a role assignment on a very specific project, which seems like an anti-pattern - We currently don't allow some things to exist in the global sense (i.e. I can't launch instances without tenancy), the admin project could own resources - What happens if the admin project disappears? - Tooling or scripts will be written around the admin project, instead of treating all projects equally Option 2 Implement global role assignments in keystone. How it works: Role assignments in keystone can be scoped to global context. Users can then ask for a globally scoped token Pros: - This approach represents a more accurate long term vision for role assignments (at least how we understand it today) - Operators can create global roles and assign them as needed after the upgrade to give proper global scope to their users - It's easier to explain global scope using global role assignments instead of a special project - token.is_global = True and token.role = 'reader' is easier to understand than token.is_admin_project = True and token.role = 'reader' - A global token can't be associated to a project, making it harder for operations that require a project to consume a global token (i.e. I shouldn't be able to launch an instance with a globally scoped token) Cons: - We need to start from scratch implementing global scope in keystone, steps for this are detailed in the spec Option 3 We do option one and then follow it up with option two. How it works: We implement option one and continue solving the admin-ness issues in Pike by helping projects consume and enforce it. We then target the implementation of global roles for Queens. Pros: - If we make the interface in oslo.context for global roles consistent, then consuming projects shouldn't know the difference between using the admin_project or a global role assignment Cons: - It's more work and we're already strapped for resources - We've told operators that the admin_project is a thing but after Queens they will be able to do real global role assignments, so they should now migrate *again* - We have to support two paths for solving the same problem in keystone, more maintenance and more testing to ensure they both behave exactly the same way - This can get more complicated for projects dedicated to testing policy and RBAC, like Patrole Looking for feedback here as to which one is preferred given timing and payoff, specifically from operators who would be doing the migrations to implement and maintain proper scope in their deployments. Thanks for reading! [0] https://github.com/openstack/keystone/blob/3d033df1c0fdc6cc9d2b02a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342 On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad mailto:lbrags...@gmail.com>> wrote: Hey all, To date we have two proposed solutions for tackling the admin-ness issue we have across the services. One builds on the existing scope concepts by scoping to an admin project [0]. The other introduces global role assignments [1] as a way to denote elevated privileges. I'd like to get some feedback from operators, as well as developers from other projects, on each approach. Since work is required in
[openstack-dev] [tricircle]weekly meeting of May.24
Hello, team, Agenda of May.24 weekly meeting: 1. feature implementation review 2. Pike-2 preparation 3. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 01:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] Project On-Boarding Info Collection
Hello, Not use a training slides in Tricricle on-boarding session, and would like to create one for new contributors later. For the summary of the on-boarding session, have replied in another thread which collects feedback. Best Regards Chaoyi Huang (joehuang) From: Kendall Nelson [kennelso...@gmail.com] Sent: 09 May 2017 2:57 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] Project On-Boarding Info Collection Hello! If you are running a project onboarding session and have etherpads/slides/ etc you are using to educate new contributors please send them to me! I am collecting all the resources you are sharing into a single place for people that weren't able to attend sessions. Thanks! Kendall (diablo_rojo) __ 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] Onboarding rooms postmortem, what did you do, what worked, lessons learned
Tricircle shared a room with Sahara, and stay there for the first half. Around 6 persons joined the session. Due to the network issue(on the lab side) I am not able to logon to my environment to do the training based on live environment. I have to play some recorded clips, during the playing, we discussed a lot of topics, from the overall architecture and functionalities, and whether it support cross Neutron L2 network, and how to setup the environment to experience it. I can't remember all detail information. It seems 45 minutes is too short for on-boarding session, lots of other topics have not been discussed. We leave the room after Sahara began their session, two projects in same room will be quite noise, many people will talk at the same time. After the session, one guy continue to talk with me about Tricircle for around half an hour. Obviously, on-boarding session is necessary for a project, some may be contributors, some may be not, but there are lots of people want to learn a project in more detail, it'll help a project to grow contributors and (potential) operators. Best Regards Chaoyi Huang (joehuang) From: Sean Dague [s...@dague.net] Sent: 19 May 2017 21:22 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned This is a thread for anyone that participated in the onboarding rooms, on either the presenter or audience side. Because we all went into this creating things from whole cloth, I'm sure there are lots of lessons learned. If you ran a room, please post the project, what you did in the room, what you think worked, what you would have done differently. If you attended a room you didn't run, please provide feedback about which one it was, and what you thought worked / didn't work from the other side of the table. Hopefully we can consolidate some of that feedback for best practices going forward. -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] [nova] Boston Forum session recap - searchlight integration
Support sort and pagination together will be the biggest challenge: it's up to how many cells will be involved in the query, 3,5 may be OK, you can search each cells, and cached data. But how about 20, 50 or more, and how many data will be cached? More over, during the query there are instances operation( create, delete) in parallel during the pagination/sort query, there is situation some cells may not provide response in time, or network connection broken, etc, many abnormal cases may happen. How to deal with some of cells abnormal query response is also one great factor to be considered. It's not good idea to support pagination and sort at the same time (may not provide exactly the result end user want) if searchlight should not be integrated. In fact in Tricircle, when query ports from neutron where tricircle central plugin is installed, the tricircle central plugin do the similar cross local Neutron ports query, and not support pagination/sort together. Best Regards Chaoyi Huang (joehuang) From: Matt Riedemann [mriede...@gmail.com] Sent: 19 May 2017 5:21 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova] Boston Forum session recap - searchlight integration Hi everyone, After previous summits where we had vertical tracks for Nova sessions I would provide a recap for each session. The Forum in Boston was a bit different, so here I'm only attempting to recap the Forum sessions that I ran. Dan Smith led a session on Cells v2, John Garbutt led several sessions on the VM and Baremetal platform concept, and Sean Dague led sessions on hierarchical quotas and API microversions, and I'm going to leave recaps for those sessions to them. I'll do these one at a time in separate emails. Using Searchlight to list instances across cells in nova-api The etherpad for this session is here [1]. The goal for this session was to explain the problem and proposed plan from the spec [2] to the operators in the room and get feedback. Polling the room we found that not many people are deploying Searchlight but most everyone was using ElasticSearch. An immediate concern that came up was the complexity involved with integrating Searchlight, especially around issues with latency for state changes and questioning how this does not redo the top-level cells v1 sync issue. It admittedly does to an extent, but we don't have all of the weird side code paths with cells v1 and it should be self-healing. Kris Lindgren noted that the instance.usage.exists periodic notification from the computes hammers their notification bus; we suggested he report a bug so we can fix that. It was also noted that if data is corrupted in ElasticSearch or is out of sync, you could re-sync that from nova to searchlight, however, searchlight syncs up with nova via the compute REST API, which if the compute REST API is using searchlight in the backend, you end up getting into an infinite loop of broken. This could probably be fixed with bypass query options in the compute API, but it's not a fun problem. It was also suggested that we store a minimal set of data about instances in the top-level nova API database's instance_mappings table, where all we have today is the uuid. Anything that is set in the API would probably be OK for this, but operators in the room noted that they frequently need to filter instances by an IP, which is set in the compute. So this option turns into a slippery slope, and is potentially not inter-operable across clouds. Matt Booth is also skeptical that we can't have a multi-cell query perform well, and he's proposed a POC here [3]. If that works out, then it defeats the main purpose for using Searchlight for listing instances in the compute API. Since sorting instances across cells is the main issue, it was also suggested that we allow a config option to disable sorting in the API. It was stated this would be without a microversion, and filtering/paging would still be supported. I'm personally skeptical about how this could be consider inter-operable or discoverable for API users, and would need more thought and input from users like Monty Taylor and Clark Boylan. Next steps are going to be fleshing out Matt Booth's POC for efficiently listing instances across cells. I think we can still continue working on the versioned notifications changes we're making for searchlight as those are useful on their own. And we should still work on enabling searchlight in the nova-next CI job so we can get an idea for how the versioned notifications are working by a consumer. However, any major development for actually integrating searchlight into Nova is probably on hold at the moment until we know how Matt's POC works. [1] https://etherpad.openstack.org/p/BOS-forum-using-searchlight-to-list-instances [2] https://specs
[openstack-dev] [tricircle]cancellation of weekly meeting(May 17) due to bug smash
Hello, team, The bug smash will be held May.17~19, the weekly meeting of May. 17 will be cancelled. Best Regards Chaoyi Huang (joehuang) __ 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] [neutron] multi-site forum discussion
Hello, Neutron cells aware is not equal to multi-site. There are lots of multi-site deployment options, not limited to nova-cells, whether to use Neutron-cells/Nova-cells in multi-site deployments, it's up to cloud operator's choice. For the bug[3], it's reasonable to make neutron support cells, but it doesn't implicate that multi-site should mandatory adopt neutron-cells. [3] https://bugs.launchpad.net/neutron/+bug/1690425 Best Regards Chaoyi Huang (joehuang) From: Armando M. [arma...@gmail.com] Sent: 13 May 2017 3:13 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] multi-site forum discussion On 12 May 2017 at 11:47, Morales, Victor mailto:victor.mora...@intel.com>> wrote: Armando, I noticed that Tricircle is mentioned there. Shouldn’t be better to extend its current functionality or what are the things that are missing there? Tricircle aims at coordinating independent neutron systems that exist in separated openstack deployments. Making Neutron cell-aware will work in the context of the same openstack deployment. Regards, Victor Morales From: "Armando M." mailto:arma...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, May 12, 2017 at 1:06 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [neutron] multi-site forum discussion Hi folks, At the summit we had a discussion on how to deploy a single neutron system across multiple geographical sites [1]. You can find notes of the discussion on [2]. One key requirement that came from the discussion was to make Neutron more Nova cells friendly. I filed an RFE bug [3] so that we can move this forward on Lauchpad. Please, do provide feedback in case I omitted some other key takeaway. Thanks, Armando [1] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18757/neutron-multi-site [2] https://etherpad.openstack.org/p/pike-neutron-multi-site [3] https://bugs.launchpad.net/neutron/+bug/1690425 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] [Openstack-operators]project Tricricle onboarding in Boston
Hello, If you are interested in learning more about Tricircle - networking automation across OpenStack clouds, you are welcome to the on-boarding session in Boston, Tuesday, May 9, 4:40pm-5:25pm Level One - MR 101. Please feel free to add topics in the etherpad, https://etherpad.openstack.org/p/BOS-forum-tricircle-onboarding , and use +1 to prompt your preferred topics. Best Regards Chaoyi Huang (joehuang) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack-operators] try and feedback on tenant overlay networking across multiple OpenStack clouds
Hello, Tricircle is a project to provide tenant level L2/L3 overlay networking automation across Neutron in multi-region OpenStack deployments. The cross OpenStack networking topology can be composed mainly from four concepts: Local Network - Local Network is a network which can only reside in one OpenStack cloud. - Network type could be VLAN, VxLAN, Flat. Local Router - Local Router is a logical router which can only reside in one OpenStack cloud. Cross OpenStack L2 Network - Cross OpenStack L2 Network is a network which can be streched into more than one OpenStack cloud. - Also called cross Neutron L2 network, or cross pod L2 network. - Network type could be VLAN, VxLAN, Flat. Non-Local Router - Non-Local Router will be able to reside in more than one OpenStack cloud, and internally inter-connected with bridge network. - Bridge network used internally for non-local router is a special cross OpenStack L2 network. - Local networks or cross OpenStack L2 networks can be attached to local router or non-local routers if the network can be presented to the region where the router can reside. With these four concepts, various typologies could be composed: - Instances in different OpenStack clouds can be attached to a cross OpenStack L2 network directly, so that they can communicate with each other no matter in which OpenStack cloud. - Local router can be set gateway with external networks to support north-south traffic handled locally. - Non-local router can work only for cross OpenStack east-west networking purpose if no external network is set to the router. - Non-local router can serve as the centralized north-south traffic gateway if external network is attached to the router, and support east-west traffic at the same time. Several typical cross OpenStack networking topology have been supported in Tricircle Pike1.5, just released on May.2: 1. Multiple North-South gateways with East-West Networking enabled - https://docs.openstack.org/developer/tricircle/networking-guide-multiple-ns-with-ew-enabled.html 2. North South Networking via Single External Network - https://docs.openstack.org/developer/tricircle/networking-guide-single-external-network.html 3. North South Networking via Multiple External Networks - https://docs.openstack.org/developer/tricircle/networking-guide-multiple-external-networks.html 4. North South Networking via Direct Provider Networks - https://docs.openstack.org/developer/tricircle/networking-guide-direct-provider-networks.html Now you can experience these networking automation capabilities through devstack, the installation guide is also available: - https://docs.openstack.org/developer/tricircle/installation-guide.html#multi-pod-installation-with-devstack If you want to learn more about the networking automation provided by Tricircle, the wiki page of Tricircle is an entrance to the project: - https://wiki.openstack.org/wiki/Tricircle Two sessions in OpenStack Boston Summit are also good start point. 1. When One Cloud is Not Enough: An Overview of Sites, Regions... https://www.openstack.org/summit/boston-2017/summit-schedule/events/18076/ 2. Tricircle - Project Onboarding. https://www.openstack.org/summit/boston-2017/summit-schedule/events/18701 And in OPNFV Beijing Summit in June, one PoC demo will be done to show how Tricircle networking capability can help VNF(telecom application) to achieve high availability across OpenStack clouds(or multi-sites): https://docs.google.com/presentation/d/16Qfm3D1yhrW31ZEVRYea8mcyKI06fQ3a6Okk4VhFGkQ/ . Feel free to ping us in mail-list or IRC if you have any topic to be discussed. Very keen to get your feedback on the networking requirements and expectation, and discuss in more detail f2f if needed. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]weekly meeting of May.3
Hello, team, Please note the new weekly meeting time is UTC 01:00, Wednesday. Agenda of May.3 weekly meeting: 1. feature implementation review 2. Pike-1.5 (May.2) review 3. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 01:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]poll for new weekly meeting time slot
Hello, According to the poll, most of contributors prefer the option "Wed UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM". I'll submit a patch to update the weekly meeting time slot. Best Regards Chaoyi Huang (joehuang) From: joehuang Sent: 24 April 2017 16:12 To: openstack-dev Subject: [openstack-dev][tricircle]poll for new weekly meeting time slot Hello, We's like to reschedule our weekly time according to our discussion, there are four options after some offline communication: Wed UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM Wed UTC 13:00, Beijing 9:00 PM, PDT 6:00 AM Thu UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM Fri UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM Please vote in the doodle poll: http://doodle.com/poll/ypd2xpqppzaqek5u thanks a lot. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]weekly meeting APR.26
Hello, According to the plan, we'd like to release pike-1.5 on May.2, the priorities of these patches are as follows: MUST to have(Should be merged before the end of this week): * Release note and doc for multi-gw NS networking, https://review.openstack.org/#/c/458786/ * Add guide for multiple north-south gateways with east-west enabled, https://review.openstack.org/#/c/458315/ NICE to have(To be merged as far as possible): * Include tricircleclient installation, https://review.openstack.org/#/c/437719/ * Implement asynchronous job Admin API, https://review.openstack.org/#/c/446837/ * Documentation on asynchronous job management, https://review.openstack.org/#/c/456652/ * Add VLAN aware VMs support, https://review.openstack.org/#/c/444579/ * Basic devstack gate run script: https://review.openstack.org/#/c/455615/ * Release notes for asynchronous job management API, https://review.openstack.org/#/c/459668/ * * Networking Qos service spec, https://review.openstack.org/#/c/417947/ For other patches, work on best effort. If no urgent topic to be discussed before the weekly meeting, the APR.26 weekly meeting is to be skipped. And also please continue to vote in the new weekly meeting time slot polling: http://doodle.com/poll/ypd2xpqppzaqek5u Best Regards Chaoyi Huang (joehuang) __ 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] project on-board schedule
Thank you very much, Hongbin and Kendall. Best Regards Chaoyi Huang (joehuang) From: Kendall Nelson [kennelso...@gmail.com] Sent: 26 April 2017 11:19 To: joehuang; OpenStack Development Mailing List (not for usage questions); Hongbin Lu Subject: Re: [openstack-dev] project on-board schedule Yes, I should be able to make that happen :) - Kendall On Tue, Apr 25, 2017, 10:03 PM joehuang mailto:joehu...@huawei.com>> wrote: Hello, Kendall, Thank you very much for the slot you provided, but consider that it's launch time, I am afraid that audience need to have launch too. I just discussed with Hongbin, the PTL of Zun, he said it's OK to exchange the project on-boarding time slot between Zun[1] and Tricircle[2]. After exchange, Tricircle will share with Sahara and use the first half (45 minutes) just like Zun in this time slot. And Zun's on-boarding session will be moved to Monday 2:00pm~3:30pm. Is this exchange is feasible? [1] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18701/zunsahara-project-onboarding [2] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding Best Regards Chaoyi Huang (joehuang) From: Kendall Nelson [kennelso...@gmail.com<mailto:kennelso...@gmail.com>] Sent: 26 April 2017 4:07 To: OpenStack Development Mailing List (not for usage questions); joehuang Subject: Re: [openstack-dev] project on-board schedule Hello Joe, I can offer TriCircle a lunch slot on Wednesday from 12:30-1:50? -Kendall On Tue, Apr 25, 2017 at 4:08 AM joehuang mailto:joehu...@huawei.com>> wrote: Hi, Thank you Tom, I found that the on-boarding session of Tricircle [1] is overlapping with my talk{2]: [1] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding [2] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18076/when-one-cloud-is-not-enough-an-overview-of-sites-regions-edges-distributed-clouds-and-more Is there any other project can help us to exchange the on-boarding session? Thanks a lot, I just find the issue. Best Regards Chaoyi Huang (joehuang) From: Tom Fifield [t...@openstack.org<mailto:t...@openstack.org>] Sent: 25 April 2017 16:50 To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] project on-board schedule On 25/04/17 16:35, joehuang wrote: > Hello, > > Where can I find the project on-board schedule in OpenStack Boston > summit? I haven't found it yet, and maybe I missed some mail. Thanks a lot. It's listed on the main summit schedule, under the Forum :) Here's a direct link to the Forum category: https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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] [tricircle] mascot for the Tricircle
Hello, team, Great, if no other comment, then the following cute Panda is Tricircle's mascot. Thank you all! [X] Best Regards Chaoyi Huang (joehuang) From: Yipei Niu [newy...@gmail.com] Sent: 25 April 2017 9:25 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tricircle] mascot for the Tricircle +1. Best regards, Yipei __ 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] project on-board schedule
Hello, Kendall, Thank you very much for the slot you provided, but consider that it's launch time, I am afraid that audience need to have launch too. I just discussed with Hongbin, the PTL of Zun, he said it's OK to exchange the project on-boarding time slot between Zun[1] and Tricircle[2]. After exchange, Tricircle will share with Sahara and use the first half (45 minutes) just like Zun in this time slot. And Zun's on-boarding session will be moved to Monday 2:00pm~3:30pm. Is this exchange is feasible? [1] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18701/zunsahara-project-onboarding [2] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding Best Regards Chaoyi Huang (joehuang) From: Kendall Nelson [kennelso...@gmail.com] Sent: 26 April 2017 4:07 To: OpenStack Development Mailing List (not for usage questions); joehuang Subject: Re: [openstack-dev] project on-board schedule Hello Joe, I can offer TriCircle a lunch slot on Wednesday from 12:30-1:50? -Kendall On Tue, Apr 25, 2017 at 4:08 AM joehuang mailto:joehu...@huawei.com>> wrote: Hi, Thank you Tom, I found that the on-boarding session of Tricircle [1] is overlapping with my talk{2]: [1] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding [2] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18076/when-one-cloud-is-not-enough-an-overview-of-sites-regions-edges-distributed-clouds-and-more Is there any other project can help us to exchange the on-boarding session? Thanks a lot, I just find the issue. Best Regards Chaoyi Huang (joehuang) From: Tom Fifield [t...@openstack.org<mailto:t...@openstack.org>] Sent: 25 April 2017 16:50 To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] project on-board schedule On 25/04/17 16:35, joehuang wrote: > Hello, > > Where can I find the project on-board schedule in OpenStack Boston > summit? I haven't found it yet, and maybe I missed some mail. Thanks a lot. It's listed on the main summit schedule, under the Forum :) Here's a direct link to the Forum category: https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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] project on-board schedule
Hi, Thank you Tom, I found that the on-boarding session of Tricircle [1] is overlapping with my talk{2]: [1] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding [2] https://www.openstack.org/summit/boston-2017/summit-schedule/events/18076/when-one-cloud-is-not-enough-an-overview-of-sites-regions-edges-distributed-clouds-and-more Is there any other project can help us to exchange the on-boarding session? Thanks a lot, I just find the issue. Best Regards Chaoyi Huang (joehuang) From: Tom Fifield [t...@openstack.org] Sent: 25 April 2017 16:50 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] project on-board schedule On 25/04/17 16:35, joehuang wrote: > Hello, > > Where can I find the project on-board schedule in OpenStack Boston > summit? I haven't found it yet, and maybe I missed some mail. Thanks a lot. It's listed on the main summit schedule, under the Forum :) Here's a direct link to the Forum category: https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146 __ 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] project on-board schedule
Hello, Where can I find the project on-board schedule in OpenStack Boston summit? I haven't found it yet, and maybe I missed some mail. Thanks a lot. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]poll for new weekly meeting time slot
Hello, We's like to reschedule our weekly time according to our discussion, there are four options after some offline communication: Wed UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM Wed UTC 13:00, Beijing 9:00 PM, PDT 6:00 AM Thu UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM Fri UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM Please vote in the doodle poll: http://doodle.com/poll/ypd2xpqppzaqek5u thanks a lot. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]mascot for the Tricircle project
Hello, team, What about the mascot of Tricircle project? Your comments are welcome. Best Regards Chaoyi Huang(joehuang) From: Heidi Joy Tretheway [heidi...@openstack.org] Sent: 22 April 2017 6:15 To: joehuang Subject: Re: Question about the Tricircle mascot Hi Joe, Following up on your team’s mascot request, our illustrators came back with a beautiful piece. Would you please let me know what your team thinks? [cid:37DEE8D2-1153-4E9B-B901-C8631599ECEB] __ 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] [tricircle]weekly meeting of Apr.19
Hello, team, Agenda of Apr.19 weekly meeting: 1. feature implementation review 2. weekly meeting time 3. Pike-1.5 (May.2) preparation 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 14:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tc][elections]questions about one platform vision
Interesting to know the idea considering OpenStack as group of constellations. Does it mean even Nova/Cinder/Neutron are not necessary to be tied together in some user cases? Seems that "one platform" has not been got consensus yet. But the marketing material of OpenStack is claiming "one platform" [1][2] [1] https://www.openstack.org/assets/marketing/OpenStack-101-Modular-Deck-1.pptx [2] OpenStack 101, https://www.openstack.org/marketing/#tab=collateral Best Regards Chaoyi Huang (joehuang) From: John Garbutt [j...@johngarbutt.com] Sent: 12 April 2017 18:51 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tc][elections]questions about one platform vision On 12 April 2017 at 03:54, joehuang wrote: > What's the one platform will be in your own words? What's your proposal and > your focus to help one platform vision being achieved? The more I think about this, the less I like the phrase "one platform". I like to think of OpenStack as group of constellations. Those constellations are groups of projects that are built to be used together around a shared set of use cases and users. Note that many (all?) of those constellations involve open source projects that were born and live outside of OpenStack. I am trying to kick start the "VM and baremetal" working group to get feedback on a specific constellation as a group of projects. Here I am thinking about running Nova, Cinder, Neutron, Keystone, etc to give you (in some sense) a Software Defined Data Center. Many applications and services need to consume and integrate with that platform, like Heat, Trove and Magnum, to can get access to the compute, networking and storage they need to execute their workloads, such as containers. Its like the next generation of consolidation to get to the next level of utilization/efficiency. If you look at this constellation the database and message queue are important non-OpenStack components of the constellation. Maybe this is a false constellation, and there is a different set of things that people use together. Thats some of the feedback I hope we get at the forum. The work ttx mentions is important. I hope the project maps will help communicate how users can meet their needs by running various combinations of OpenStack and non-OpenStack projects together. To be clear, I am not claiming to have the answers here, this is just my current thinking. I look forward to all the debate and discussions around this topic, and all the interesting things I will learn about along that journey, things that will likely make me change my mind. Thanks, johnthetubaguy __ 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] [tricircle]weekly meeting of Apr.12
Hello, team, Agenda of Apr.12 weekly meeting: 1. feature implementation review 2. Pike-1.5 (May.2) preparation 3. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 14:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tc][elections]questions about one platform vision
Hello, I heard the one platform vision in OpenStack now and then: One platform for virtual machines, containers and bare metal. I also learned that there are some groups working on making Kubernets being able to manage virtual machines. Except running containers in virtual machine, there is also the need for running containers in bare metal. There are several projects connecting OpenStack to container world: Zun, Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, ... Can all these efforts lead us to one platform vision? We have to think over the question. What's the one platform will be in your own words? What's your proposal and your focus to help one platform vision being achieved? Best Regards Chaoyi Huang (joehuang) __ 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] [tc] [elections] Available time and top priority
> When there are topics with a lot of people clamoring to talk, Thierry usually > lets people speak in order of "raising > their hand". This reduces cross-talk and lets everyone get their turn to > state what's on their mind. +1, impressive for the "raising their hand" in TC weekly IRC meeting :), especially during Tricircle's big-tent application discussion. Best Regards Chaoyi Huang (joehuang) From: Ed Leafe [e...@leafe.com] Sent: 11 April 2017 5:40 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tc] [elections] Available time and top priority On Apr 10, 2017, at 3:40 PM, Matt Riedemann wrote: > > I don't attend many TC meetings, it's usually on accident, but yeah, when I > do I always note the flurry of cross-talk chatter that just drowns everything > out. I feel like there are usually at least 3 parallel conversations going on > during a TC meeting and it's pretty frustrating to follow along, or get a > thought in the mix. That has to be much worse for a non-native English > speaker. > > So yeah, slow down folks. :) When there are topics with a lot of people clamoring to talk, Thierry usually lets people speak in order of "raising their hand". This reduces cross-talk and lets everyone get their turn to state what's on their mind. Normally, though, it is a bit of an acquired skill to be able to follow along. -- Ed Leafe __ 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] [tricircle]weekly meeting of Apr.5
Hello, team, Agenda of Apr.5 weekly meeting: 1. feature implementation review 2. Pike-2 planning 3. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 14:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]weekly meeting of Mar. 29
Hello, team, Agenda of Mar.29 weekly meeting: 1. Pike-1 prioritized patches 2. Requirements from VNF high availability across OpenStack (which will be a demo in OPNFV Beijing Summit) 3. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 14:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]pike-1 patch prioritization
Hello, As we discussed in last weekly meeting, pike-1 is expected to be tagged by the end of this month, Mar.31. These patches are must to have in pike-1: 1. Add multi-region configuration in gate_hook.sh<https://review.openstack.org/438382>: https://review.openstack.org/#/c/438382/ 2. Cross-pod VxLAN network spec<https://review.openstack.org/429155>: https://review.openstack.org/#/c/429155/ 3. Shared VxLAN (Part4: bridge network l3)<https://review.openstack.org/425131> : https://review.openstack.org/#/c/425131/ 4. Shared VxLAN (Part5: bulk create shadow port)<https://review.openstack.org/444112>: https://review.openstack.org/#/c/444112/ 5. Update doc and add release note for vxlan<https://review.openstack.org/448524>: https://review.openstack.org/#/c/448524/ 6. Support WSGI deployment for Tricircle Admin API(part1)<https://review.openstack.org/440175>: https://review.openstack.org/#/c/440175/ These two patches are nice to have in pike-1 1. Networking Qos service spec<https://review.openstack.org/417947>: https://review.openstack.org/#/c/417947/ 2. Update networking-guide-single-external-network<https://review.openstack.org/446883>: https://review.openstack.org/#/c/446883/ Other patches will be merged in best effort. That is, once it was considered ready to merge, it can be merged, regardless it's in pike-1 or pike-2. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]weekly meeting of Mar. 22
Hello, team, Agenda of Mar.22 weekly meeting: 1. Pike-1 patches review 2. Pike-1 release 3. Demo and talk of VNF high availability across OpenStack with Tricircle in OPNFV Beijing summit 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 14:00. Best Regards Chaoyi Huang (joehuang) __ 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][ptl] Action required ! - Please submit Boston Forum sessions before April 2nd
Hello, Should we submit a session for the on-boarding slot which is being arranged by Kendall " first come first served process" ? Does this mean that the on-boarding slot allocation need another round of selection, not the " first come first served process" ? Best Regards Chaoyi Huang (joehuang) From: Emilien Macchi [emil...@redhat.com] Sent: 22 March 2017 0:40 To: OpenStack Development Mailing List Subject: [openstack-dev] [all][ptl] Action required ! - Please submit Boston Forum sessions before April 2nd Sorry for duplicating the original e-mail from User Committee, but we want to make sure all projects are aware about the deadline. http://lists.openstack.org/pipermail/user-committee/2017-March/001856.html PTLs (and everyone), please make sure topics are submitted before April 2nd. Please let us know any question, Thanks! -- Emilien Macchi __ 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] [ptls] Project On-Boarding Rooms
Hello, Kendall, Tricircle need a slot too, if it's not too late :). Thanks providing the project on-boarding opportunity. Best Regards Chaoyi Huang (joehuang) From: Kendall Nelson [kennelso...@gmail.com] Sent: 16 March 2017 2:20 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [ptls] Project On-Boarding Rooms Hello All! As you may have seen in a previous thread [1] the Forum will offer project on-boarding rooms! This idea is that these rooms will provide a place for new contributors to a given project to find out more about the project, people, and code base. The slots will be spread out throughout the whole Summit and will be 90 min long. We have a very limited slots available for interested projects so it will be a first come first served process. Let me know if you are interested and I will reserve a slot for you if there are spots left. - Kendall Nelson (diablo_rojo) [1] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html __ 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] [tricircle]weekly meeting of Mar. 15
Hello, team, New weekly meeting time slot is UTC 14:00~UTC 15:00 Agenda of Mar.15 weekly meeting: 1. Test coverage requirement : https://review.openstack.org/#/c/444394/ 2. Demo of VNF high availability across OpenStack with Tricircle in OPNFV Beijing summit 3. Pike-1 prioritized patches progress review : https://etherpad.openstack.org/p/tricircle-pike-design-topics 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 14:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]weekly meeting of Mar. 8
Hello, team, Attention please, the new weekly meeting time slot is UTC 14:00~UTC 15:00 Agenda of Mar.8 weekly meeting: 1. Pike-1 feature priority discussion 2. Pike features development 3. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 14:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]reschedule the weekly meeting
Hello, The patch was merged, the weekly meeting will be held on UTC 1400 ~ UTC 1500 every Wednesday from this week. Best Regards Chaoyi Huang(joehuang) 发件人:黄朝意 收件人:openstack-dev,Morales, Victor,sindhu.dev...@intel.com,prince.a.owusu.boat...@intel.com 时间:2017-03-06 10:07:14 主题:RE: [openstack-dev][tricircle]reschedule the weekly meeting Hello, According to the poll[1], the weekly meeting will be rescheduled to UTC 1400 ~ UTC 1500 every Wednesday, once the patch[2] was merged, we can start the weekly meeting at new time slot. [1]poll of weekly meeting time: http://doodle.com/poll/hz436r6wm99h4eka#table [2]new weekly meeting time patch: https://review.openstack.org/#/c/441727/ Best Regards Chaoyi Huang (joehuang) From: joehuang Sent: 01 March 2017 11:59 To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; prince.a.owusu.boat...@intel.com Subject: RE: [openstack-dev][tricircle]reschedule the weekly meeting Hello, team, According to the discussion in the IRC, we'd like to move the weekly meeting from UTC1300 to UTC1400, there are several options for this time slot, please vote before next Monday, then I'll submit a patch to occupy the new time slot and release the old time slot. Poll link: http://doodle.com/poll/hz436r6wm99h4eka Note: before the new weekly meeting time is settled, we have to have weekly meeting at old time slot. Best Regards Chaoyi Huang (joehuang) ____ From: joehuang Sent: 27 February 2017 21:48 To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; prince.a.owusu.boat...@intel.com Subject: [openstack-dev][tricircle]reschedule the weekly meeting Hello, Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 every Wednesday, it's not convenient for contributors from USA. The available time slots could be found at https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0 Other contributors are mostly from East Asia, the time zone is around UTC+8/UTC+9. Please propose some your preferred time slots, and then let's have a poll for the new weekly meeting time. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]reschedule the weekly meeting
Hello, According to the poll[1], the weekly meeting will be rescheduled to UTC 1400 ~ UTC 1500 every Wednesday, once the patch[2] was merged, we can start the weekly meeting at new time slot. [1]poll of weekly meeting time: http://doodle.com/poll/hz436r6wm99h4eka#table [2]new weekly meeting time patch: https://review.openstack.org/#/c/441727/ Best Regards Chaoyi Huang (joehuang) From: joehuang Sent: 01 March 2017 11:59 To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; prince.a.owusu.boat...@intel.com Subject: RE: [openstack-dev][tricircle]reschedule the weekly meeting Hello, team, According to the discussion in the IRC, we'd like to move the weekly meeting from UTC1300 to UTC1400, there are several options for this time slot, please vote before next Monday, then I'll submit a patch to occupy the new time slot and release the old time slot. Poll link: http://doodle.com/poll/hz436r6wm99h4eka Note: before the new weekly meeting time is settled, we have to have weekly meeting at old time slot. Best Regards Chaoyi Huang (joehuang) ____ From: joehuang Sent: 27 February 2017 21:48 To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; prince.a.owusu.boat...@intel.com Subject: [openstack-dev][tricircle]reschedule the weekly meeting Hello, Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 every Wednesday, it's not convenient for contributors from USA. The available time slots could be found at https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0 Other contributors are mostly from East Asia, the time zone is around UTC+8/UTC+9. Please propose some your preferred time slots, and then let's have a poll for the new weekly meeting time. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]Nominating Victor Morales as Tricircle Core
Thank you all for your voting. Victor, you are now included in the core team. Best Regards Chaoyi Huang (joehuang) From: Yipei Niu [newy...@gmail.com] Sent: 01 March 2017 15:06 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core +1. From: joehuang Sent: 01 March 2017 11:44 To: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core +1 from my vote. Best Regards Chaoyi Huang (joehuang) From: Vega Cai [luckyveg...@gmail.com] Sent: 01 March 2017 11:42 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core +1 Zhiyuan On Wed, 1 Mar 2017 at 11:41 Devale, Sindhu mailto:sindhu.dev...@intel.com>> wrote: +1 Sindhu From: joehuang mailto:joehu...@huawei.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, February 28, 2017 at 8:38 PM To: openstack-dev mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core Hi Team, Victor Morales has made many review contributions[1] to Trircircle since the Ocata cycle, and he also created the python-tricircleclient sub-project[2]. I would like to nominate him to be Tricircle core reviewer. I really think his experience will help us substantially improve Trircircle. It's now time to vote :) [1] http://stackalytics.com/report/contribution/tricircle/120 [2] https://git.openstack.org/cgit/openstack/python-tricircleclient/ Best Regards Chaoyi Huang (joehuang) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- BR Zhiyuan __ 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] [tricircle]weekly meeting of Mar. 1
Hello, team, Before the new weekly meeting is settled, we'll still hold the weekly meeting in regular time slot: UTC 13:00~UTC 14:00 Agenda of Mar. 1 weekly meeting: 1. Pike release schedule: https://releases.openstack.org/pike/schedule.html 2. Launch pad blueprint registration and spec 3. Pike features development 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 13:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]reschedule the weekly meeting
Hello, team, According to the discussion in the IRC, we'd like to move the weekly meeting from UTC1300 to UTC1400, there are several options for this time slot, please vote before next Monday, then I'll submit a patch to occupy the new time slot and release the old time slot. Poll link: http://doodle.com/poll/hz436r6wm99h4eka Note: before the new weekly meeting time is settled, we have to have weekly meeting at old time slot. Best Regards Chaoyi Huang (joehuang) ____ From: joehuang Sent: 27 February 2017 21:48 To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; prince.a.owusu.boat...@intel.com Subject: [openstack-dev][tricircle]reschedule the weekly meeting Hello, Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 every Wednesday, it's not convenient for contributors from USA. The available time slots could be found at https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0 Other contributors are mostly from East Asia, the time zone is around UTC+8/UTC+9. Please propose some your preferred time slots, and then let's have a poll for the new weekly meeting time. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]Nominating Victor Morales as Tricircle Core
+1 from my vote. Best Regards Chaoyi Huang (joehuang) From: Vega Cai [luckyveg...@gmail.com] Sent: 01 March 2017 11:42 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core +1 Zhiyuan On Wed, 1 Mar 2017 at 11:41 Devale, Sindhu mailto:sindhu.dev...@intel.com>> wrote: +1 Sindhu From: joehuang mailto:joehu...@huawei.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, February 28, 2017 at 8:38 PM To: openstack-dev mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core Hi Team, Victor Morales has made many review contributions[1] to Trircircle since the Ocata cycle, and he also created the python-tricircleclient sub-project[2]. I would like to nominate him to be Tricircle core reviewer. I really think his experience will help us substantially improve Trircircle. It's now time to vote :) [1] http://stackalytics.com/report/contribution/tricircle/120 [2] https://git.openstack.org/cgit/openstack/python-tricircleclient/ Best Regards Chaoyi Huang (joehuang) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- BR Zhiyuan __ 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] [tricircle]Nominating Victor Morales as Tricircle Core
Hi Team, Victor Morales has made many review contributions[1] to Trircircle since the Ocata cycle, and he also created the python-tricircleclient sub-project[2]. I would like to nominate him to be Tricircle core reviewer. I really think his experience will help us substantially improve Trircircle. It's now time to vote :) [1] http://stackalytics.com/report/contribution/tricircle/120 [2] https://git.openstack.org/cgit/openstack/python-tricircleclient/ Best Regards Chaoyi Huang (joehuang) __ 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] Zuul v3 - What's Coming: What to expect with the Zuul v3 Rollout
So cool! Look forward to multi-node jobs as first class Best Regards Chaoyi Huang (joehuang) From: Monty Taylor [mord...@inaugust.com] Sent: 01 March 2017 7:26 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] Zuul v3 - What's Coming: What to expect with the Zuul v3 Rollout Hi everybody! This content can also be found at http://inaugust.com/posts/whats-coming-zuulv3.html - but I've pasted it in here directly because I know that some folks don't like clicking links. tl;dr - At last week's OpenStack PTG, the OpenStack Infra team ran the first Zuul v3 job, so it's time to start getting everybody ready for what's coming **Don't Panic!** Awesome changes are coming, but you are NOT on the hook for rewriting all of your project's gate jobs or anything crazy like that. Now grab a seat by the fire, pour yourself a drink while I spin a yarn about days gone by and days yet to come. First, some background The OpenStack Infra team has been hard at work for quite a while on a new version of Zuul (where by 'quite some time' I mean that Jim Blair and I had our first Zuul v3 design whiteboarding session in 2014). As you might be able to guess given the amount of time, there are some big things coming that will have a real and visible impact on the OpenStack community and beyond. Since we have a running Zuul v3 now [1], it seemed like the time to start getting folks up to speed on what to expect. There is other deep-dive information on architecture and rationale if you're interested[2], but for now we'll focus on what's relevant for end users. We're also going to start sending out a bi-weekly "Status of Zuul v3" email to the openstack-dev@lists.openstack.org mailing list ... so stay tuned! **Important Note** This post includes some code snippets - but v3 is still a work in progress. We know of at least one breaking change that is coming to the config format, so please treat this not as a tutorial, but as a conceptual overview. Syntax is subject to change. The Big Ticket Items While there are a bunch of changes behind the scenes, there are a reasonably tractable number of user-facing differences. * Self-testing In-Repo Job Config * Ansible Job Content * First-class Multi-node Jobs * Improved Job Reuse * Support for non-OpenStack Code and Node Systems * and Much, Much More Self-testing In-Repo Job Config This is probably the biggest deal. There are a lot of OpenStack Devs (around 2k in Ocata) and a lot of repositories (1689) There a lot fewer folks on the project-config-core team who are the ones who review all of the job config changes (please everyone thank Andreas Jaeger next time you see him). That's not awesome. Self-testing in-repo job config is awesome. Many systems out there these days have an in-repo job config system. Travis CI has had it since day one, and Jenkins has recently added support for a Jenkinsfile inside of git repos. With Zuul v3, we'll have it too. Once we roll out v3 to everyone, as a supplement to jobs defined in our central config repositories, each project will be able to add a zuul.yaml file to their own repo: - job: name: my_awesome_job nodes: - name: controller label: centos-7 - project: name: openstack/awesome_project check: jobs: - my_awesome_job It's a small file, but there is a lot going on, so let's unpack it. First we define a job to run. It's named my_awesome_job and it needs one node. That node will be named controller and will be based on the centos-7 base node in nodepool. In the next section, we say that we want to run that job in the check pipeline, which in OpenStack is defined as the jobs that run when patchsets are proposed. And it's also self-testing! Everyone knows the fun game of writing a patch to the test jobs, getting it approved, then hoping it works once it starts running. With Zuul v3 in-repo jobs, if there is a change to job definitions in a proposed patch, that patch will be tested with those changes applied. And since it's Zuul, Depends-On footers are honored as well - so iteration on getting a test job right becomes just like iterating on any other patch or sequence of patches. Ansible Job Content The job my_awesome_job isn't very useful if it doesn't define any content. That's done in the repo as well, in playbooks/my_awesome_job.yaml: - hosts: controller tasks: - name: Run make tests shell: make distcheck As previously mentioned, the job content is now defined in Ansible rather than using our Jenkins Job Builder tool. This playbook is going to run a tasks on a host called controller which you may remember we requested in the job definition. On that host, it will run make distcheck. Pretty much anything you can do in Ansible, you can do in a Zuul job now, and the pla
[openstack-dev] [tricircle]reschedule the weekly meeting
Hello, Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 every Wednesday, it's not convenient for contributors from USA. The available time slots could be found at https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0 Other contributors are mostly from East Asia, the time zone is around UTC+8/UTC+9. Please propose some your preferred time slots, and then let's have a poll for the new weekly meeting time. Best Regards Chaoyi Huang (joehuang) __ 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]PKI token VS Fernet token
Thank you all very much, the less data to be replicated, the better. Best Regards Chaoyi Huang (joehuang) From: Clint Byrum [cl...@fewbar.com] Sent: 26 February 2017 12:06 To: openstack-dev Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token Excerpts from Lance Bragstad's message of 2017-02-25 13:07:58 -0600: > Since both token formats rebuild the authorization context at validation > time, we can remove some revocation events that are no longer needed. This > means we won't be storing as many revocation events on role removal from > domains and projects. Instead we will only rely on the revocation API to > invalidate tokens for cases like specific token revocation or password > changes (the new design of validation does role assignment enforcement for > us automatically). This should reduce the amount of data being replicated > due to massive amounts of revocation events. > I didn't know that the work to make role removal non-event based was even started much less done. Cool. > We do still have some more work to do on this front, but I can dig into it > and see what's left. > Indeed, the less revocation events, the better the Fernet story is for scalability. __ 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]PKI token VS Fernet token
Hello, Matt, Thank you for your reply, just as what you mentioned, for the slow changed data, aync. replication should work. My concerns is that the impact of replication delay, for example (though it's quite low chance to happen): 1) Add new user/group/role in RegionOne, before the new user/group/role are replicated to RegionTwo, the new user begin to access RegionTwo service, then because the data has not arrived yet, the user's request to RegionTwo may be rejected for the token vaildation failed in local KeyStone. 2)In token revoke case. If we remove the user'role in RegionOne, the token in RegionOne will be invalid immediately, but before the remove operation replicated to the RegionTwo, the user can still use the token to access the services in RegionTwo. Although it may last in very short interval. Is there someone can evaluate the security risk is affordable or not. Best Regards Chaoyi Huang (joehuang) From: Matt Fischer [m...@mattfischer.com] Sent: 25 February 2017 11:38 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token At last, we still have one question: For public cloud, it is very common that multi regions are deployed. And the distance is usually very far between the regions. So the transport delay is really a problem. Fernet token requires the data must be the same. Because of the slow connection and high time delay, in our opinion, it is unrealistic that let the keystones from different regions to use the same keystone datacenter. Any idea about this problem? Thanks. There's nothing in Fernet tokens that would cause an issue with the transportation delay. You could mail the Fernet keys to each region and you're still fine, why? Because key rotation means that the "next key" is already in place on every box when you rotate keys. There is a widely held misconception that all keystone nodes must instantaneously sync keys in every region or it won't work, that is simply not true. In fact the main reason we switched to Fernet was to REDUCE the load on our cross-region replication. Without a database full of tokens to deal with, there's basically nothing to replicate as joe says below. User/group/role changes for us was more of a few times a day operation rather than getting a token which is thousands of times per second. __ 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]PKI token VS Fernet token
Database async. replication across data centers should work considering that the data in KeyStone is not updated frequently. There is a little delay for the data replication, may lead to quite few requests rejection in a data center where the data has not arrived. But I think it's quite short and acceptable. For public cloud, I would like to know others thoughts on the security risk, is the security risk also acceptable. Best Regards Chaoyi Huang (joehuang) From: 王玺源 [wangxiyuan1...@gmail.com] Sent: 23 February 2017 21:39 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token Thanks for all your advices and opinions. We'll try to solve the PKI issue and hope it can come back in the future. About the fernet token, we'll test it with the new config options and show you the result later. Hope it performs well. At last, we still have one question: For public cloud, it is very common that multi regions are deployed. And the distance is usually very far between the regions. So the transport delay is really a problem. Fernet token requires the data must be the same. Because of the slow connection and high time delay, in our opinion, it is unrealistic that let the keystones from different regions to use the same keystone datacenter. Any idea about this problem? Thanks. 2017-02-21 8:58 GMT-05:00 Dolph Mathews mailto:dolph.math...@gmail.com>>: It appears that you don't have caching enabled, then. Without enabling caching, Fernet performance is well known to be terrible, which would explain your benchmark results. If you run a similar benchmark with caching, I'd be eager to see the new configuration and benchmark results. On Fri, Feb 17, 2017 at 8:16 AM 王玺源 mailto:wangxiyuan1...@gmail.com>> wrote: Hi Dolph: We made the keystone.conf same with the example. [token] provider = fernet [fernet_tokens] //all configuration is default # # From keystone # # Directory containing Fernet token keys. (string value) #key_repository = /etc/keystone/fernet-keys/ # This controls how many keys are held in rotation by keystone-manage # fernet_rotate before they are discarded. The default value of 3 means that # keystone will maintain one staged key, one primary key, and one secondary # key. Increasing this value means that additional secondary keys will be kept # in the rotation. (integer value) # max_active_keys = 3 Dolph Mathews mailto:dolph.math...@gmail.com>>于2017年2月17日 周五上午7:22写道: Thank you for the data and your test scripts! As Lance and Stanek already alluded, Fernet performance is very sensitive to keystone's configuration. Can your share your keystone.conf as well? I'll also be in Atlanta and would love to talk Fernet performance, even if we don't have a formal time slot on the schedule. On Wed, Feb 15, 2017 at 9:08 AM Lance Bragstad mailto:lbrags...@gmail.com>> wrote: In addition to what David said, have you played around with caching in keystone [0]? After the initial implementation of fernet landed, we attempted to make it the default token provider. We ended up reverting the default back to uuid because we hit several issues. Around the Liberty and Mitaka timeframe, we reworked the caching implementation to fix those issues and improve overall performance of all token formats, especially fernet. We have a few different performance perspectives available, too. Some were run nearly 2 years ago [1] and some are run today [2]. Since the Newton release, we've made drastic improvements to the overall structure of the token provider [3] [4] [5]. At the very least, it should make understanding keystone's approach to tokens easier. Maintaining out-of-tree token providers should also be easier since we cleaned up a lot of the interfaces that affect developers maintaining their own providers. We can try and set something up at the PTG. We are getting pretty tight for time slots, but I'm sure we can find some time to work through the issues you're seeing (also, feel free to hop into #openstack-keystone on freenode if you want to visit prior to the PTG). [0] https://docs.openstack.org/developer/keystone/configuration.html#caching-layer [1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ [2] https://github.com/lbragstad/keystone-performance [3] https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:make-fernet-default [4] https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider [5] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/token-provider-cleanup.html On Wed, Feb 15, 2017 at 8:44 AM, David Stanek mailto:dsta...@dstanek.com>> wrote: On 15-Feb 18:16, 王玺源 wrote: > Hello everyone, > PKI/PKIZ token has been remov
[openstack-dev] [tricircle]weekly meeting of Feb.22
Hello, team, Let's resume weekly meeting after Ocata 3.0.0 released. Agenda of Feb. 22 weekly meeting: 1. Pike features development 2. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 13:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle][all] guide for reading source code
Hello, For those who are interested in digging into Tricircle source code, it'll be good to have a step by step guide. I prepared a wiki page to navigate the source code of Tricircle: https://wiki.openstack.org/wiki/TricircleHowToReadCode It was linked to the wiki page of Tricircle: https://wiki.openstack.org/wiki/Tricircle And also please feel free to update the wiki to make it being more readable and consistent with the code. Should we include it into the source code repo, and maintain it at the same time if we update the code logic? Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]Ocata released and Pike meetup
Hello, Thanks for your great contribution, Tricircle 3.0.0 (Ocata release) has been released after the patch[1] was approved, the release notes could be found at [2]. A meetup for Pike will be held: Feb.17, UTC 1:00~8:00( UTC+8: 9:00 am~4:00 pm), Block G, Huawei Industrial Base, Shenzhen. Etherpad [3]: [1] https://review.openstack.org/#/c/432166/ [2] https://docs.openstack.org/releasenotes/tricircle/ [3] https://etherpad.openstack.org/p/tricircle-pike-design-topics Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle] python-tricircleclient repo officially created
Hi, Victor, Pretty cool! No need to type the boring curl any more. Best Regards Chaoyi Huang (joehuang) From: Morales, Victor [victor.mora...@intel.com] Sent: 16 February 2017 0:19 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tricircle] python-tricircleclient repo officially created Howdy, I’m happy to announce that after OpenStack Governance has approved[1] and infra them processed the request[2], the python-tricircleclient repository has been created[3]. This client pretends to make things simpler for users who require multi region solutions which can be addressed by Tricircle. Hopefully this project helps for the adoption and visibility of this solution. Lastly, this client is still under developing and requires all your expertise to improve it so feel free to add new capabilities and features that you consider necessary. Regards, Victor Morales irc: electrocucaracha [1] https://review.openstack.org/#/c/426419/ [2] https://review.openstack.org/#/c/426859/ [3] http://git.openstack.org/cgit/openstack/python-tricircleclient/ __ 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] [tricircle]no weekly meeting Feb.15
Hello, team, Due to the preparation for the Ocata release and meetup on Feb.17, there is no weekly meeting Feb.15. Let's meet on Friday, and for those who will attend Atlanta PTG, you can have a F2F talk with Zhiyuan, he is the representative of Tricircle team. Best Regards Chaoyi Huang (joehuang) __ 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] [neutron]CIDR overlapping
O, it's being set to "True" in devstack installation. Thanks for clarification. Best Regards Chaoyi Huang (joehuang) From: Kevin Benton [ke...@benton.pub] Sent: 14 February 2017 12:17 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron]CIDR overlapping Do you have allow_overlapping_ips set to True? On Mon, Feb 13, 2017 at 7:56 PM, joehuang mailto:joehu...@huawei.com>> wrote: Hello, During the regression test, I find that Neutron allows CIDR overlapping in same project. neutron --os-region-name RegionOne net-create dup-net1 neutron --os-region-name RegionOne net-create dup-net2 neutron --os-region-name RegionOne subnet-create dup-net1 20.0.1.0/24<http://20.0.1.0/24> neutron --os-region-name RegionOne subnet-create dup-net2 20.0.1.0/24<http://20.0.1.0/24> all commands can be executed successfully, and after then the project has two subnets with same CIDR: 20.0.1.0/24<http://20.0.1.0/24> Should it be allowed? Or it's just because it's too difficult to address the race condition. Best Regards Chaoyi Huang (joehuang) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] [neutron]CIDR overlapping
Hello, During the regression test, I find that Neutron allows CIDR overlapping in same project. neutron --os-region-name RegionOne net-create dup-net1 neutron --os-region-name RegionOne net-create dup-net2 neutron --os-region-name RegionOne subnet-create dup-net1 20.0.1.0/24 neutron --os-region-name RegionOne subnet-create dup-net2 20.0.1.0/24 all commands can be executed successfully, and after then the project has two subnets with same CIDR: 20.0.1.0/24 Should it be allowed? Or it's just because it's too difficult to address the race condition. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]schedule for Ocata release and Pike meetup/PTG
Hello,team, Thanks for your great contribution, the Ocata cycle is almost done. As what we discussed in weekly meeting, the schedule for Ocata release and Pike meetup/PTG as follows: 1.Ocata branch this Friday or early 2. Regression test until Feb.15 3. Ocata release Feb.16 4. Pike meetup on Feb.17, 9:00 am~4:00 pm, G section, Huawei Industrial Base, Shenzhen, China for those who can't go to Atalanta. https://etherpad.openstack.org/p/tricircle-pike-design-topics 5. Core developer LuckyVega (Cai Zhiyuan) will be representative to attend the PTG at Atalanta. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]weekly meeting of Feb. 8
Hello, team, Let's resume weekly meeting after breaks for Chinese New Year. Agenda of Feb. 8 weekly meeting: 1. Ocata release dates 2. Pike meetup before PTG: https://etherpad.openstack.org/p/tricircle-pike-design-topics 3. Representative and topics to PTG 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 13:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]Ocata branch creation
Hello, Tricircle Ocata branch will be created after these two patches are merged before this Friday: 1. https://review.openstack.org/#/c/429457/ 2. https://review.openstack.org/#/c/424601/ Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle] Example EVPN question/use-case
Hello, Curtis and Greg, This is a quite good use case. Thanks for the sharing. Tricircle is working on VxLAN based L2 network across OpenStack clouds for different backends (non-SDN, SDN, L2 GW or non L2 GW). The spec is in review: https://review.openstack.org/#/c/429155/. Currently only SDN controllers which can support using BGP to exchange tunneling endpoint information is considered. It's worth to take this use case into consideration. Please join the review and give your comments, thanks. Best Regards Chaoyi Huang (joehuang) From: Curtis [serverasc...@gmail.com] Sent: 08 February 2017 1:49 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tricircle] Example EVPN question/use-case Hi, I'm not sure if this is useful at all, but there is a blog post [1] from one of the people behind the PacketPushers podcast regarding connecting two OpenStack clouds with a EVPN. They are wondering how to do it. They want to connect an NSX based cloud with a OpenContrail based cloud and do it at very high speeds. Interesting use case, real world. Thanks, Curtis. [1]: http://etherealmind.com/help-wanted-stitching-a-federated-sdn-on-openstack-with-evpn/ __ 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] [tricircle]Pike design topics discussion
Hello, (Repost) As what's discussed during the weekly meeting, let's discuss what's to do in Pike in etherpad next Tuesday morning UTC 1:30 am (9:30am Beijing time, 10:30 Korea/Japan time, Monday 5:30pm PST time) The etherpad link https://etherpad.openstack.org/p/tricircle-pike-design-topics Please input your concerns on what to do in Pike into the etherpad, and let's discuss that time, the duration is around 1.5 hour. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle][ptl] PTL Candidacy for Tricircle Pike cycle
Hello, I would like to announce my self nomination for the PTL candidacy for Tricircle Pike cycle. My name is Chaoyi Huang, IRC handle joehuang. It's great step that the Tricircle project joined the OpenStack big-tent ecosystem in Ocata cycle, thanks to the effort from every Tricircle contributor, and the help from TCs/PTLs/other project contributors. Being one big-tent project is one very important milestone to build the open community, attract more contributors, to accelrate the Tricircle being more and more mature. Although lots of fundatemental features and documentations are ready[1][2], it's time for us to think about the question: when will Tricircle will be ready for production use? Here are some ideas to make Tricircle to reach the goal for production deployment in Pike cycle: * function test ready, enhance scenario test cases and code coverage. * encourage cloud operator to try Tricircle and get feedback from cloud operators for quality, features, and what's to improvement. * feature compliment - shared_vxlan supported L2/L3 networking, advanced networking features like QoS, LBaaS, python client etc. * performance, reliability review and enhancement as needed. * upgradable before production. * keep community as open as any other team, make the contribution in Tricircle is comfortable for anyone, attract more and more contributors. * help and grow any one who wants to try PTL in Queens cycle. Hope everyone will enjoy the contribution in Tricircle. Thank you for your kind consideration of my candidacy. [1]https://github.com/openstack/tricircle/tree/master/releasenotes/notes [2]http://docs.openstack.org/developer/tricircle/ Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]Pike design topics discussion
Hello, As what's discussed during the weekly meeting, let's discuss what's to do in Pike in etherpad next Tuesday morning UTC 1:30 am (9:30am Beijing time, 10:30 Korea/Japan time, Monday 5:30pm PST time) The etherpad link https://etherpad.openstack.org/p/tricircle-pike-design-topics Please input your concerns on what to do in Pike into the etherpad, and let's discuss that time, the duration is around 1.5 hour. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]weekly meeting of Jan.18
Hello, team, Agenda of Jan.18 weekly meeting: 1. Ocata release preparation 2. Pike planning and design topics: https://etherpad.openstack.org/p/tricircle-pike-design-topics 3. QoS and LBaaS feature support 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 13:00. If you have other topics to be discussed in the weekly meeting, please reply the mail. Best Regards Chaoyi Huang (joehuang) __ 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] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC
Hello, I read the meeting log and etherpad, and find that you mentioned OPNFV Multisite and Kingbird project. Some comment on these multi-site related projects: OPNFV multisite, kingbird, tricircle. Multisite is a requirement project in OPNFV to identify the gap and requirement in OpenStack to make OpenStack work for NFV multi-site cloud. Kingbird is one sub-project of Multisite, started after gap analysis in OPNFV, which is aiming at centralized quota management, centralized view for distributed virtual resources, synchronization of ssh keys, images, flavors, etc. across regions in OpenStack multi-region deployments. Currently the project is working on key-pair sync, and centralized quota management feature has been implemented in OPNFV C release. Kingbird is one major topic in OPNFV Multisite weekly meeting. While Tricircle is one OpenStack big-tent official project, which was accepted in Nov.2016, and has been narrowed its scope on networking automation across Neutron in OpenStack multi-region deployments during the big-tent application. Tricircle has basic features of L2/L3 networking across OpenStack cloud, currently local network and shared_VLAN based L2/L3 networking are supported, and is working on VxLAN L2 networking across Neutron, so that L2/L3 networking can also leverage the VxLAN L2 networking capability. You can refer to (review) the networking guide prepared: https://review.openstack.org/#/c/420316/. During the discussion happened in 2015 , both kingbird / tricircle are candidate solutions to address the multisite clouds, Kingbird and Tricircle can work together or separately in OpenStack multi-region deployment scenario, they are complimented each other now. Kingbird has no features about networking automation, and Tricircle has no features related to Nova/Cinder... Tricircle is mostly visible in OpenStack community, while Kingbird is mostly visible in OPNFV community. Welcome to join the meeting: Tricircle: IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 13:00 Multisite & Kingbird: IRC: http://webchat.freenode.net/?channels=opnfv-meeting on every Thursday 8:00-9:00 UTC (During winter time, means CET 9:00 AM). Best Regards Chaoyi Huang (joehuang) From: Anthony SIMONET [anthony.simo...@inria.fr] Sent: 17 January 2017 22:11 To: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org Subject: [openstack-dev] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC Hi all, The agenda is available at: https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 82) Please feel free to add items to the agenda. The meeting while take place on #openstack-meeting. Cheers, Anthony __ 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] [tricircle]Tricircle Pike PTG
Hello, As only few of us may go to Atlanta, the etherpad has been renamed to reflect the fact of our "virtually distributed PTG" https://etherpad.openstack.org/p/tricircle-pike-design-topics We will discuss this in the weekly meeting, "What date and time and venu during the PTG, and meetup for contributors who can't go to Atlanta? It would be great to hold it at the same time, like virtually distributed PTG: some in PTG Atlanta, some in other place, but are inter-connectted through online etherpad." Best Regards Chaoyi Huang (joehuang) ____ From: joehuang Sent: 17 January 2017 10:22 To: openstack-dev Subject: [openstack-dev][tricircle]Tricircle Pike PTG As the Ocata stable branch will be created and released soon, it's time to prepare what we need to discuss and implement in Pike release: The etherpad has been created at: https://etherpad.openstack.org/p/tricircle-ptg-pike Please feel free to add the topics, ideas into the etherpad, and let's plan the agenda as well. Best Regards Chaoyi Huang (joehuang) __ 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] [tricircle]Tricircle Pike PTG
As the Ocata stable branch will be created and released soon, it's time to prepare what we need to discuss and implement in Pike release: The etherpad has been created at: https://etherpad.openstack.org/p/tricircle-ptg-pike Please feel free to add the topics, ideas into the etherpad, and let's plan the agenda as well. Best Regards Chaoyi Huang (joehuang) __ 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] [release][ptl] not planning to serve as release PTL for Pike
Thank you very much for your guide, Doug, this is the first time for Tricircle to release as one big-tent project. Best Regards Chaoyi Huang (joehuang) From: Doug Hellmann [d...@doughellmann.com] Sent: 14 January 2017 4:00 To: openstack-dev Subject: [openstack-dev] [release][ptl] not planning to serve as release PTL for Pike I announced this at the release team meeting on 6 Jan, but thought I should also post to the list as well: I do not plan to serve as the Release Management team PTL for the Pike release cycle. It has been my pleasure to serve as PTL, and we've almost finished the automation work that I envisioned when I joined the team. Now I would like to shift my focus to some other projects within the community. I will still be an active member of the Release Management team, helping with new initiatives and reviews for releases. Doug __ 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] [release] Release countdown for week R-5, Jan 16-20
Great, got it, thanks a lot Best Regards Chaoyi Huang (joehuang) From: Doug Hellmann [d...@doughellmann.com] Sent: 13 January 2017 22:55 To: openstack-dev Subject: Re: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20 Excerpts from joehuang's message of 2017-01-13 01:23:08 +: > Hello, Doug, > > One question, according to the guide for self-branch[1], the Ocata stable > branch should be created for RC1 tag for projects using the > cycle-with-milestone release model. The date for RC1 one is Jan 30 - Feb 03 > according to the schedule [2]. Tricircle is one big-tent project with > cycle-with-intermediary mode, and has dependency on stable Neutron, should > Tricircle Ocata stable branch be created during Jan 30 - Feb 03 or later > than Feb 03? I think Neutron Ocata stable branch will be created during Jan > 30 - Feb 03. You'll probably want to wait until after the Neutron stable branch has been created. You can submit the branch request and either mark it WIP or add a Depends-On to prevent it from merging before the neutron request. Doug > > [1]http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n66 > [2] https://releases.openstack.org/ocata/schedule.html > > Best Regards > Chaoyi Huang (joehuang) > > > From: Doug Hellmann [d...@doughellmann.com] > Sent: 13 January 2017 2:34 > To: openstack-dev > Subject: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20 > > Focus > - > > Feature work and major refactoring should be starting to wrap up > as we approach the third milestone and various feature and release > freeze dates. > > The deadline for non-client library releases is Thursday 19 Jan. > We do not grant Feature Freeze Extensions for any libraries, so > that is a hard freeze date. Any feature work that requires updates > to non-client libraries should be prioritized so it can be completed > by that time. > > Release Tasks > - > > As we did at the end of Newton, when the time comes to create > stable/ocata branches they will be configured so that members of > the $project-release group in gerrit have permission to approve > patches. This group should be a small subset of the core review > team, aware of the priorities and criteria for patches to be approved > as we work toward release candidates. Release liaisons should ensure > that these groups exist in gerrit and that their membership is > correct for this cycle. Please coordinate with the release management > team if you have any questions. > > General Notes > - > > We will start the soft string freeze during R-4 (23-27 Jan). See > https://releases.openstack.org/ocata/schedule.html#o-soft-sf for > details > > The release team is now publishing the release calendar using ICS. > Subscribe your favorite calendaring software to > https://releases.openstack.org/schedule.ics for automatic updates. > > Important Dates > --- > > Final release of non-client libraries: 19 Jan > > Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan > > Ocata release schedule: http://releases.openstack.org/ocata/schedule.html > __ 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] [machine learning] Question: Why there is no serious project for machine learning ?
What do you mean " serious project " ? Best Regards Chaoyi Huang (joehuang) From: 严超 [yanchao...@gmail.com] Sent: 13 January 2017 15:53 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [machine learning] Question: Why there is no serious project for machine learning ? Hi, all, I'm wondering if there is a serious project for machine learning in Openstack ? For us to easily build a model in industrial operational level. Thanks, Andy Yan __ 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] [release] Release countdown for week R-5, Jan 16-20
Hello, Doug, One question, according to the guide for self-branch[1], the Ocata stable branch should be created for RC1 tag for projects using the cycle-with-milestone release model. The date for RC1 one is Jan 30 - Feb 03 according to the schedule [2]. Tricircle is one big-tent project with cycle-with-intermediary mode, and has dependency on stable Neutron, should Tricircle Ocata stable branch be created during Jan 30 - Feb 03 or later than Feb 03? I think Neutron Ocata stable branch will be created during Jan 30 - Feb 03. [1]http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n66 [2] https://releases.openstack.org/ocata/schedule.html Best Regards Chaoyi Huang (joehuang) From: Doug Hellmann [d...@doughellmann.com] Sent: 13 January 2017 2:34 To: openstack-dev Subject: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20 Focus - Feature work and major refactoring should be starting to wrap up as we approach the third milestone and various feature and release freeze dates. The deadline for non-client library releases is Thursday 19 Jan. We do not grant Feature Freeze Extensions for any libraries, so that is a hard freeze date. Any feature work that requires updates to non-client libraries should be prioritized so it can be completed by that time. Release Tasks - As we did at the end of Newton, when the time comes to create stable/ocata branches they will be configured so that members of the $project-release group in gerrit have permission to approve patches. This group should be a small subset of the core review team, aware of the priorities and criteria for patches to be approved as we work toward release candidates. Release liaisons should ensure that these groups exist in gerrit and that their membership is correct for this cycle. Please coordinate with the release management team if you have any questions. General Notes - We will start the soft string freeze during R-4 (23-27 Jan). See https://releases.openstack.org/ocata/schedule.html#o-soft-sf for details The release team is now publishing the release calendar using ICS. Subscribe your favorite calendaring software to https://releases.openstack.org/schedule.ics for automatic updates. Important Dates --- Final release of non-client libraries: 19 Jan Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan Ocata release schedule: http://releases.openstack.org/ocata/schedule.html __ 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