Re: [openstack-dev] [Neutron][qos] Question about behavior expectations if network policy is set
Hey all, Quick question: If I have a network and a port, and neither has any QOS policy set, and then I change the network to set the qos_policy_id, should this new QOS policy affect traffic on the already-created port? In other words, is this a network default for future ports (like with port_security_enabled) which would only affect ports created on this network from here on out (but leave already-created ports untouched)? Or is this a network setting which takes effect for all ports, regardless if they were already created or not? If the latter, the question had come up, this seems to mean that if a net policy is set, then there is no way a port can be set to have no policy, because if you unset a port's specific policy, it will fallback to the network policy, rather than skip policy calculations altogether. So, what does one do if they want all ports on a net to follow Policy X, EXCEPT for a single port? I would say the first question is the most important for me to understand the behavior, with the second question as a further clarification. Thanks a bunch! Sincerely, Michael Micucci __ 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][qos] Question about behavior expectations if network policy is set
Hey all, Quick question: If I have a network and a port, and neither has any QOS policy set, and then I change the network to set the qos_policy_id, should this new QOS policy affect traffic on the already-created port? In other words, is this a network default for future ports (like with port_security_enabled) which would only affect ports created on this network from here on out (but leave already-created ports untouched)? Or is this a network setting which takes effect for all ports, regardless if they were already created or not? If the latter, the question had come up, this seems to mean that if a net policy is set, then there is no way a port can be set to have no policy, because if you unset a port's specific policy, it will fallback to the network policy, rather than skip policy calculations altogether. So, what does one do if they want all ports on a net to follow Policy X, EXCEPT for a single port? I would say the first question is the most important for me to understand the behavior, with the second question as a further clarification. Thanks a bunch! Sincerely, Michael Micucci __ 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] Social at the summit
I'd love to join as well! On 4/25/2016 3:56 PM, Brian Haley wrote: +1 On 4/25/16 1:07 PM, Kyle Mestery wrote: OK, there is enough interest, I'll find a place on 6th Street for us and get a reservation for Thursday around 7 or so. Thanks folks! On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han wrote: +1 :) Han Zhou Irc: zhouhan On Monday, April 25, 2016, Korzeniewski, Artur wrote: Sign me up :) Artur IRC: korzen -Original Message- From: Darek Smigiel [mailto:smigiel.dari...@gmail.com] Sent: Monday, April 25, 2016 7:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Social at the summit Count me in! Will be good to meet all you guys! Darek (dasm) Smigiel On Apr 25, 2016, at 12:13 PM, Doug Wiegley wrote: On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka wrote: WAT??? It was never supposed to be core only. Everyone is welcome! +2 irony intended. Socials are not controlled by gerrit ACLs. :-) doug Sent from my iPhone On 25 Apr 2016, at 11:56, Edgar Magana wrote: Would you extend it to ex-cores? Edgar On 4/25/16, 10:55 AM, "Kyle Mestery" wrote: Ihar, Henry and I were talking and we thought Thursday night makes sense for a Neutron social in Austin. If others agree, reply on this thread and we'll find a place. Thanks! Kyle ___ ___ 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 __ 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 __ 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] [Neutron] Team meeting on Tuesday 1400UTC
On 01/14/2016 03:49 AM, Sean M. Collins wrote: On Wed, Jan 13, 2016 at 02:59:35AM CST, Ihar Hrachyshka wrote: Kevin Benton wrote: The issue with this data is that who says something is not a good metric. For example, this shows that I attended more than twice as many afternoon meetings as the morning meetings when I know I actually only missed a couple of morning ones. I just don't say anything unless there is something that I feel I need to comment on. Same here. I am almost always present on Tue meetings, but the data shows 13/22. I should make some more silly comments to bump my stats! Time to break out that cron job that just writes 'o/' to a socket! ;) Could we do a roll call and would that in any way be useful? :) __ 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] Introducing Zephyr: A neutron end-to-end network testing framework
* Hello all! I am pleased to announce the availability of "Zephyr", a new test framework for neutron API-based end-to-end network testing! Currently, there is a LaunchPad at https://launchpad.net/zephyr-neutronand the code is public and can currently be found athttp://github.com/midonet/zephyr(plans to move to a OpenStack project are currently in progress, which would move the code base under the OpenStack umbrella). zephyr ˈzɛfə/ noun 1. a soft gentle breeze. Zephyr was born as a black-box testing system for the MidoNet virtual networking product, testing scenarios and end-to-end functionality at a Neutron API level (rather than to the MidoNet API). Zephyr's design principles are: * Neutron-based end-to-end testing of OpenStack networking **(no keystone, no nova, etc.) which leads to a vendor-agnostic design (currently set to work with midonet, but design will allow for future decoupling) * Decoupled Physical - Virtual management, so any physical layer model (like docker or IP namespaces, or VMs through ssh, or even an already running system like with devstack) can be used without modifying tests * Community collaboration and conformation to OpenStack community standards Zephyr is a work in progress, and as such there are several paths we have open to us: * Make Zephyr truly vendor-agnostic: Right now Zephyr relies on MidoNet as a backend, but we'd like to have it work with any vendor backend and any physical model, like docker containers, IP net namespaces, VMs through ssh, running devstack environment, and possibly even bare iron multi-node! (Note: we currently support IP net namespaces and are working on devstack integration) * Integrate as a testing system as is decided by the community (Integrated with fullstack? As a devstack addon?) * Improve usability and reporting via OpenStack standard models * Get Zephyr to work with other Python testing frameworks (currently unittest), like nose, etc. * Update code to match OpenStack community coding-style * Maintain and update code as suggested through code review * Remain flexible and open so community members can add fixes and specific improvements. I look forward to making Zephyr work as a suitable neutron testing platform (either inside fullstack, or on its own if the community wishes to move that way) and meet the needs of as much of the community as possible! In that vein, I would like to move zephyr into community standard repositories, bug trackers, mailing lists, etc. (Launchpad ready at: https://launchpad.net/zephyr-neutronand IRC channel already set up! Please come and visit us at: #openstack-zephyr), and really try to get everyone involved wherever I can. Please don't hesitate to contact me at micu...@midokura.com or on IRC as “kitsuneninetails” in the #openstack-zephyr channel with any questions, comments, or suggestions! Sincerely, Michael Micucci IRC: kitsunenineta...@freenode.net Zephyr IRC channel: #openstack-zephyr * -- 私の力で進む、果てしないこの道を。 With my own strength, I will continue down this endless road. __ 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] OpenStack Mitaka (三鷹) - Our next release name has been selected
A little off-topic, so please forgive me. :) If you go to the Ghibli Museum (and yes, it IS a great experience), be sure to get tickets in advance. You have to buy them at Lawson store before the actual ticket date (no same-day sales). Just a heads up for anyone planning to go. ;) As I said, I lived in that area until recently, so if anyone wants some tips on places to go, I might be able to provide a couple sightseeing spots. ;) Thanks! Michael Micucci On 07/15/2015 08:08 PM, Jaesuk Ahn wrote: Thank everyone in the community for the great collaboration. :) It seems like Mitaka is hosting great animations everyone loves, Ghibli Museum (http://www.ghibli-museum.jp/en/). We should probably plan an official trip there during Tokyo Summit. :) On Wed, Jul 15, 2015 at 4:00 AM Ian Cordasco mailto:ian.corda...@rackspace.com>> wrote: On 7/14/15, 13:47, "Monty Taylor" mailto:mord...@inaugust.com>> wrote: >Hi everybody! > >Ok. There is nothing more actually useful I can say that isn't in the >subject line. As I mentioned previously, the preliminary results from >our name election are here: > >http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc > >As you are all probably aware by now, as a follow on step, the OpenStack >Foundation staff assessed the names chosen for legal risk in the order >we ranked them. The first two had significant identified problems so we >skipped them. The third had no legal problems, but after announcing it >as the choice, it came to light that there were significant social >issues surrounding the name. > >The fourth on the list, Mitaka (三鷹) is clear. > >So please join me in welcoming the latest name to our family ... and if >you, like me, are not a native Japanese speaker, in learning two (more) >new characters. > >I'd also like to thank everyone in our community for understanding. As >we try our best to be an inclusive worldwide community, the >opportunities for unwitting missteps are vast and ultimately probably >unavoidable. Being able to recognize and deal with them and learn from >them as they occur makes me proud of who we are and what we've become. I agree. It's really encouraging to see a community as large as OpenStack embrace inclusivity and empathy around social issues. __ 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 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] OpenStack Meiji (明治) - Our next release name has been selected
Dear all, #4 was Mitaka (三鷹, meaning "three hawks"), I believe? Mitaka is a very beautiful city, if I may say so (I lived there, so I'm a bit biased :)), with Inokashira Park, a zoo, and many walking trails. Plus, the Ghibli Museum is there, which celebrates a very famous and well-loved animation studio throughout the world, with a similar pedigree to Disney in the U.S.A. (such as Spirited Away, Howl's Moving Castle, Nausicaa and the Valley of the Wind, My Neighbor Totoro, among many other great films) With animation being a world-wide export from Japan, it seems like a nice (and current) thing to celebrate. I'd like to support Iwamoto-san's proposal in the interest of peace and cooperation between our international communities, and suggest we switch to "Mitaka." I just hope there are no legal problems with this name as well. :) Sincerely, Michael Micucci On 07/08/2015 02:31 PM, IWAMOTO Toshihiro wrote: It is totally understandable that the combination of "Japan" and "Meiji" recalls harsh history to some people, especially in East Asia. As a Japanese, I'm sorry for that. I think the release naming process should not cause such friction. Could we just select some other neutral candidate name instead? At Wed, 08 Jul 2015 04:40:58 +, Jaesuk Ahn wrote: Dear OpenStack Community, As Clint mentioned, there is some historical background regarding the name of "Meiji". I have been aware of the potential problem with "Meiji", however, I have not raise my voice here since it was not the top of the list. However, with current situation, IMHO, it is better to present my concern over this name. It was briefly mentioned in the previous email thread. Once again, please understand that the name "Meiji" can create some historical debate in East Asia, especially in Korea. Under the name of Emperor Meiji, Japan forcefully colonized Korea. Lots of people in Korea suffered during the colonization. Furthermore, this history is not the one only exists on the book. This is actually very recent event in terms of history. FYI, there is a wiki entry: https://en.wikipedia.org/wiki/Korea_under_Japanese_rule If you look at "legacy" section in the above wiki entry, you will understand what I am referring to. I am not saying the word "Meiji" is bad in general. I just want to state that this word can cause very negative feeling to some people in East Asia. I totally value the community's process and rules. I recognize that process to select "Meiji" itself was not the problem at all. However, I am sincerely asking the community to acknowledge my concern over this name, and please put some effort as a community to avoid any unnecessary debate. Thank you. Best wishes for everyone here in the community. Jaesuk Ahn, Ph.D. member of OpenStack Community and OpenStack Korea User Group. On Wed, Jul 8, 2015 at 2:24 AM Clint Byrum wrote: http://afe.easia.columbia.edu/main_pop/kpct/kp_meiji.htm There's a summary of what Meiji might mean to historians. I'm not sure if OpenStack needs to be too concerned about this, but I believe this is what Ian is referring to as "historical and political debates in East Asia." Seems like a hot-button name for OpenStack to adopt. Excerpts from Ian Y. Choi's message of 2015-07-07 05:40:52 -0700: Hello, I think the third name 'Meiji' may arise some historical and political debates in East Asia, as far as I know. Could you share what significant identified problems are on the first two selected from our election? With many thanks, /Ian On Tue, Jul 7, 2015 at 8:55 PM, Masayuki Igawa Hi, # I'm a native Japanese speaker :-) 2015年7月7日(火) 20:33 Amrith Kumar : Maybe this (the google answer)? www.youtube.com/watch?v=Qvw0A12aOGQ Yeah, this is correct pronunciation. But someone who is a native Japanese speaker should confirm. https://www.youtube.com/watch?v=D9vwge557hY I think this is a casual version and Japanese people are familiar with this. Thanks, -- Masayuki Igawa -amrith P.S. the yahoo answer suggests that you pronounce it as "Meh - gee" with the emphasis on the "meh" ;) -Original Message- From: Matthias Runge [mailto:mru...@redhat.com] Sent: Tuesday, July 07, 2015 6:08 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote: significant identified problems... but the third in the list, Meiji (明 治) is clear. So please join me in welcoming the latest name to our family ... and if you, like me, are not a native Japanese speaker, in learning two new characters. Could someone provide a hint please, how to pronounce this properly? -- Matthias Runge
