[Openstack-operators] [openstack-dev][tacker] Unexpected files are created after installing Tacker
hi, tackers I have some questions about installing Tacker. I have an physical environment which installed Tacker a few days ago. Today I have pulled the latest code. Then I upgrade the database by using " tacker-db-manage --database-connection "mysql+pymysql:// root:12345@127.0.0.1/tacker?charset=utf8" upgrade head " At last I execute this command " python setup.py install ". I uploaded the output at [1]. But I met some issues about the files which were generated. There is directory named " tacker/db/vm " in the path " /usr/lib/python2.7/site-packages ". But this directory doesn't exist in the source code. In the [1], I found this command "creating /usr/lib/python2.7/site-packages/tacker/db/vm" . But the directory " tacker/db/vm " doesn't exist anymore. Because this wrong directory and files in this directory, tacker-server doesn't startup correctly. Could someone tell me the reason why this directory was generated? Thanks [1]. http://paste.openstack.org/show/586528/ ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [Large Deployments Team] Meeting Reminder - October 20, 2016 16:00 UTC
Hello LDT folks! Just a reminder that the monthly meeting is in a little over 3 hours. I apologize for the short notice. I’d like to discuss the upcoming summit, and what our plan is for the time that we have. See you all in #openstack-operators! Thanks! VW ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [puppet][tripleo][fuel] Upcoming changes to defaults around using processor count for worker configurations
Hey Sergii, On Thu, Oct 20, 2016 at 3:34 AM, Sergii Golovatiuk wrote: > Hi, > > > On Thu, Sep 29, 2016 at 11:57 PM, Alex Schultz wrote: >> >> Hello all, >> >> So for many years we've been using either the service defaults >> (usually python determined processor count) or the $processorcount >> fact from facter in puppet for worker configuration options for the >> OpenStack services. If you are currently using the default values >> provided by the puppet modules, you will be affected by this upcoming >> change. After much discussion and feedback from deployers, we've >> decided to change this to a default value that has a cap on it. This >> is primarily from the feedback when deploying on physical hardware >> where processor counts can be 32, 48 or even 512. These values can >> lead to excessive memory consumption or errors due to connection >> limits (mysql/rabbit). As such we've come up with a new fact to that >> will be used instead of $processorcount. >> >> The new fact is called $os_workers[0]. This fact uses the >> $processorcount to help weigh in on the number of workers to configure >> and won't be less than 2 but is capped at 8. The $os_workers fact >> will use the larger value of either '2' or '# of processors / 4' but >> will not exceed 8. The primary goal of this is to improve the user >> experience when people install services using the puppet modules and >> without having to tune all of these worker values. We plan on >> implementing this for all modules as part of the Ocata cycle. This >> work will can be tracked using the os_workers-fact[1] gerrit topic. >> It should be noted that we have implemented this fact in such a way >> that operators are free to override it using an external fact to >> provide their own values as well. If you are currently specifying >> your own values for the worker configurations in your manifests then >> this change will not affect you. If you have been relying on the >> defaults and wish to continue to use the $processorcount logic, we >> would recommend either implementing your own external fact[2] for this >> or updating your manifests to provide $::processorcount to the workers >> configuration. > > > This doesn't help a lot. I saw the case where 8 neutron-servers allocated > 6GB of RAM. From OOM perspective, the biggest process was MySQL (or Rabbit) > as it doesn't calculate the sum of processes. Instead of killing > neutron-server it killed MySQL to release some RAM to node. IMO, I would > focus on cgroup limitation for OpenStack services as that will allow the > operator to specify some the upper limit of CPU and RAM usage for every > service. > Yea this isn't a fix for excessive ram utilization of the services themselves. This primarily reduces the default consumption. I recently went to implement using this fact in tripleo[0] and it reduced the default memory utilization of the undercloud by a little over 1gig[1] in our CI runs. This was on a 4 cpu vhost so we basically halfed the number of running python processes by switching for the 17 different services that may run. So yea this isn't the end solution for dealing with excessive memory consumption but rather an improvement over the existing processor count usage. The primary target for this is really to prevent accidental blowing up of mysql connections when a host has large number of cpus but also reducing the overall number of processes by default. Thanks, -Alex [0] https://review.openstack.org/#/c/386696/ [1] http://people.redhat.com/~aschultz/os_workers.html >> >> As always we'd love to hear feedback on this and any other issues >> people might be facing. We're always available in #puppet-openstack on >> freenode or via the mailing lists. >> >> Thanks, >> -Alex >> >> >> [0] https://review.openstack.org/#/c/375146/ >> [1] https://review.openstack.org/#/q/topic:os_workers-fact >> [2] https://docs.puppet.com/facter/3.4/custom_facts.html#external-facts >> >> __ >> OpenStack Development Mailing 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] OpenContrail Users at the BCN Summit?
Hi All, Are there any OpenContrail users that will be at the summit next week? If so let me know because I'd like to talk to anyone who would be willing to chat with me about it. :) I searched the schedule a bit but didn't find anything obvious. Might have missed it. Thanks, Curtis. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] OpenContrail Users at the BCN Summit?
A few of our team members will be out at the summit next week. Meeting up to chat would be great. - matt On Thu, Oct 20, 2016 at 1:25 PM, Curtis wrote: > Hi All, > > Are there any OpenContrail users that will be at the summit next week? > If so let me know because I'd like to talk to anyone who would be > willing to chat with me about it. :) I searched the schedule a bit but > didn't find anything obvious. Might have missed it. > > Thanks, > Curtis. > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] 2017 Openstack Operators Mid-Cycle Meetups - venue selection etherpads
Hello Everyone, Here are etherpads for the collection of venue hosting proposals and assessment: https://etherpad.openstack.org/p/ops-meetup-venue-discuss-spring-2017 https://etherpad.openstack.org/p/ops-meetup-venue-discuss-aug-2017 For your reference, the previous etherpad (for august 2016 was eventually was decided to be in NYC) was : https://etherpad.openstack.org/p/ops-meetup-venue-discuss -- Chris Morgan ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Participate in a Usability Study at Barcelona: Get a free bluetooth speaker and OpenStack t-shirt for your time
Apologies for any cross-postings. Hi Folks, I wanted to send a second notice that there will be two usability studies being conducted in Barcelona with cloud operators. We had nearly a 100% show rate last summit and the results had a direct impact on the OpenStackClient. In fact, the results were shared at the OSC working session the next day. Intel is providing a Philips bluetooth speaker to show our appreciation for your time. In addition, the foundation is providing a t-shirt to each person that participates in the study. I may even give anyone suffering from jetlag a Red Bull to get them through the day. ___ The first study will be on Monday, October 24th and is intended to investigate the current APIs to understand any specific pain points associated with completing tasks that span projects such as quotas. This study will last 45 minutes per operator. You can schedule a time here: http://doodle.com/poll/fwfi2sfcuctxv3u8 Note that you may need to set the time zone in Doodle to Spain > Ceuta ___ The second study will be on Tuesday, October 25th and is intended to investigate the OpenStackClient to understand any specific pain points and opportunities associated with completing tasks with the client. This study will last 45 minutes per operator. We ran a similar study at the previous summit and the feedback from users was that it was a good opportunity to “test drive” the client with an OSC expert in the room with them. You can schedule a time here: http://doodle.com/poll/894aqsmheaa2mv5a Note that you may need to set the time zone in Doodle to Spain > Ceuta For both studies, someone with the OpenStack UX project will send you a calendar invite after you select a time(s) that are convenient for you. Thanks, Piet Kruithof PTL OpenStack UX ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] What do customers want?: Six studies conducted by the OpenStack UX project on behalf of the community
Hi Folks, The OpenStack UX project and Intel have produced three booklets for the Barcelona OpenStack Summit based on the OpenStack UX’s work over the past six months. The first is an overview of user research that was conducted on behalf of the OpenStack community including operator information needs, novice user experience for Horizon, OpenStackClient (OSC) validation and managing quotas at scale. https://drive.google.com/file/d/0B8h-c0zHxYBoXzFMQWJsY09Eclk/view?usp=sharing The second booklets include the OpenStack Personas and GUI Guidelines: OpenStack Personas: https://drive.google.com/file/d/0B8h-c0zHxYBoMXB4UVgtdFFsaDQ/view?usp=sharing OpenStack GUI Guidelines: https://drive.google.com/file/d/0B8h-c0zHxYBoV0tHV1l5bVpZZzg/view?usp=sharing ___ Unfortunately, we were unable to include the results for the searchlight/horizon integration as well as cloud architect information needs. However, the presentations are posted to the OpenStack UX YouTube channel. https://www.youtube.com/channel/UCt6h129lzcjUqLDY005aCxw The channel is updated regularly, so it may be worth checking from time to time. ___ For extra credit, my suggestion would be to read the “State of OpenStack User Experience October 2016” which provides a succinct overview of the research that was conducted, why it matters, results, and recommendations. https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv8-tDIQCSingu7zqSMbKFZ_Y/edit?usp=sharing Thanks, Piet Kruithof PTL OpenStack UX project ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
