Re: [openstack-dev] [k8s] OpenStack and Containers White Paper
51 <+44%207446%20862551> > > *PORT.*DIRECT > United Kingdom > https://port.direct > > This e-mail message may contain confidential or legally privileged > information and is intended only for the use of the intended recipient(s). > Any unauthorized disclosure, dissemination, distribution, copying or the > taking of any action in reliance on the information herein is prohibited. > E-mails are not secure and cannot be guaranteed to be error free as they > can be intercepted, amended, or contain viruses. Anyone who communicates > with us by e-mail is deemed to have accepted these risks. Port.direct is > not responsible for errors or omissions in this message and denies any > responsibility for any damage arising from the use of e-mail. Any opinion > and other statement contained in this message and any attachment are solely > those of the author and do not necessarily represent those of the company. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaesuk Ahn, Team Lead Virtualization SW Lab, SW R&D Center SK Telecom __ OpenStack Development Mailing 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-helm] Core reviewer retirements
I really appreciate their efforts on openstack-helm. they made this project possible. :) I also hope to collaborate together again!! I will see you around on irc or other places. ;) Thanks!! 2018년 3월 28일 (수) 오전 8:50, MCEUEN, MATT 님이 작성: > A handful of the OpenStack-Helm core reviewers have shifted their focus > over the past half year, and have not had the opportunity to maintain the > same level of reviews and contributions. We've jointly agreed that it's > the right time for them to retire as active core reviewers. > > Brandon Jozsa > Larry Rensing > Darla Ahlert > > These folks helped set the direction of OpenStack-Helm, and I can't thank > them enough for their contributions and dedication. They'll always be part > of the team, and circumstances permitting in the future, I hope to > collaborate closely again! > > Thanks, > Matt McEuen > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaesuk Ahn, Team Lead Virtualization SW Lab, SW R&D Center SK Telecom __ OpenStack Development Mailing 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-helm] the first CI/CD focused weekly irc meeting
Hi everyone, In the past, we have discussed an idea of having CI/CD focused meeting along with regular irc team meeting. Rather than having a separate meeting, During the Sydney summit, I, Pete, and Stacy talked together and agreed on the following: - rather than having a separate schedule, let's use one of regular meeting slot. - let's have the first CI/CD focused meeting on Nov. 28 regular irc meeting. If you are interested in CI/CD focused topic in the scope of OpenStack-Helm, pls find a way to Nov 28 regular irc team meeting. :) Cheers, Jaesuk Ahn (jayahn) FYI, OpenStack-Helm has weekly irc meeting(1) on every Tuesday (15:00 UTC). -- Jaesuk Ahn, Ph.D. SDI Tech. Lab, SK Telecom __ OpenStack Development Mailing 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-helm] Announcing OpenStack-Helm as a hosted project
This is a amazing news. Let’s make it super great together. :)
Jaesuk Ahn, Ph.D.
Open System Lab, SK Telecom
. OpenStack Korea User Group Coordinator &
. Cloud Native Computing Seoul Meetup Organizer
On 2017년 6월 29일 (목) at 오전 9:31 Ihor Dvoretskyi
<
mailto:Ihor Dvoretskyi
> wrote:
a, pre, code, a:link, body { word-wrap: break-word !important; }
Amazing news, my congratulations!
I'm excited to see how Kubernetes+OpenStack collaboration moves forward.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
mailto:openstack-dev-requ...@lists.openstack.org
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Thu, Jun 29, 2017 at 3:07 AM, Steve Wilkerson
<
mailto:wilkers.st...@gmail.com
>
wrote:
Hello everyone!
Now that Boston has come and gone, we'd like to formally announce that
OpenStack-Helm is now a hosted project on OpenStack infra. We received
a great deal of positive feedback in Boston, and we're excited to see
what's next for both OpenStack and Kubernetes together.
We'd like to invite anyone who's interested in working on OpenStack on
top of Kubernetes to contribute to OpenStack-Helm. The OpenStack-Helm
wiki can be found here:
https://wiki.openstack.org/wiki/Openstack-helm
. The OpenStack-Helm
Launchpad currently has blueprints listed that are new-contributor
friendly, and we’d be happy to help any new contributors either find
or identify work that would be helpful as the project moves forward.
Anyone is welcome to join us in #openstack-helm on freenode and/or the
#openstack-helm channel in the Kubernetes Slack team (we've got a
chatbot that mirrors all chat between the two). Our weekly meeting is
at 3:00PM UTC on Tuesdays in #openstack-meeting-5 (next Tuesday’s
meeting on 7/4 will be cancelled due to the holiday). Both the
Eavesdrop history of our meetings and the agenda for future meetings
can be found via links on the wiki page.
On behalf of the core team; alanmeadows, v1k0d3n, portdirect,
lrensing, lamt, and myself, I'd really like to thank the help and
support we've got thus far, and we look forward to meeting and working
with new contributors. If you have any questions, please feel free to
reach out.
Cheers,
srwilkers
__
__
__
OpenStack Development Mailing List (not for usage questions)
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] PTG from the Ops Perspective - a few short notes
evelopment Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Rackspace Limited is a company registered in England & Wales (company > registered number 03897010) whose registered office is at 5 Millington > Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy > can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail > message may contain confidential or privileged information intended for the > recipient. Any dissemination, distribution or copying of the enclosed > material is prohibited. If you receive this transmission in error, please > notify us immediately by e-mail at ab...@rackspace.com and delete the > original message. Your cooperation is appreciated. > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaesuk Ahn, Ph.D. SDI Tech. Lab, SK Telecom __ OpenStack Development Mailing 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] [Monasca] influxDB clustering and HA will be "commercial option".
Hi, Monasca developers and users, https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ "For our current and future customers, we’ll be offering clustering and high availability through Influx Cloud, our managed hosting offering, and Influx Enterprise, our on-premise offering, in the coming months.” It seems like “clustering” and “high availablity” of influxDB will be available only in commercial version. Monasca is currently leveraging influxDB as a metrics and alarm database. Beside vertical, influxDB is currently only an open source option to use. With this update stating “influxDB open source sw version will not have clustering / ha feature”, I would like to know if there has been any discussion among monasca community to add more database backend rather than influxDB, especially OpenTSDB. Thank you. -- Jaesuk Ahn, Ph.D. Software Defined Infra Tech. Lab. SKT __ OpenStack Development Mailing 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] [Monasca] collectd-Monasca Python plugin
We are looking into similar plan to have collectd-plugin for Monasca. There are some env. we cannot deploy monasca agent, but want to put data into Monasca. In addition, we wanted to use easily accepted collectd for gathering data from legacy env. It will be interesting to see more detail about your plan. Cheers, --- Jaesuk Ahn SDI Tech. Lab, SKT 2016년 1월 21일 (목) 19:11, Alonso Hernandez, Rodolfo < rodolfo.alonso.hernan...@intel.com>님이 작성: > Hello: > > We are doing (or at least planning) a collectd-Monasca Python plugin. This > plugin will receive the data from RPC calls form collectd and will write > this data in Monasca, using statsd API. > > My question is: do you think this development could be useful? Does it > worth? Any comment? > > Thank you in advance. Regards. > > Rodolfo Alonso. > -- > Intel Research and Development Ireland Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > > > This e-mail and any attachments may contain confidential material for the > sole > use of the intended recipient(s). Any review or distribution by others is > strictly prohibited. If you are not the intended recipient, please contact > the > sender and delete all copies. > > > __ > OpenStack Development Mailing 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 Mitaka (三鷹) - Our next release name has been selected
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 wrote: > On 7/14/15, 13:47, "Monty Taylor" 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://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-operators] [Openstack] Rescinding the M name decision
+1 from me as well. 2015년 7월 10일 (금) 18:27, Neil Jerram 님이 작성: > On 10/07/15 10:19, Thierry Carrez wrote: > > > > Part of the confusion here is that we are not naming "releases". We are > > naming release *cycles*. We are giving a name to a period of time, > > basically. In that period of time, various version numbers for various > > components will be released. Saying "Glance 12.0.0 was released in > > OpenStack 13 cycle" is not really helping. > > > > We won't run out of letters, because the names can cycle back to A > > (potentially using a new theme, away from "geographic features near > > where the corresponding design summit happened"). > > > > So while we could technically name a release cycle "14", I feel it's a > > bit more difficult to rally around a number than a name. Also, numbers > > wouldn't really solve the perceived issues with names: numbers happen to > > also be culturally meaningful. You don't have a 13th floor in many US > > buildings. In China, building miss the 4th floor instead. 9 is feared in > > Japan. And don't talk about 39 to Afghans. > > > > I think "growing up" is accepting the pain that comes with picking a > > good name, rather than sidestepping the issue. > > +1 to all that. Nicely put. > > Neil > > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > __ OpenStack Development Mailing 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] Rescinding the M name decision
First of all, I really appreciate Itoh's research on each name. In my personal opinion, I don't see any significant problem using words in the list except those that have legal issue. I am realizing that keeping proper line between "significant concern" vs "negligible concern" would be very tricky, especially when it comes down to regional culture and history. However, I will do my best to help this process. Anyway, I do hope we select a release name which can be loved by everyone in the community, and honor all the contributors in Japan hosting Tokyo summit. Cheers, On Thu, Jul 9, 2015 at 2:16 PM Masanori Itoh wrote: > Hello community, > > | If anyone has concerns about any of these potential choices, > | please raise them now. > > As one of common Japanese, I would like to express my personal opinion > related to *the concern* raised recently. > > > 1. Names that remind particular companies > > I don't write concrete company names here, but the following names > remind us (for Japanese, at least) very particular company names. > This is because there are usually HQs or famous facilities of those > companies. > > - Mita > - Mitaka > - Musashino > - Meguro > > > 2. Trademarks / Exact (major) company name > > - Mizuho is one of the 3 mega-banks in Japan. > http://www.mizuhobank.com/index.html > > > 3. Historical concerns > > The below is some information that could raise similar argument. > > - War ship names > During the WW2, there were several war ships with names: > - Musashi > https://en.wikipedia.org/wiki/Japanese_battleship_Musashi > - Mizuho > https://en.wikipedia.org/wiki/Japanese_seaplane_carrier_Mizuho > > - War related places > - Mitaka > In those days, there was a large aircraft factory that > produced including Zero fighter. > https://en.wikipedia.org/wiki/Mitsubishi_A6M_Zero > > - Potential concern > - Marunouchi > 'Marunouchi' has a close relationship with the Imperial Palace. > https://en.wikipedia.org/wiki/Marunouchi > > > In the above, although I did my best, I might have missed some more > things. > But, anyway, I have no choice other than stating the above publicly > in order to prove that I didn't intentionally hide anything . > > > Best regards, > Masanori > > > On Wed, Jul 8, 2015 at 11:40 PM, Monty Taylor > wrote: > > Hi everyone! > > > > In light of issues raised concerning the initially selected name for the > > M release (Meiji), that name will not be used. > > > > It turns out fully open community and fully inclusive collaboration is a > > hard thing to get right. On the one hand, we do not want to exclude > > anyone's input or contribution. On the other hand, we do not want the > > result of that openness to result in effective exclusion or seeming > > persecution of a minority group. > > > > We tried very hard with this naming election to ensure that everyone was > > able to participate in nominations, and that everyone was able to > > participate in elections without the sense that someone had arbitrarily > > limited anyone else's contribution unduly. > > > > There are ways in which this was successful and ways in which is was > > not. Clearly the cultural and historical connotations of this choice are > > an area where the democratic process did not serve us, and I expect us > > to circle back and do work to figure out how to do better in our next > > iteration. > > > > The foundation team is doing legal due diligence on the next set of > > names in the list below (#4-6) and we expect to have an update within a > > week. If anyone has concerns about any of these potential choices, > > please raise them now. > > > > 1. Mita (三田) (Condorcet winner: wins contests with all other choices) > > 2. Minato (港) loses to Mita (三田) by 954–913 > > 3. Meiji (明治) loses to Mita (三田) by 1034–873, loses to Minato (港) > > by 1052–879 > > 4. Mitaka (三鷹) loses to Mita (三田) by 1094–702, loses to Meiji (明 > > 治) by 1012–870 > > 5. Musashi (武蔵) loses to Mita (三田) by 1093–829, loses to Mitaka (三 > > 鷹) by 971–892 > > 6. Meguro (目黒) loses to Mita (三田) by 1137–690, loses to Musashi (武 > > 蔵) by 958–872 > > 7. Minami (みなみ) loses to Mita (三田) by 1183–621, loses to Meguro > > (目黒) by 858–857 > > 8. Mejiro (目白) loses to Mita (三田) by 1294–485, loses to Minami (み > > なみ) by 990–658 > > 9. Mizuho (瑞穂) loses to Mita (三田) by 1338–421, loses to Mejiro (目 > > 白) by 905–625 > > 10. Musashino (武蔵野) loses to Mita (三田) by 1472–305, loses to > > Mizuho (瑞穂) by 1034–456 > > 11. Marunouchi (丸の内) loses to Mita (三田) by 1505–275, loses to > > Musashino (武蔵野) by 931–481 > > > > 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 > > __
Re: [openstack-dev] [openstack-community] OpenStack Meiji (明治) - Our next release name has been selected
I do agree with Jeremy. We are being away from the original topic of this thread. I suggest we initiate a separate thread on single mailing list regarding release naming policy. -- Jaesuk Ahn On Wed, Jul 8, 2015 at 11:38 PM Jeremy Stanley wrote: > On 2015-07-08 10:08:07 -0400 (-0400), Monty Taylor wrote: > > On 07/08/2015 01:51 AM, Tristan Goode wrote: > [...] > > > So let's give up naming things like toys in our play crib, start acting > > > like grown ups and using semver or plain old integers. At worst, we > might > > > have some people see bugs in version 13. > > > > We already use semver. This is not a realistic solution to anything. > > To be slightly more specific... > > http://git.openstack.org/cgit/openstack/cinder/tag/?id=7.0.0.0b1 > > http://git.openstack.org/cgit/openstack/glance/tag/?id=11.0.0.0b1 > > http://git.openstack.org/cgit/openstack/neutron/tag/?id=7.0.0.0b1 > > http://git.openstack.org/cgit/openstack/ceilometer/tag/?id=5.0.0.0b1 > > http://git.openstack.org/cgit/openstack/heat/tag/?id=5.0.0.0b1 > > http://git.openstack.org/cgit/openstack/nova/tag/?id=12.0.0.0b1 > > http://git.openstack.org/cgit/openstack/trove/tag/?id=4.0.0.0b1 > > http://git.openstack.org/cgit/openstack/horizon/tag/?id=8.0.0.0b1 > > http://git.openstack.org/cgit/openstack/sahara/tag/?id=3.0.0.0b1 > > ...et cetera. Is the suggestion to take the mean of those release > numbers to determine an "OpenStack" release identifier, or maybe a > sum total? (This is of course a rhetorical question.) We're naming a > release cycle which tracks the development process of a bunch of > different releases of discrete components each with their own > version numbers. > > Also, lets stop insulting people on public mailing lists by implying > that they or their processes and customs are infantile. It's not > constructive at all. Further, we should pick one mailing list on > which to have this discussion rather than cross-posting to four. > -- > Jeremy Stanley > > ___ > Community mailing list > commun...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community > __ OpenStack Development Mailing 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
> > I just wonder why nobody raised issues with the name while it was on the > proposed names wiki page, while it was on the ballot, or while it was > under final consideration. We've known that "Meiji" was an option for > one month, and that it was #3 in the candidate names for more than 2 > weeks. And yet nobody ever raised any issue with it until it was > officially chosen and announced, at which point it's a lot more > difficult to change. > > I have been aware of this potential issue since it was on the ballot. I actually hesitated to raise this issue worrying it might cause un-wanted debate between members. I basically thought voting process would filter this kind of controversial word. Then, I saw that this name was #3, and thought I did not need to raise the issue since it was not on the top. As Thierry said, I should have raised the issue back then, not at this last moment. I sincerely apologize for that. I have my lesson learned throughout this case. BTW, I have to say that I am really happy that we are able to resolve this kind of difficult issue as a community, respecting each other. -- Jaesuk Ahn > -- > 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] OpenStack Meiji (明治) - Our next release name has been selected
"Mitaka" seems very beautiful name. I am pretty sure it will be really beautiful city as Michael described. Anyway, I will follow any process to pick the name. As long as I know, there has already been active discussion on versioning. Switching from year-based policy to sem versioning. For the release name, although it can create unexpected debate like this one, I personally think using word can have its own benefit. If the number is everything to describe a release, it is less fun for sure. =) I am pretty sure we can come up with better way to have our release name. I will actively participate such discussion. Cheers, Jaesuk Ahn, Ph.D. member of OpenStack Community.. On Wed, Jul 8, 2015 at 2:58 PM Michael Micucci wrote: > 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 po
Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected
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 > > > wrote: > > > > > 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 > > >> > > >> > __ > > >> OpenStack Development Mailing List (not for usage questions) > > >> Unsubscribe: > > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openst
Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler
+1 for this proposal. We are highly interested in this one. Jaesuk Ahn, Ph.D. Team Lead, Next Generation Cloud Platform Dev. Project KT … active member of openstack community On Jun 4, 2014, 5:29:36 PM, John Garbutt wrote: On 3 June 2014 14:29, Jay Pipes <mailto:jaypi...@gmail.com> wrote: > tl;dr > = > > Move CPU and RAM allocation ratio definition out of the Nova scheduler and > into the resource tracker. Remove the calculations for overcommit out of the > core_filter and ram_filter scheduler pieces. +1 I hope to see us send more specific stats to the scheduler, that each filter/weigher can then interpret. The extensible system then means you can optimise what you send down the scheduler to a minimum. The next step is doing differential updates, with more infrequent full sync updates. But we are getting there. As you say, I love that we do the calculation once per host, not once per request. It plays really well with the caching scheduler work, and the new build and run instance flow that help work towards the scheduler process(es) doing the bare minimum on each user request. > Details > === > > Currently, in the Nova code base, the thing that controls whether or not the > scheduler places an instance on a compute host that is already "full" (in > terms of memory or vCPU usage) is a pair of configuration options* called > cpu_allocation_ratio and ram_allocation_ratio. > > These configuration options are defined in, respectively, > nova/scheduler/filters/core_filter.py and > nova/scheduler/filters/ram_filter.py. > > Every time an instance is launched, the scheduler loops through a collection > of host state structures that contain resource consumption figures for each > compute node. For each compute host, the core_filter and ram_filter's > host_passes() method is called. In the host_passes() method, the host's > reported total amount of CPU or RAM is multiplied by this configuration > option, and the product is then subtracted from the reported used amount of > CPU or RAM. If the result is greater than or equal to the number of vCPUs > needed by the instance being launched, True is returned and the host > continues to be considered during scheduling decisions. > > I propose we move the definition of the allocation ratios out of the > scheduler entirely, as well as the calculation of the total amount of > resources each compute node contains. The resource tracker is the most > appropriate place to define these configuration options, as the resource > tracker is what is responsible for keeping track of total and used resource > amounts for all compute nodes. +1 > Benefits: > > * Allocation ratios determine the amount of resources that a compute node > advertises. The resource tracker is what determines the amount of resources > that each compute node has, and how much of a particular type of resource > have been used on a compute node. It therefore makes sense to put > calculations and definition of allocation ratios where they naturally > belong. > * The scheduler currently needlessly re-calculates total resource amounts > on every call to the scheduler. This isn't necessary. The total resource > amounts don't change unless either a configuration option is changed on a > compute node (or host aggregate), and this calculation can be done more > efficiently once in the resource tracker. > * Move more logic out of the scheduler > * With the move to an extensible resource tracker, we can more easily > evolve to defining all resource-related options in the same place (instead > of in different filter files in the scheduler...) +1 Thats a much nicer solution than shoving info from the aggregate into the scheduler. Great to avoid that were possible. Now there are limits to this, I think. Some examples that to mind: * For per aggregate ratios, we just report the free resources, taking into account the ratio. (as above) * For the availability zone filter, each host should report its availability zone to the scheduler * If we have filters that adjust the ratio per flavour, we will still need that calculation in the scheduler, but thats cool In general, the approach I am advocating is: * each host provides the data needed for the filter / weightier * ideally in a way that requires minimal processing And after some IRC discussions with Dan Smith, he pointed out that we need to think about: * with data versioned in a way that supports live-upgrades Thanks, John ___ OpenStack-dev mailing list mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer][IceHouse] Ceilometer + Kibana + ElasticSearch Integration
+1 we have been researching on logstash+ es + kivana for openstack log, thinking how ceilometer can be intergrated with those. Great to here this! Although I have to think this integration more from now, for log aggregator, using logstash might be good idea here. I will keep following up on this. :) Jaesuk Ahn, Ph.D. Team Lead, Cloud Platform Dev. KT 2013. 9. 14. 오전 2:38에 "Nachi Ueno" 님이 작성: > Hi Folks > > Thank you for your feedback! > I'll continue this one > > (1) adding new storage driver > (2) adding extension for elastic search query in ceilometer. > (i'm still not sure how ceilometer supports extension framework yet) > > > Monsyne > Thank you for your information. I'll take a look that project. > > Best > Nachi > > > 2013/9/13 Monsyne Dragon : > > Nice! Have you chatted with these folks: http://projectmeniscus.org/ ? > > (Openstack-related logging-as-a-service project) > > They list interoperation with Ceilometer as a project goal. > > > > On 9/12/13 7:06 PM, "Nachi Ueno" wrote: > > > >>Hi Folks > >> > >>Is anyone interested in Kibana + ElasticSearch Integration with > >>ceilometer? > >># Note: This discussion is not for Havana. > >> > >>I have registered BP. (for IceHouse) > >>https://blueprints.launchpad.net/ceilometer/+spec/elasticsearch-driver > >> > >>This is demo video. > >>http://www.youtube.com/watch?v=8SmA0W0hd4I&feature=youtu.be > >> > >>I wrote some sample storage driver for elastic search in ceilometer. > >>This is WIP -> https://review.openstack.org/#/c/46383/ > >> > >>This integration sounds cool for me, because if we can integrate then, > >>we can use it as Log as a service. > >> > >>IMO, there are some discussion points. > >> > >>[1] We should add elastic search query api for ceilometer? or we > >>should let user kick ElasticSearch api directory? > >> > >>Note that ElasticSearch has no tenant based authentication, in that > >>case we need to integrate Keystone and ElasticSearch. (or Horizon) > >> > >>[2] Log (syslog or any application log) should be stored in > >>Ceilometer? (or it should be new OpenStack project? ) > >> > >>Best > >>Nachi > >> > >>___ > >>OpenStack-dev mailing list > >>OpenStack-dev@lists.openstack.org > >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
