Re: [openstack-dev] [sahara] Asia friendly IRC meeting time
+1 on alternative meeting times. Maybe we can come up with some candidates and put for vote on doodle? cf. Oslo meeting time vote page: http://doodle.com/zv8izg7ymxcank34 -zhongyue On Tue, Nov 25, 2014 at 3:37 PM, Zhidong Yu zdyu2...@gmail.com wrote: Hi All, I'd like to propose a time change to the weekly IRC meeting to make it more convenient for people from Asia to attend. As you might be aware, we here at Intel in China have a few people started working on Sahara actively since Juno release. I also noticed that there are contributions from NTT Japan as well. So I think an Asia-friendly time could allow us to participate in the community more efficiently and may potentially attract more contributors from Asia. I know it's difficult to find a time good for both US, Europe and Asia. I suggest we could have two different meeting series with different time, i.e. US/Europe meeting this week, US/Asia meeting next week, and so on. Current meeting time: 18:00UTC: Moscow (9pm)China(2am) US West(10am) My proposal: 18:00UTC: Moscow (9pm)China(2am) US West(10am) 00:00UTC: Moscow (3am)China(8am) US West(4pm) Thanks, Zhidong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STO/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Proposing new meeting times
+1 for Option #2 On Tue, Nov 18, 2014 at 5:56 PM, Lucas Alvares Gomes lucasago...@gmail.com wrote: On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen devananda@gmail.com wrote: Hi all, As discussed in Paris and at today's IRC meeting [1] we are going to be alternating the time of the weekly IRC meetings to accommodate our contributors in EMEA better. No time will be perfect for everyone, but as it stands, we rarely (if ever) see our Indian, Chinese, and Japanese contributors -- and it's quite hard for any of the AU / NZ folks to attend. I'm proposing two sets of times below. Please respond with a -1 vote to an option if that option would cause you to miss ALL meetings, or a +1 vote if you can magically attend ALL the meetings. If you can attend, without significant disruption, at least one of the time slots in a proposal, please do not vote either for or against it. This way we can identify a proposal which allows everyone to attend at a minimum 50% of the meetings, and preferentially weight towards one that allows more contributors to attend two meetings. This link shows the local times in some major coutries / timezones around the world (and you can customize it to add your own). http://www.timeanddate.com/worldclock/meetingtime.html?iso=20141125p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 For reference, the current meeting time is 1900 UTC. Option #1: alternate between Monday 1900 UTC Tuesday 0900 UTC. I like this because 1900 UTC spans all of US and western EU, while 0900 combines EU and EMEA. Folks in western EU are in the middle and can attend all meetings. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=19min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=25hour=9min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 +1 Option #2: alternate between Monday 1700 UTC Tuesday 0500 UTC. I like this because it shifts the current slot two hours earlier, making it easier for eastern EU to attend without excluding the western US, and while 0500 UTC is not so late that US west coast contributors can't attend (it's 9PM for us), it is harder for western EU folks to attend. There's really no one in the middle here, but there is at least a chance for US west coast and EMEA to overlap, which we don't have at any other time. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=17min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 I'll collate all the responses to this thread during the week, ahead of next week's regularly-scheduled meeting. -Devananda [1] http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-11-17-19.00.log.html ___ 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 -- *Intel SSG/STO/BDT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] adding James Carey to oslo-i18n-core
+1 On Sat, Sep 27, 2014 at 8:31 AM, Jay S. Bryant jsbry...@electronicjungle.net wrote: On 09/26/2014 06:46 PM, Matt Riedemann wrote: On 9/25/2014 11:04 AM, Ben Nemec wrote: +1. He's on the short list of people who actually understand how all that lazy translation stuff works. :-) -Ben On 09/23/2014 04:03 PM, Doug Hellmann wrote: James Carey (jecarey) from IBM has done the 3rd most reviews of oslo.i18n this cycle [1]. His feedback has been useful, and I think he would be a good addition to the team for maintaining oslo.i18n. Let me know what you think, please. Doug [1] http://stackalytics.com/?module=oslo.i18n ___ 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 I'm not part of the core team but agree with Ben here. Jim is my go-to guy on the i18n stuff, which I'm sure delights him whenever I have issues. :) I second Matt's note! I hadn't voted since I am not a core member. Jim was my partner in crime on the i18n stuff in Icehouse and has done a lot of good work in Juno. I am so thankful for his knowledge and help! So, a big +2 from me. :-) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STO/CBE* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo-vmware] Propose adding Radoslav to core team
+1 On Tue, Sep 16, 2014 at 1:56 AM, Sabari Murugesan smuruge...@vmware.com wrote: +1 On Sep 15, 2014, at 10:18 AM, Arnaud Legendre wrote: +1 On Sep 15, 2014, at 9:37 AM, Gary Kotton gkot...@vmware.com wrote: Hi, I would like to propose Radoslav to be a core team member. Over the course of the J cycle he has been great with the reviews, bug fixes and updates to the project. Can the other core team members please update with your votes if you agree or not. Thanks Gary ___ 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 -- *Intel SSG/STO/CBE* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra] How to solve the cgit repository browser line number misalignment in Chrome
Thanks! Will submit a patch. On Thu, Apr 10, 2014 at 8:08 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: That looks like it. Thanks, Josh! On Wed, Apr 9, 2014 at 7:08 PM, Joshua Hesketh joshua.hesk...@rackspace.com wrote: Hey, I suspect you're looking for this : http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/git/openstack.css Hope that helps! Cheers, Josh From: Doug Hellmann [doug.hellm...@dreamhost.com] Sent: Thursday, April 10, 2014 12:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Infra] How to solve the cgit repository browser line number misalignment in Chrome I don't, but someone on the infra team (#openstack-infra) should be able to tell you where the theme is maintained. Doug On Tue, Apr 8, 2014 at 7:26 PM, Zhongyue Luo zhongyue@intel.com wrote: Do you happen to know where the repo for cgit is? I'll submit a patch adding font and font size. On Apr 8, 2014 10:24 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Maybe those changes should be added to our cgit stylesheet? Doug On Mon, Apr 7, 2014 at 9:23 PM, Zhongyue Luo zhongyue@intel.com wrote: Hi, I know I'm not the only person who had this problem so here's two simple steps to get the lines and line numbers aligned. 1. Install the stylebot extension https://chrome.google.com/extensions/detail/oiaejidbmkiecgbjeifoejpgmdaleoha 2. Click on the download icon to install the custom style for git.openstack.org http://stylebot.me/styles/5369 Thanks! -- Intel SSG/STO/DCST/CBE 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ 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 ___ 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 -- *Intel SSG/STO/DCST/CBE* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra] How to solve the cgit repository browser line number misalignment in Chrome
Apparently the patch needs to be submitted to cgit. http://git.zx2c4.com/cgit/tree/cgit.css#n277 On Thu, Apr 10, 2014 at 8:08 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: That looks like it. Thanks, Josh! On Wed, Apr 9, 2014 at 7:08 PM, Joshua Hesketh joshua.hesk...@rackspace.com wrote: Hey, I suspect you're looking for this : http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/git/openstack.css Hope that helps! Cheers, Josh From: Doug Hellmann [doug.hellm...@dreamhost.com] Sent: Thursday, April 10, 2014 12:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Infra] How to solve the cgit repository browser line number misalignment in Chrome I don't, but someone on the infra team (#openstack-infra) should be able to tell you where the theme is maintained. Doug On Tue, Apr 8, 2014 at 7:26 PM, Zhongyue Luo zhongyue@intel.com wrote: Do you happen to know where the repo for cgit is? I'll submit a patch adding font and font size. On Apr 8, 2014 10:24 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Maybe those changes should be added to our cgit stylesheet? Doug On Mon, Apr 7, 2014 at 9:23 PM, Zhongyue Luo zhongyue@intel.com wrote: Hi, I know I'm not the only person who had this problem so here's two simple steps to get the lines and line numbers aligned. 1. Install the stylebot extension https://chrome.google.com/extensions/detail/oiaejidbmkiecgbjeifoejpgmdaleoha 2. Click on the download icon to install the custom style for git.openstack.org http://stylebot.me/styles/5369 Thanks! -- Intel SSG/STO/DCST/CBE 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ 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 ___ 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 -- *Intel SSG/STO/DCST/CBE* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra] How to solve the cgit repository browser line number misalignment in Chrome
Hi, Ignore my last comment. Patch submitted. https://review.openstack.org/#/c/86495 On Thu, Apr 10, 2014 at 8:08 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: That looks like it. Thanks, Josh! On Wed, Apr 9, 2014 at 7:08 PM, Joshua Hesketh joshua.hesk...@rackspace.com wrote: Hey, I suspect you're looking for this : http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/git/openstack.css Hope that helps! Cheers, Josh From: Doug Hellmann [doug.hellm...@dreamhost.com] Sent: Thursday, April 10, 2014 12:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Infra] How to solve the cgit repository browser line number misalignment in Chrome I don't, but someone on the infra team (#openstack-infra) should be able to tell you where the theme is maintained. Doug On Tue, Apr 8, 2014 at 7:26 PM, Zhongyue Luo zhongyue@intel.com wrote: Do you happen to know where the repo for cgit is? I'll submit a patch adding font and font size. On Apr 8, 2014 10:24 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Maybe those changes should be added to our cgit stylesheet? Doug On Mon, Apr 7, 2014 at 9:23 PM, Zhongyue Luo zhongyue@intel.com wrote: Hi, I know I'm not the only person who had this problem so here's two simple steps to get the lines and line numbers aligned. 1. Install the stylebot extension https://chrome.google.com/extensions/detail/oiaejidbmkiecgbjeifoejpgmdaleoha 2. Click on the download icon to install the custom style for git.openstack.org http://stylebot.me/styles/5369 Thanks! -- Intel SSG/STO/DCST/CBE 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ 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 ___ 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 -- *Intel SSG/STO/DCST/CBE* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra] How to solve the cgit repository browser line number misalignment in Chrome
Do you happen to know where the repo for cgit is? I'll submit a patch adding font and font size. On Apr 8, 2014 10:24 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Maybe those changes should be added to our cgit stylesheet? Doug On Mon, Apr 7, 2014 at 9:23 PM, Zhongyue Luo zhongyue@intel.com wrote: Hi, I know I'm not the only person who had this problem so here's two simple steps to get the lines and line numbers aligned. 1. Install the stylebot extension https://chrome.google.com/extensions/detail/oiaejidbmkiecgbjeifoejpgmdaleoha 2. Click on the download icon to install the custom style for git.openstack.org http://stylebot.me/styles/5369 Thanks! -- Intel SSG/STO/DCST/CBE 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ 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] [Infra] How to solve the cgit repository browser line number misalignment in Chrome
Hi, I know I'm not the only person who had this problem so here's two simple steps to get the lines and line numbers aligned. 1. Install the stylebot extension https://chrome.google.com/extensions/detail/oiaejidbmkiecgbjeifoejpgmdaleoha 2. Click on the download icon to install the custom style for git.openstack.org http://stylebot.me/styles/5369 Thanks! -- *Intel SSG/STO/DCST/CBE* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][baremetal] Status of nova baremetal and ironic
Hi, If I were to implement a new BM driver then should I propose a BP to Ironic rather than Nova? We are currently writing a driver internally using nova-baremetal. My understanding is that nova-baremetal will only merge critical bug fixes and new features will merge to Ironic, correct? Thanks. On Sat, Feb 8, 2014 at 1:37 AM, Chris K nobody...@gmail.com wrote: Hi Taurus, You are correct Ironic is under rapid development right now, there are several patches in flight right now critical to Ironic. There have been successful tests using Ironic to boot both vm's and real hardware, but at this time I would say we are just about out of alpha and entering bata stages. Ironic's Goal is to graduate from incubation in the Icehouse cycle, and start integration in the J cycle. We are working on a migration path from Nova-bm to Ironic as part of this graduation. With out knowing what environment you are using Nova-bm it is very difficult to say when you should look at switching, but off the top of my head I would say: Look at evaluating after the Icehouse release. I would include with that Check back often, things are changing quickly. Chris Krelle NobodyCam On Fri, Feb 7, 2014 at 1:58 AM, Taurus Cheung taurus.che...@harmonicinc.com wrote: I am working on deploying images to bare-metal machines using nova bare-metal. So far working well. I know Ironic is under rapid development. Could I know the current status of Ironic and the suitable time to shift from nova baremetal to Ironic? Regards, Taurus ___ 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 -- *Intel SSG/STO/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Avoiding dhcp port loss using conductors
Hi folks, I having working on enhancing the base performance of Neutron using ML2 OVS during my free cycles for the past few weeks. The current bottleneck in Neutron is, as we all know, the part when a neutron agent requests security_group_rules_for_devices to the server in order to update its port's SG rules. This operation takes an average 24secs according to my observation and it is also the main cause of some VMs not able to receive DHCP responses in severe conditions. To enhance the throughput performance of VM provisioning with Neutron, I've created a neutron-conductor service which currently only handles security_group_rules_for_devices requests. Though it is yet in prototype status, it works great in my devstack env and in the OpenStack deployment in our lab. In my all-in-one devstack env with 4cores and 8G mem, I was able to provision 50 nano flavor VMs without any network failures. In the lab deployment, which has 16 compute nodes, I was able to provision 500 tiny flavor VMs with 8sec interval between every nova boot. All of which successfully obtained fixed IPs. I've pushed my devstack patch which launches the neutron conductor service to my github account: https://github.com/zyluo/devstack/tree/havana_neutron_conductor_sg_only The patch for the neutron-conductor is located at: https://github.com/zyluo/neutron/tree/havana_conductor_sg_only If you are interested, feel free to try this on your devstack env. Instructions are in the commit message: https://github.com/zyluo/devstack/commit/07382fa11ec9049b5e732390aca67d4bc9a7443b I've only tested on CentOS 6.4 using ML2 OVS. Any feedback would be appreciated. Thanks! -- *Intel SSG/STO/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal to move from Freenode to OFTC
FYI http://www.oftc.net/Services/#register-your-account On Tue, Mar 4, 2014 at 8:32 AM, James E. Blair jebl...@openstack.orgwrote: Sean Dague s...@dague.net writes: [I don't have anything substantial to add to q1 right now, though it's a good one.] #2) how bad do we believe nick contention might be in this transition? We've got 1000+ people that have well known nicks on freenode, that might hit conflicts on oftc. Now might be a good time to go register your nick (and your casual Friday nick as well) and see. OFTC has a similar policy to Freenode around releasing nicks that have not been used in years, and the operators in #oftc have been responsive to such requests. That way, if this is a problem, we might find out early. #3) while for IRC veterans this is a simple matter of changing a config in your IRC proxy, we have been training new folks for a long time (and all through our wiki and documentation) that Freenode is our place. That might have required some of these folks to get firewall rules for freenode created. What kind of timeline are you thinking about for the cutover to hopefully catch all these folks? Good point (though with Freenode's constant server rotation, I wonder how many folks actually have IP-based firewall rules [as opposed to just a port rule which should work for OFTC as well]). I was thinking about a month, for starters. That gives us plenty of time for notice, and early April puts us in the RC phase but not too close to the release. If we decide to proceed but feel this isn't enough time for this or other issues, we should probably push it to early May (the off week after the release). -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STO/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py
Just a thought but couldn't the changes of a module update be calculated by comparing the last commit dates of the source and target module? For instance, if module A's update patch for Nova was uploaded on date XX then we can filter out the changes from XX~present and print it out for the author to paste in the commit message when running update.py for module A. This way we might not need any changes to the openstack-modules.conf? On Sun, Nov 24, 2013 at 12:54 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Thanks for the reminder, Sandy. https://bugs.launchpad.net/oslo/+bug/1254300 On Sat, Nov 23, 2013 at 9:39 AM, Sandy Walsh sandy.wa...@rackspace.comwrote: Seeing this thread reminded me: We need support in the update script for entry points in olso setup.cfg to make their way into the target project. So, if update is getting some love, please keep that in mind. ___ 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 -- *Intel SSG/STO/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] The three API server multi-worker process patches.
Thanks, I'll give it a try. On Fri, Nov 22, 2013 at 2:35 AM, Carl Baldwin c...@ecbaldwin.net wrote: Hello, Please tell me if your experience is similar to what I experienced: 1. I would see *at most one* MySQL server has gone away error for each process that was spawned as an API worker. I saw them within a minute of spawning the workers and then I did not see these errors anymore until I restarted the server and spawned new processes. 2. I noted in patch set 7 the line of code that completely fixed this for me. Please confirm that you have applied a patch that includes this fix. https://review.openstack.org/#/c/37131/7/neutron/wsgi.py 3. I did not change anything with pool_recycle or idle_interval in my config files. All I did was set api_workers to the number of workers that I wanted to spawn. The line of code with my comment in it above was sufficient for me. It could be that there is another cause for the errors that you're seeing. For example, is there a max connections setting in mysql that might be exceeded when you spawn multiple workers? More detail would be helpful. Cheers, Carl On Wed, Nov 20, 2013 at 7:40 PM, Zhongyue Luo zhongyue@intel.com wrote: Carl, By 2006 I mean the MySQL server has gong away error code. The error message was still appearing when idle_timeout is set to 1 and the quantum API server did not work in my case. Could you perhaps share your conf file when applying this patch? Thanks. On Thu, Nov 21, 2013 at 3:34 AM, Carl Baldwin c...@ecbaldwin.net wrote: Hi, sorry for the delay in response. I'm glad to look at it. Can you be more specific about the error? Maybe paste the error your seeing in paste.openstack.org? I don't find any reference to 2006. Maybe I'm missing something. Also, is the patch that you applied the most recent? With the final version of the patch it was no longer necessary for me to set pool_recycle or idle_interval. Thanks, Carl On Tue, Nov 19, 2013 at 7:14 PM, Zhongyue Luo zhongyue@intel.com wrote: Carl, Yingjun, I'm still getting the 2006 error even by configuring idle_interval to 1. I applied the patch to the RDO havana dist on centos 6.4. Are there any other options I should be considering such as min/max pool size or use_tpool? Thanks. On Sat, Sep 7, 2013 at 3:33 AM, Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com wrote: This pool_recycle parameter is already configurable using the idle_timeout configuration variable in neutron.conf. I tested this with a value of 1 as suggested and it did get rid of the mysql server gone away messages. This is a great clue but I think I would like a long-term solution that allows the end-user to still configure this like they were before. I'm currently thinking along the lines of calling something like pool.dispose() in each child immediately after it is spawned. I think this should invalidate all of the existing connections so that when a connection is checked out of the pool a new one will be created fresh. Thoughts? I'll be testing. Hopefully, I'll have a fixed patch up soon. Cheers, Carl From: Yingjun Li liyingjun1...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: Thursday, September 5, 2013 8:28 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] The three API server multi-worker process patches. +1 for Carl's patch, and i have abandoned my patch.. About the `MySQL server gone away` problem, I fixed it by set 'pool_recycle' to 1 in db/api.py. 在 2013年9月6日星期五，Nachi Ueno 写道： Hi Folks We choose https://review.openstack.org/#/c/37131/ -- This patch to go on. We are also discussing in this patch. Best Nachi 2013/9/5 Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com: Brian, As far as I know, no consensus was reached. A problem was discovered that happens when spawning multiple processes. The mysql connection seems to go away after between 10-60 seconds in my testing causing a seemingly random API call to fail. After that, it is okay. This must be due to some interaction between forking the process and the mysql connection pool. This needs to be solved but I haven't had the time to look in to it this week. I'm not sure if the other proposal suffers from this problem. Carl On 9/4/13 3:34 PM, Brian Cline bcl...@softlayer.com wrote: Was any consensus on this ever reached? It appears both reviews are still open. I'm partial to review 37131 as it attacks the problem a more concisely, and, as mentioned, combined the efforts of the two more effective patches. I would echo Carl's
Re: [openstack-dev] [Neutron] The three API server multi-worker process patches.
Carl, By 2006 I mean the MySQL server has gong away error code. The error message was still appearing when idle_timeout is set to 1 and the quantum API server did not work in my case. Could you perhaps share your conf file when applying this patch? Thanks. On Thu, Nov 21, 2013 at 3:34 AM, Carl Baldwin c...@ecbaldwin.net wrote: Hi, sorry for the delay in response. I'm glad to look at it. Can you be more specific about the error? Maybe paste the error your seeing in paste.openstack.org? I don't find any reference to 2006. Maybe I'm missing something. Also, is the patch that you applied the most recent? With the final version of the patch it was no longer necessary for me to set pool_recycle or idle_interval. Thanks, Carl On Tue, Nov 19, 2013 at 7:14 PM, Zhongyue Luo zhongyue@intel.com wrote: Carl, Yingjun, I'm still getting the 2006 error even by configuring idle_interval to 1. I applied the patch to the RDO havana dist on centos 6.4. Are there any other options I should be considering such as min/max pool size or use_tpool? Thanks. On Sat, Sep 7, 2013 at 3:33 AM, Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com wrote: This pool_recycle parameter is already configurable using the idle_timeout configuration variable in neutron.conf. I tested this with a value of 1 as suggested and it did get rid of the mysql server gone away messages. This is a great clue but I think I would like a long-term solution that allows the end-user to still configure this like they were before. I'm currently thinking along the lines of calling something like pool.dispose() in each child immediately after it is spawned. I think this should invalidate all of the existing connections so that when a connection is checked out of the pool a new one will be created fresh. Thoughts? I'll be testing. Hopefully, I'll have a fixed patch up soon. Cheers, Carl From: Yingjun Li liyingjun1...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: Thursday, September 5, 2013 8:28 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] The three API server multi-worker process patches. +1 for Carl's patch, and i have abandoned my patch.. About the `MySQL server gone away` problem, I fixed it by set 'pool_recycle' to 1 in db/api.py. 在 2013年9月6日星期五，Nachi Ueno 写道： Hi Folks We choose https://review.openstack.org/#/c/37131/ -- This patch to go on. We are also discussing in this patch. Best Nachi 2013/9/5 Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com: Brian, As far as I know, no consensus was reached. A problem was discovered that happens when spawning multiple processes. The mysql connection seems to go away after between 10-60 seconds in my testing causing a seemingly random API call to fail. After that, it is okay. This must be due to some interaction between forking the process and the mysql connection pool. This needs to be solved but I haven't had the time to look in to it this week. I'm not sure if the other proposal suffers from this problem. Carl On 9/4/13 3:34 PM, Brian Cline bcl...@softlayer.com wrote: Was any consensus on this ever reached? It appears both reviews are still open. I'm partial to review 37131 as it attacks the problem a more concisely, and, as mentioned, combined the efforts of the two more effective patches. I would echo Carl's sentiments that it's an easy review minus the few minor behaviors discussed on the review thread today. We feel very strongly about these making it into Havana -- being confined to a single neutron-server instance per cluster or region is a huge bottleneck--essentially the only controller process with massive CPU churn in environments with constant instance churn, or sudden large batches of new instance requests. In Grizzly, this behavior caused addresses not to be issued to some instances during boot, due to quantum-server thinking the DHCP agents timed out and were no longer available, when in reality they were just backlogged (waiting on quantum-server, it seemed). Is it realistically looking like this patch will be cut for h3? -- Brian Cline Software Engineer III, Product Innovation SoftLayer, an IBM Company 4849 Alpha Rd, Dallas, TX 75244 214.782.7876 direct | bcl...@softlayer.com -Original Message- From: Baldwin, Carl (HPCS Neutron) [mailto:carl.bald...@hp.com] Sent: Wednesday, August 28, 2013 3:04 PM To: Mark McClain Cc: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] The three API server multi-worker process patches. All, We've known for a while now that some duplication of work happened with respect to adding multiple worker processes
Re: [openstack-dev] [Neutron] The three API server multi-worker process patches.
Carl, Yingjun, I'm still getting the 2006 error even by configuring idle_interval to 1. I applied the patch to the RDO havana dist on centos 6.4. Are there any other options I should be considering such as min/max pool size or use_tpool? Thanks. On Sat, Sep 7, 2013 at 3:33 AM, Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com wrote: This pool_recycle parameter is already configurable using the idle_timeout configuration variable in neutron.conf. I tested this with a value of 1 as suggested and it did get rid of the mysql server gone away messages. This is a great clue but I think I would like a long-term solution that allows the end-user to still configure this like they were before. I'm currently thinking along the lines of calling something like pool.dispose() in each child immediately after it is spawned. I think this should invalidate all of the existing connections so that when a connection is checked out of the pool a new one will be created fresh. Thoughts? I'll be testing. Hopefully, I'll have a fixed patch up soon. Cheers, Carl From: Yingjun Li liyingjun1...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: Thursday, September 5, 2013 8:28 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] The three API server multi-worker process patches. +1 for Carl's patch, and i have abandoned my patch.. About the `MySQL server gone away` problem, I fixed it by set 'pool_recycle' to 1 in db/api.py. 在 2013年9月6日星期五，Nachi Ueno 写道： Hi Folks We choose https://review.openstack.org/#/c/37131/ -- This patch to go on. We are also discussing in this patch. Best Nachi 2013/9/5 Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com: Brian, As far as I know, no consensus was reached. A problem was discovered that happens when spawning multiple processes. The mysql connection seems to go away after between 10-60 seconds in my testing causing a seemingly random API call to fail. After that, it is okay. This must be due to some interaction between forking the process and the mysql connection pool. This needs to be solved but I haven't had the time to look in to it this week. I'm not sure if the other proposal suffers from this problem. Carl On 9/4/13 3:34 PM, Brian Cline bcl...@softlayer.com wrote: Was any consensus on this ever reached? It appears both reviews are still open. I'm partial to review 37131 as it attacks the problem a more concisely, and, as mentioned, combined the efforts of the two more effective patches. I would echo Carl's sentiments that it's an easy review minus the few minor behaviors discussed on the review thread today. We feel very strongly about these making it into Havana -- being confined to a single neutron-server instance per cluster or region is a huge bottleneck--essentially the only controller process with massive CPU churn in environments with constant instance churn, or sudden large batches of new instance requests. In Grizzly, this behavior caused addresses not to be issued to some instances during boot, due to quantum-server thinking the DHCP agents timed out and were no longer available, when in reality they were just backlogged (waiting on quantum-server, it seemed). Is it realistically looking like this patch will be cut for h3? -- Brian Cline Software Engineer III, Product Innovation SoftLayer, an IBM Company 4849 Alpha Rd, Dallas, TX 75244 214.782.7876 direct | bcl...@softlayer.com -Original Message- From: Baldwin, Carl (HPCS Neutron) [mailto:carl.bald...@hp.com] Sent: Wednesday, August 28, 2013 3:04 PM To: Mark McClain Cc: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] The three API server multi-worker process patches. All, We've known for a while now that some duplication of work happened with respect to adding multiple worker processes to the neutron-server. There were a few mistakes made which led to three patches being done independently of each other. Can we settle on one and accept it? I have changed my patch at the suggestion of one of the other 2 authors, Peter Feiner, in attempt to find common ground. It now uses openstack common code and therefore it is more concise than any of the original three and should be pretty easy to review. I'll admit to some bias toward my own implementation but most importantly, I would like for one of these implementations to land and start seeing broad usage in the community earlier than later. Carl Baldwin PS Here are the two remaining patches. The third has been abandoned. https://review.openstack.org/#/c/37131/ https://review.openstack.org/#/c/36487/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Revisiting current column number limit in code
This would be a nightmare to some people who work with xwindows disabled by default. Not to mention going through code via console on a server. On Oct 30, 2013 4:53 PM, Roman Prykhodchenko rprikhodche...@mirantis.com wrote: Hi there, Limiting the lines to 80 symbols makes viewing/editing/comparing two files on a single screen quite comfortable. This is not only useful for Vimers who do not use graphical IDEs but also makes debugging/troubleshooting easier when someone has a development/preproduction server(s) where you cannot basically use any IDE. If a line of code is complex enough to not fit 80 symbols I'd suggest simplifying the algorithm. Btw, some of displays can be turned for 90˚ so this might be a way to go with graphical IDEs :) - Roman On Oct 30, 2013, at 10:24 , Victor Sergeyev vserge...@mirantis.com wrote: By the way, pep8 says, that it is okay to increase the nominal line length from 80 to 100 characters. See http://www.python.org/dev/peps/pep-0008/#maximum-line-length I'm ok with 80 characters, but just for information - is there any plans to to increase the line length in OpenStack? Victor On Wed, Oct 30, 2013 at 8:52 AM, Aaron Rosen aro...@nicira.com wrote: Here's what mine usually looks like :) http://www.python.org/dev/peps/pep-0008/#maximum-line-length On Tue, Oct 29, 2013 at 11:19 PM, Ravi Kumar Pasumarthy ravi...@thoughtworks.com wrote: Hello, Looks like the current column limit for the code base is 80. Because of this large space on the right hand side is not used. Please find the attached pictures of couple of developer screens working on openstack codebase. Are there any thoughts to increase the current column limit to 120 atleast. How does this help ? I can see more lines of code, it is easier on the eyes. Some external monitors supports rotation, but for laptops we cannot rotate. So is it possible to revisit the column number limit ? Thanks, Ravi Kumar Pasumarthy Lead Consultant ThoughtWorks ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] unable to run tox due to the '--pre' argument
Looks like this problem happens in systems that use pip1.4 but upgraded tox to 1.6.1 http://tox.readthedocs.org/en/latest/config.html#confval-install_command=ARGV On Fri, Sep 20, 2013 at 12:47 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2013-09-19 09:24:08 +0800 (+0800), Yongsheng Gong wrote: [...] I upgrade the pip into 1.4.1: gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$ .tox/py27/bin/pip install -U pip gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$ .tox/py27/bin/pip --version pip 1.4.1 from /mnt/data/opt/stack/python-neutronclient/.tox/py27 /lib/python2.7/site-packages (python 2.7) [...] Then I run tox -e py27 and it failed: [...] I check the pip version in .tox: gongysh@gongysh-ThinkPad-T530:/mnt/data/opt/stack/ python-neutronclient$ .tox/py27/bin/pip --version pip 1.3.1 from /mnt/data/opt/stack/python-neutronclient/.tox/py27 /lib/python2.7/site-packages/pip-1.3.1-py2.7.egg (python 2.7) It is changed back!!! I've tried to reproduce this and it doesn't seem to happen for me. Using tox 1.6.1 to run 'tox -e py27' in a current checkout of python-neutronclient's master branch automatically installs pip 1.4.1 in the virtualenv it creates. Can you try this on another machine/vm just for confirmation? Clark also suggested on IRC just now that maybe you have some global tox configuration specifying to always recreate the virtualenv (essentially -r) and that its populating it with your system-installed version or perhaps an older cached download. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] Program name and Mission statement
Why not OpenStack MapReduce? I think that pretty much says it all? On Wed, Sep 11, 2013 at 3:54 AM, Glen Campbell g...@glenc.io wrote: performant isn't a word. Or, if it is, it means having performance. I think you mean high-performance. On Tue, Sep 10, 2013 at 8:47 AM, Matthew Farrellee m...@redhat.comwrote: Rough cut - Program: OpenStack Data Processing Mission: To provide the OpenStack community with an open, cutting edge, performant and scalable data processing stack and associated management interfaces. On 09/10/2013 09:26 AM, Sergey Lukjanov wrote: It sounds too broad IMO. Looks like we need to define Mission Statement first. Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. On Sep 10, 2013, at 17:09, Alexander Kuznetsov akuznet...@mirantis.com mailto:akuznetsov@mirantis.**com akuznet...@mirantis.com wrote: My suggestion OpenStack Data Processing. On Tue, Sep 10, 2013 at 4:15 PM, Sergey Lukjanov slukja...@mirantis.com mailto:slukja...@mirantis.com** wrote: Hi folks, due to the Incubator Application we should prepare Program name and Mission statement for Savanna, so, I want to start mailing thread about it. Please, provide any ideas here. P.S. List of existing programs: https://wiki.openstack.org/**wiki/Programshttps://wiki.openstack.org/wiki/Programs P.P.S. https://wiki.openstack.org/**wiki/Governance/NewProgramshttps://wiki.openstack.org/wiki/Governance/NewPrograms Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**orgOpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.**openstack.orgOpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/** openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.**openstack.orgOpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Glen Campbell* http://glenc.io • @glenc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] sample configuration file
This issue was first raised here, https://review.openstack.org/#/c/38333/ Some of us are trying to find a work-around solution but apparently things aren't as simple as they seem. On Tue, Sep 3, 2013 at 5:19 AM, Gary Kotton gkot...@vmware.com wrote: Hi, Whilst reviewing the olso messaging (my poor browser with all of the open tabs) it has come to my attention that the nova sample configuration file no longer has the RPC message configuration values. The common CFG values are also no longer in the file. I think that this is a bug and would like to know what others think. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] generate_sample.sh
Some how the total option count changed in your patch to 614 when it should be the same. How about re-runing generate_sample.sh. On Sat, Jul 20, 2013 at 10:05 AM, Matt Riedemann mrie...@us.ibm.com wrote: Looks like it's complaining because you changed nova.conf.sample. Based on the readme: *https://github.com/openstack/nova/tree/master/tools/conf*https://github.com/openstack/nova/tree/master/tools/conf Did you running ./tools/conf/analyze_opts.py? I'm assuming you need to run the tools and if there are issues you have to resolve them before pushing up your changes. I've personally never ran this though. Thanks, *MATT RIEDEMANN* Advisory Software Engineer Cloud Solutions and OpenStack Development -- *Phone:* 1-507-253-7622 | *Mobile:* 1-507-990-1889* E-mail:* *mrie...@us.ibm.com* mrie...@us.ibm.com [image: IBM] 3605 Hwy 52 N Rochester, MN 55901-1407 United States From:Gary Kotton gkot...@vmware.com To:OpenStack Development Mailing List ( openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.org, Date:07/19/2013 07:03 PM Subject:[openstack-dev] [nova] generate_sample.sh -- Hi, I have run into a problem with pep8 for * https://review.openstack.org/#/c/37539/*https://review.openstack.org/#/c/37539/. The issue is that have run the script in the subject and the pep8 fails. Any ideas? Thanks Gary___ 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 -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 image/gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] common codes
Gareth, https://wiki.openstack.org/wiki/Oslo#Principles I believe this link will answer most of your answers. On Tue, Jul 16, 2013 at 11:16 AM, Gareth academicgar...@gmail.com wrote: Michael, thanks for your perspective. It's easy to understand. But I just have some questions, not specific problems. Yaguang, I like the 'import' way too. But is there a global timeline of making oslo mature? Is this decided by oslo team or release plan? On Tue, Jul 16, 2013 at 11:00 AM, Yaguang Tang yaguang.t...@canonical.com wrote: we put openstack common code in oslo , and sync to other projects to keep the common code in each project is aways up to date, when oslo is mature enough, then we will publish oslo as a openstack common library. the common code in each project just need to change from from nova.openstack.common import something to from oslo.openstack.common import something after oslo is released , as the common code is aways sync from oslo, so there isn't any big change. correct me if my understanding is wrong. 在 2013-7-16 上午10:25，Gareth academicgar...@gmail.com写道： Hi, all There are some common codes in most of projects, such as opnstack/common, db, and some else (?). I know a good way is using 'import oslo' is ok, instead of copy those codes here and there. And now we already have project oslo and trove, but how and when do we handle old codes, remove that in next major release? -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack http://www.ustack.com* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ 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 -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack http://www.ustack.com* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Sample config file location inconsistency
On Tue, Jun 25, 2013 at 6:21 PM, Gary Kotton gkot...@redhat.com wrote: On 06/25/2013 06:03 AM, Zhongyue Luo wrote: Hi team I'm currently trying to move the generate_sample.sh script in nova to oslo. Before pushing the patch to gerrit, I wanted to give the output directory a default value if it was not stated so I was wondering where projects put their sample config file at and did this: find . -name *.conf* ! -path *.tox* ! -path *.venv* | grep etc results: ./ceilometer/etc/ceilometer/ceilometer.conf.sample ./cinder/etc/cinder/cinder.conf.sample ./nova/etc/nova/nova.conf.sample ./swift/etc/swift.conf-sample ./tempest/etc/tempest.conf.sample ./glance/etc/glance-cache.conf ./quantum/etc/quantum.conf At the moment Neutron (it is getting hard to get used to) does not have sample configuration file(s). The convention that we use is to try and have the default value of the variable in the configuration file commented out so that the user can update if they choose. In addition to this there are a number of different configuration files, for example - dhcp-agent.ini, l3-agent.ini etc. It may be a bit tricky generating sample configuration files for all of these. Thanks Gary This is also how Glance manages their conf files. I agree that it's better when configuration files are as small as possible for each daemon so this requirement makes sense. However mapping the options to the files seems need of manual control for the time being. Therefore the current goal is to list up all the options in one file with the default values commented out. This is for the web doc team to go through minimum hassle for updating option documentation. We should have further discussion on how to automatically map options to its conf file. ./keystone/etc/keystone.conf.sample You can see that ceilometer, cinder, and nova put their sample config files on ./etc/$PROJECTNAME while the others put it on ./etc So would this inconsistency be a problem? IMO, ./etc/$PROJECTNAME makes sense to me if consistency is an issue. Thoughts? -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://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 -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Sample config file location inconsistency
Hi team I'm currently trying to move the generate_sample.sh script in nova to oslo. Before pushing the patch to gerrit, I wanted to give the output directory a default value if it was not stated so I was wondering where projects put their sample config file at and did this: find . -name *.conf* ! -path *.tox* ! -path *.venv* | grep etc results: ./ceilometer/etc/ceilometer/ceilometer.conf.sample ./cinder/etc/cinder/cinder.conf.sample ./nova/etc/nova/nova.conf.sample ./swift/etc/swift.conf-sample ./tempest/etc/tempest.conf.sample ./glance/etc/glance-cache.conf ./quantum/etc/quantum.conf ./keystone/etc/keystone.conf.sample You can see that ceilometer, cinder, and nova put their sample config files on ./etc/$PROJECTNAME while the others put it on ./etc So would this inconsistency be a problem? IMO, ./etc/$PROJECTNAME makes sense to me if consistency is an issue. Thoughts? -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
