[openstack-dev] [All] LOG.warning/LOG.warn
Hi, Over the last few weeks I have seen a number of patches where LOG.warn is replacing LOG.warning. I think that if we do something it should be the opposite as warning is the documented one in python 2 and 3 https://docs.python.org/3/howto/logging.html. Any thoughts? Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party] What tests are required to be run
Hi Edgar, Freescale CI is reporting the results for ML2 Mechanism driver (J-1) and FWaaS Plugin (to be approved for J-3). I'm the owner for this CI. The Wiki page for this CI is https://wiki.openstack.org/wiki/ThirdPartySystems/Freescale_CI. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 -Original Message- From: Edgar Magana [mailto:edgar.mag...@workday.com] Sent: Saturday, August 16, 2014 4:06 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to be run Importance: High Team, I did a quick audit on the Neutron CI. Very sad results. Only few plugins and drivers are running properly and testing all Neutron commits. I created a report here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin _and_Drivers We will discuss the actions to take on the next Neutron IRC meeting. So please, reach me out to clarify what is the status of your CI. I had two commits to quickly verify the CI reliability: https://review.openstack.org/#/c/114393/ https://review.openstack.org/#/c/40296/ I would expect all plugins and drivers passing on the first one and failing for the second but I got so many surprises. Neutron code quality and reliability is a top priority, if you ignore this report that plugin/driver will be candidate to be remove from Neutron tree. Cheers, Edgar P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job! On 8/14/14, 8:30 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'm not sure if all CI accounts are running sufficient tests. Per the requirements wiki page here [1], everyone needs to be running more than just Tempest API tests, which I still see most neutron third-party CI setups doing. I'd like to ask everyone who operates a third-party CI account for Neutron to please look at the link below and make sure you are running appropriate tests. If you have questions, the weekly third-party meeting [2] is a great place to ask questions. Thanks, Kyle [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty ___ 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] Time to Samba! :-)
On Sat, Aug 16, 2014 at 11:03 PM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: Hey Stackers, I'm wondering here... Samba4 is pretty solid (up coming 4.2 rocks), I'm using it on a daily basis as an AD DC controller, for both Windows and Linux Instances! With replication, file system ACLs - cifs, built-in LDAP, dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty cool! In OpenStack ecosystem, there are awesome solutions like Trove, Solum, Designate and etc... Amazing times BTW! So, why not try to integrate Samba4, working as an AD DC, within OpenStack itself?! If yes, then, what is the best way/approach to achieve this?! I mean, for SQL, we have Trove, for iSCSI, Cinder, Nova uses Libvirt... Don't you guys think that it is time to have an OpenStack project for LDAP too? And since Samba4 come with it, plus DNS, AD, Kerberos and etc, I think that it will be huge if we manage to integrate it with OpenStack. I think that it would be nice to have, for example: domains, users and groups management at Horizon, and each tenant with its own Administrator (not the Keystone global admin) (to mange its Samba4 domains), so, they will be able to fully manage its own account, while allowing Keystone to authenticate against these users... Also, maybe Designate can have support for it too! I don't know for sure... Today, I'm doing this Samba integration manually, I have an external Samba4, from OpenStack's point of view, then, each tenant/project, have its own DNS domains, when a instance boots up, I just need to do something like this (bootstrap): -- echo 127.0.1.1 instance-1.tenant-1.domain-1.com instance-1 /etc/hosts net ads join -U administrator -- To make this work, the instance just needs to use Samba4 AD DC as its Name Servers, configured at its /etc/resolv.conf, delivered by DHCP Agent. The packages `samba-common-bin` and `krb5-user` are also required. Including a ready to use smb.conf file. Then, ping instance-1.tenant-1.domain-1.com worldwide! It works for both IPv4 and IPv6!! Also, Samba4 works okay with Disjoint Namespaces, so, each tenant can have one or more domains and subdomains! Like *.realm.domain.com, *.domain.com, *.cloud-net-1.domain.com, *.domain2.com... All dynamic managed by Samba4 and Bind9! What about that?! Cheers! Thiago There are several existing OpenStack projects which can help to leverage Samba support: 1. Manila - it seems to be capable of provisioning and attaching CIFS/SMB shares. I know Samba is more than just a CIFS share, but it is a significant part of it 2. You can use Heat to spin up a VM and configure Samba server 3. You can use Murano to spin up VMs with Samba, LDAP, Kerberos, etc (done with Heat internally) and configure them to work together Thanks, Ruslan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Time to Samba! :-)
This can be addressed by Murano only if its deployed to the cloud (on VM belonging to some tenant). Having it on OpenStack service layer integrated with major OpenStack services sounds very promising. The problem I see is significant overlap with Keystone, especially in Kerberos and LDAP parts Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com On Sun, Aug 17, 2014 at 4:56 AM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: I know! :-P On 16 August 2014 21:17, Adam Lawson alaw...@aqorn.com wrote: Also, don't forget that AD != LDAP. ;) On Aug 16, 2014 5:16 PM, Adam Lawson alaw...@aqorn.com wrote: Doesn't Murano address this already? On Aug 16, 2014 2:35 PM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: I think that it would be great too! OpenLDAP-as-a-Service... With multi-domain support! :-) Nevertheless, last time I used Samba, was back in 2001... It is impressive these days! It worth take a look... I'm using it for about two months now, it is great! Cheers! On 16 August 2014 18:01, Clint Byrum cl...@fewbar.com wrote: Excerpts from Martinx - ジェームズ's message of 2014-08-16 12:03:20 -0700: Hey Stackers, I'm wondering here... Samba4 is pretty solid (up coming 4.2 rocks), I'm using it on a daily basis as an AD DC controller, for both Windows and Linux Instances! With replication, file system ACLs - cifs, built-in LDAP, dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty cool! In OpenStack ecosystem, there are awesome solutions like Trove, Solum, Designate and etc... Amazing times BTW! So, why not try to integrate Samba4, working as an AD DC, within OpenStack itself?! But, if we did that, what would be left for us to reinvent in our own slightly different way? ___ 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] Time to Samba! :-)
On Sun, Aug 17, 2014 at 4:16 AM, Adam Lawson alaw...@aqorn.com wrote: Doesn't Murano address this already? Please note that Murano is no longer a windows-as-a-service or smth-as-a-serivce. Murano is an application catalog [1]. But you're absolutely right, this is a perfect use case for Murano - application developer can describe those applications and publish them in catalog, which will enable cloud users to combine those apps together. LDAP, Kerberos, Samba, ActiveDirectory - are applications in terms of Murano. [1] https://wiki.openstack.org/wiki/Murano -- Ruslan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] The future of the integrated release
On Fri, Aug 15, 2014 at 7:17 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: I recently suggested that the Ceilometer API (and integration tests) be separated from the implementation (two repos) so others might plug in a different implementation while maintaining compatibility, but that wasn't well received. Personally, I'd like to see that model extended for all OpenStack projects. Keep compatible at the API level and welcome competing implementations. Brilliant idea I'd vote for Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party] What tests are required to be run
On Fri, Aug 15, 2014 at 5:35 PM, Edgar Magana edgar.mag...@workday.com wrote: Team, I did a quick audit on the Neutron CI. Very sad results. Only few plugins and drivers are running properly and testing all Neutron commits. I created a report here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin _and_Drivers Can you link this and/or move it to this page: https://wiki.openstack.org/wiki/NeutronPlugins This is under the NeutronPolicies wiki page which I did at the start of Juno. This tracks all policies and procedures for Neutron, and there's a Plugins page (which I linked to above) where this should land. We will discuss the actions to take on the next Neutron IRC meeting. So please, reach me out to clarify what is the status of your CI. I had two commits to quickly verify the CI reliability: https://review.openstack.org/#/c/114393/ https://review.openstack.org/#/c/40296/ I would expect all plugins and drivers passing on the first one and failing for the second but I got so many surprises. Neutron code quality and reliability is a top priority, if you ignore this report that plugin/driver will be candidate to be remove from Neutron tree. Cheers, Edgar P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job! Thanks for sending this out Edgar and doing this analysis! Can you please put an agenda item on Monday's meeting to discuss this? I won't be at the meeting as I'm on PTO (Mark is running the meeting in my absence), but I'd like the team to discuss this and allow all third-party people a chance to be there and share their feelings here. Thanks, Kyle On 8/14/14, 8:30 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'm not sure if all CI accounts are running sufficient tests. Per the requirements wiki page here [1], everyone needs to be running more than just Tempest API tests, which I still see most neutron third-party CI setups doing. I'd like to ask everyone who operates a third-party CI account for Neutron to please look at the link below and make sure you are running appropriate tests. If you have questions, the weekly third-party meeting [2] is a great place to ask questions. Thanks, Kyle [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty ___ 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] [all] The future of the integrated release
On 08/17/2014 05:11 AM, Stan Lagun wrote: On Fri, Aug 15, 2014 at 7:17 PM, Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com wrote: I recently suggested that the Ceilometer API (and integration tests) be separated from the implementation (two repos) so others might plug in a different implementation while maintaining compatibility, but that wasn't well received. Personally, I'd like to see that model extended for all OpenStack projects. Keep compatible at the API level and welcome competing implementations. Brilliant idea I'd vote for The problem is when the API is the worst part of the project. We have a number of projects (some that I work on) that one of the weakest parts of the project is the design, inconsistency, and efficiency of the API constructs are simply terrible. The last thing I would want to do is say here, everyone go build multiple implementations on top of this crappy API. :( As for the idea of letting the market flush out competing implementations, I'm all for that ... with some caveats. A couple of those caveats would include: a) Must be Python if it is to be considered as a part of OpenStack's integrated release [1] b) The API must be simple, efficient, and consistent, possibly having signoff by some working group focused on API standards All the best, -jay [1] This isn't saying other programming languages aren't perfectly fine*, just that our integration and CI systems are focused on Python, and non-Python projects are a non-starter at this point. * except Java, of course. That goes without saying. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Using xstatic-bootstrap-scss version 2, and not 3
Hi, I have already uploaded a bunch of xstatic packages to Debian, in advance of the removal of the embedded files from Horizon. I would like to send my deepest thanks for this great initiative! The below packages are currently in the FTP master's NEW queue, waiting for approval: xstatic-angular, xstatic-angular-cookies, xstatic-angular-mock, xstatic-bootstrap-datepicker, xstatic-d3, xstatic-hogan=2.0.0.2, xstatic-jasmine, xstatic-jquery, xstatic-jquery.quicksearch, xstatic-jquery.tablesorter, xstatic-jsencrypt, xstatic-qunit, xstatic-rickshaw, xstatic-spin For these, I made a bunch of libjs-* Debian packages: libjs-jquery-migrate, libjs-jquery.quicksearch, libjs-jsencrypt, libjs-spin.js, libjs-twitter-bootstrap-datepicker I have uploaded libjs-jquery-migrate, but the rest of are also in the Debian FTP master's NEW queue. I wonder, by the way, if it was possible to upgrade spin to version 2.0.1, because version 1.2.5 isn't even available from the github repo. Remaining to do: xstatic-jquery-ui xstatic-jquery-migrate=1.2.1.1 # MIT License - IN NEW QUEUE xstatic-jquery.bootstrap.wizard=1.0.0.1 # MIT License I don't think it will take me a long time to have them done! :) Note that there's no git repo for xstatic-jquery-ui. The one from bitbucker was deleted, and there's no https://github.com/stackforge/xstatic-jquery-ui repository. I am guessing that this is just a mistake. Same for xstatic-jquery by the way. Anyway, I'm stuck with the jquery-ui for the moment, so it'd be nice to have this one solved soon. Anyway, before, we had this: xstatic-bootstrap-scss=2.0.1.1,3 # Apache 2.0 License but I've seen that this requirement got upgraded to 3. This is a problem in Debian, because all files of bootstrap-scss are contained within the compass-bootstrap-sass-plugin package, and it's currently in version 2.3.1.0. The current maintainer isn't very responsive, and as Debian Jessie will be frozen next 5th of November, I'm not sure it will be solved before Jessie is released. So I was wondering if it was possible to keep compatibility with version 2.3.1.0 of compass-bootstrap-sass-plugin within Horizon. Thoughts anyone? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] stable/havana jobs failing due to keystone bug 1357652
I'm seeing some nova stable/havana patches failing consistently on keystone bug 1357652 [1], keystone won't start due to an import error. I'm not seeing any recent changes for keystone in stable/havana so not sure if this is an infra issue or something else. I'm also not seeing the hits in logstash for some reason, which is odd. [1] https://bugs.launchpad.net/keystone/+bug/1357652 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] stable/havana jobs failing due to keystone bug 1357652
On 08/17/2014 09:08 AM, Matt Riedemann wrote: I'm seeing some nova stable/havana patches failing consistently on keystone bug 1357652 [1], keystone won't start due to an import error. I'm not seeing any recent changes for keystone in stable/havana so not sure if this is an infra issue or something else. I saw this too on Friday. I believe that it's related to a new keystoneclient requirement for oslo.utils, which isn't in requirements.txt for keystone. The change either needs to be reverted, or a requirement needs to be added to satisfy the dependency (which may not be appropriate for stable releases). -NGK I'm also not seeing the hits in logstash for some reason, which is odd. [1] https://bugs.launchpad.net/keystone/+bug/1357652 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] LOG.warning/LOG.warn
+2 I prefer the LOG.warning format and support that given the documentation you shared. If there is agreement I would create a hacking check. Jay On Aug 17, 2014 1:28 AM, Gary Kotton gkot...@vmware.com wrote: Hi, Over the last few weeks I have seen a number of patches where LOG.warn is replacing LOG.warning. I think that if we do something it should be the opposite as warning is the documented one in python 2 and 3 https://docs.python.org/3/howto/logging.html. Any thoughts? 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
Re: [openstack-dev] stable/havana jobs failing due to keystone bug 1357652
On 08/17/2014 09:18 AM, Nathan Kinder wrote: On 08/17/2014 09:08 AM, Matt Riedemann wrote: I'm seeing some nova stable/havana patches failing consistently on keystone bug 1357652 [1], keystone won't start due to an import error. I'm not seeing any recent changes for keystone in stable/havana so not sure if this is an infra issue or something else. I saw this too on Friday. I believe that it's related to a new keystoneclient requirement for oslo.utils, which isn't in requirements.txt for keystone. The change either needs to be reverted, or a requirement needs to be added to satisfy the dependency (which may not be appropriate for stable releases). This requirement change was backported for stable/icehouse: https://review.openstack.org/#/c/112337/ It seems like the right thing to do is to propose a similar change for stable/havana instead of reverting the keystoneclient change. -NGK I'm also not seeing the hits in logstash for some reason, which is odd. [1] https://bugs.launchpad.net/keystone/+bug/1357652 ___ 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] [all] The future of the integrated release
Hello all, As a Ceilometer's core, I'd like to add my 0.02$. During previous discussions it was mentioned several projects which were started or continue to be developed after Ceilometer became integrated. The main question I'm thinking of is why it was impossible to contribute into existing integrated project? Is it because of Ceilometer's architecture, the team or there are some other (maybe political) reasons? I think it's a very sad situation when we have 3-4 Ceilometer-like projects from different companies instead of the only one that satisfies everybody. (We don't see it in other projects. Though, maybe there are several Novas os Neutrons on StackForge and I don't know about it...) Of course, sometimes it's much easier to start the project from scratch. But there should be strong reasons for doing this if we are talking about integrated project. IMHO the idea, the role is the most important thing when we are talking about integrated project. And if Ceilometer's role is really needed (and I think it is) then we should improve existing implementation, merge all needs into the one project and the result will be still Ceilometer. Thanks, Nadya On Fri, Aug 15, 2014 at 12:41 AM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann d...@doughellmann.com wrote: On Aug 13, 2014, at 3:05 PM, Eoghan Glynn egl...@redhat.com wrote: At the end of the day, that's probably going to mean saying No to more things. Everytime I turn around everyone wants the TC to say No to things, just not to their particular thing. :) Which is human nature. But I think if we don't start saying No to more things we're going to end up with a pile of mud that no one is happy with. That we're being so abstract about all of this is frustrating. I get that no-one wants to start a flamewar, but can someone be concrete about what they feel we should say 'no' to but are likely to say 'yes' to? I'll bite, but please note this is a strawman. No: * Accepting any more projects into incubation until we are comfortable with the state of things again * Marconi * Ceilometer Well -1 to that, obviously, from me. Ceilometer is on track to fully execute on the gap analysis coverage plan agreed with the TC at the outset of this cycle, and has an active plan in progress to address architectural debt. Yes, there seems to be an attitude among several people in the community that the Ceilometer team denies that there are issues and refuses to work on them. Neither of those things is the case from our perspective. Totally agree. Can you be more specific about the shortcomings you see in the project that aren’t being addressed? Once again, this is just a strawman. I'm just not sure OpenStack has 'blessed' the best solution out there. https://wiki.openstack.org/wiki/Ceilometer/Graduation#Why_we_think_we.27re_ready - Successfully passed the challenge of being adopted by 3 related projects which have agreed to join or use ceilometer: - Synaps - Healthnmon - StackTach https://wiki.openstack.org/w/index.php?title=StackTachaction=editredlink=1 Stacktach seems to still be under active development ( http://git.openstack.org/cgit/stackforge/stacktach/log/), is used by rackspace in production and from everything I hear is more mature then ceilometer. Divert all cross project efforts from the following projects so we can focus our cross project resources. Once we are in a bitter place we can expand our cross project resources to cover these again. This doesn't mean removing anything. * Sahara * Trove * Tripleo You write as if cross-project efforts are both of fixed size and amenable to centralized command control. Neither of which is actually the case, IMO. Additional cross-project resources can be ponied up by the large contributor companies, and existing cross-project resources are not necessarily divertable on command. Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough. What “cross-project efforts” are we talking about? The liaison program in Oslo has been a qualified success so far. Would it make sense to extend that to other programs and say that each project needs at least one designated QA, Infra, Doc, etc. contact? Doug Yes: * All integrated projects that are not listed above And what of the other pending graduation request? Cheers, Eoghan ___ 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] [Trove] Reminder: Midcycle Meetup this week - IRC meetings canceled
Hello folks: Just wanted to send out a quick reminder that we have the Trove Midcycle Meetup this week (Aug 20 - 22) in Cambridge, MA. Details for the event can be found at [1]. Since many of us will also be traveling on Aug 18th and 19th, and the meeting agendas are light, I'm canceling the Trove IRC meetings scheduled for this week (BP meeting on the 18th, and weekly meeting on the 20th). We'll resume the meetings next week and pick up where we left off on the agenda. Looking forward to seeing many of you at the Midcycle Meetup! Cheers, Nikhil [1] https://wiki.openstack.org/w/index.php?title=Trove/JunoMidCycleMeetup. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][Neutron] tempest requirements errors while fetching oslo.i18n=0.1.0
reposting. any pointers from folks on the group? i dont see the errors below when running gate jobs manually, but when triggered from zuul, the tempest venv setup fails while trying to fetch some of the oslo packages. earlier i was seeing errors in oslo.il8n, now oslo.utils my first question, is if the package with the same version is already available on the system, is it expected for tempest to try and fetch it from a mirror? 2nd, since it doesnt seem to be a connectivity issue (the manual build works fine), why is the package not available at lost.. pip.log output is here - Paste #96539 | LodgeIt! Paste #96539 | LodgeIt! Requirement already up-to-date: warlock=1.0.1,2 in /usr/lib/python2.7/site-packages (from python-glanceclient=0.13.1-tempest==2.dev807.gfcd64c0) Getting page http://pypi.openstack.org/openstack/oslo.utils/ Could not fetch URL http://pypi.opens... View on paste.openstack.org Preview by Yahoo thanks in advance! From: daya kamath day...@yahoo.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org; Openstack-infra openstack-in...@lists.openstack.org Sent: Wednesday, August 6, 2014 9:18 AM Subject: [infra][Neutron] tempest requirements errors while fetching oslo.i18n=0.1.0 all, i'm seeing continuous errors when the gate script starts running tempest tests for neutron. it tries to download some packages even though these are visible in pip list output, and fails when trying to find a source for oslo.i18n = 0.1.0. this is not happening one-shot, continuously, so i dont think there's intermittent connectivity issues. interestingly, when i ran the same job on sandbox, it worked fine. any pointers? here's the error log - Paste #90811 | LodgeIt! Paste #90811 | LodgeIt! Running tempest sdnve tests 22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve 22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest 22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo... View on paste.openstack.org Preview by Yahoo Paste #90811 | LodgeIt! Running tempest sdnve tests 22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve 22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest 22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo... View on paste.openstack.org Preview by Yahoo here's my pip list output - Paste #90812 | LodgeIt! Paste #90812 | LodgeIt! alembic (0.6.5) amqp (1.3.3) anyjson (0.3.3) argparse (1.2.1) astroid (1.1.0) Babel (1.3) backports.ssl-match-hostname (3.4.0.2) BeautifulSoup (3.2.1) beautifulsoup4 (4.3.2) boto (2.27.0) bzr (2.6.0) ceilometer (2014.2.dev50.gb6a5978, /opt/stack/new/ceilometer)... View on paste.openstack.org Preview by Yahoo TIA for your help! also, sorry if you get multiple copies of the message, i got a membership disabled message when i sent it out earlier, and trying again.. daya___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] stable/havana jobs failing due to keystone bug 1357652
2014-08-17 18:30 GMT+02:00 Nathan Kinder nkin...@redhat.com: This requirement change was backported for stable/icehouse: https://review.openstack.org/#/c/112337/ It seems like the right thing to do is to propose a similar change for stable/havana instead of reverting the keystoneclient change. We had similar issue last month, it's due to fact we test master clients against stable releases of services. Change is appropriate for stable because it changes test requirements, not runtime deps for the project itself: https://review.openstack.org/106974 Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-stable-maint] stable/havana jobs failing due to keystone bug 1357652
On 8/17/2014 3:36 PM, Alan Pevec wrote: 2014-08-17 22:25 GMT+02:00 Matt Riedemann mrie...@linux.vnet.ibm.com: The other thing I thought was we could cap the version of python-keystoneclient in stable/havana, would that be bad? stable/havana is going to be end of life pretty soon anyway. No, we had cap on some clients and it was creating situations with conflicting requirements, last example was swiftclient2. Another alternative was to start stable/* from clients but that was rejected in the past. Theory is that *clients are backward compatible but I'm not sure if addition of new dependencies was considered when decision to go with master-only clients was made. I think it's fine to add new test-requirements on stable, we should just somehow get an early warning that client change is going to break stable branch and update test-req preemptively. Cheers, Alan OK, so here is where we appear to be: 1. We need the oslo.utils changes in python-keystoneclient reverted on master to get the stable/havana backports for global-requirements to pass Jenkins. The revert is here: https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+branch:master+topic:bug/1357652,n,z 2. The backports for oslo.i18n and oslo.utils to stable/havana are here: https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:stable/havana+topic:bug/1357652,n,z 3. Once 1 and 2 are done, we can restore the changes to python-keystoneclient on master. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] The future of the integrated release
Here's why folk are questioning Ceilometer: Nova is a set of tools to abstract virtualization implementations. Neutron is a set of tools to abstract SDN/NFV implementations. Cinder is a set of tools to abstract block-device implementations. Trove is a set of tools to simplify consumption of existing databases. Sahara is a set of tools to simplify Hadoop consumption. Swift is a feature-complete implementation of object storage, none of which existed when it was started. Keystone supports all of the above, unifying their auth. Horizon supports all of the above, unifying their GUI. Ceilometer is a complete implementation of data collection and alerting. There is no shortage of implementations that exist already. I'm also core on two projects that are getting some push back these days: Heat is a complete implementation of orchestration. There are at least a few of these already in existence, though not as many as their are data collection and alerting systems. TripleO is an attempt to deploy OpenStack using tools that OpenStack provides. There are already quite a few other tools that _can_ deploy OpenStack, so it stands to reason that people will question why we don't just use those. It is my hope we'll push more into the unifying the implementations space and withdraw a bit from the implementing stuff space. So, you see, people are happy to unify around a single abstraction, but not so much around a brand new implementation of things that already exist. Excerpts from Nadya Privalova's message of 2014-08-17 11:11:34 -0700: Hello all, As a Ceilometer's core, I'd like to add my 0.02$. During previous discussions it was mentioned several projects which were started or continue to be developed after Ceilometer became integrated. The main question I'm thinking of is why it was impossible to contribute into existing integrated project? Is it because of Ceilometer's architecture, the team or there are some other (maybe political) reasons? I think it's a very sad situation when we have 3-4 Ceilometer-like projects from different companies instead of the only one that satisfies everybody. (We don't see it in other projects. Though, maybe there are several Novas os Neutrons on StackForge and I don't know about it...) Of course, sometimes it's much easier to start the project from scratch. But there should be strong reasons for doing this if we are talking about integrated project. IMHO the idea, the role is the most important thing when we are talking about integrated project. And if Ceilometer's role is really needed (and I think it is) then we should improve existing implementation, merge all needs into the one project and the result will be still Ceilometer. Thanks, Nadya On Fri, Aug 15, 2014 at 12:41 AM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann d...@doughellmann.com wrote: On Aug 13, 2014, at 3:05 PM, Eoghan Glynn egl...@redhat.com wrote: At the end of the day, that's probably going to mean saying No to more things. Everytime I turn around everyone wants the TC to say No to things, just not to their particular thing. :) Which is human nature. But I think if we don't start saying No to more things we're going to end up with a pile of mud that no one is happy with. That we're being so abstract about all of this is frustrating. I get that no-one wants to start a flamewar, but can someone be concrete about what they feel we should say 'no' to but are likely to say 'yes' to? I'll bite, but please note this is a strawman. No: * Accepting any more projects into incubation until we are comfortable with the state of things again * Marconi * Ceilometer Well -1 to that, obviously, from me. Ceilometer is on track to fully execute on the gap analysis coverage plan agreed with the TC at the outset of this cycle, and has an active plan in progress to address architectural debt. Yes, there seems to be an attitude among several people in the community that the Ceilometer team denies that there are issues and refuses to work on them. Neither of those things is the case from our perspective. Totally agree. Can you be more specific about the shortcomings you see in the project that aren’t being addressed? Once again, this is just a strawman. I'm just not sure OpenStack has 'blessed' the best solution out there. https://wiki.openstack.org/wiki/Ceilometer/Graduation#Why_we_think_we.27re_ready - Successfully passed the challenge of being adopted by 3 related projects which have agreed to join or use ceilometer: - Synaps - Healthnmon - StackTach https://wiki.openstack.org/w/index.php?title=StackTachaction=editredlink=1 Stacktach seems to still be under active development ( http://git.openstack.org/cgit/stackforge/stacktach/log/), is used by
Re: [openstack-dev] [All] LOG.warning/LOG.warn
My recollection is that this was a request from the oslo team, but it was so long ago that I don't recall the details. I think the change is low value, so should only be done when someone is changing the logging in a file already (the log hinting for example). Michael On Sun, Aug 17, 2014 at 4:26 PM, Gary Kotton gkot...@vmware.com wrote: Hi, Over the last few weeks I have seen a number of patches where LOG.warn is replacing LOG.warning. I think that if we do something it should be the opposite as warning is the documented one in python 2 and 3 https://docs.python.org/3/howto/logging.html. Any thoughts? Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] Picking a Name for the Tempest Library
On Sun, Aug 17, 2014 at 1:27 AM, Marc Koderer m...@koderer.com wrote: Hi all, Am 15.08.2014 um 23:31 schrieb Jay Pipes jaypi...@gmail.com: I suggest that tempest should be the name of the import'able library, and that the integration tests themselves should be what is pulled out of the current Tempest repository, into their own repo called openstack-integration-tests or os-integration-tests“. why not keeping it simple: tempest: importable test library tempest-tests: all the test cases Simple, obvious and clear ;) ++. And for more clarity- importable test library could name as tempest-lib Regards Marc Best, -jay ___ 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 -- Thanks Regards Ghanshyam Mann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [infra][Neutron] tempest requirements errors while fetching oslo.i18n=0.1.0
On 2014-08-17 13:11:41 -0700 (-0700), daya kamath wrote: [...] Getting page http://pypi.openstack.org/openstack/oslo.utils/ Could not fetch URL [...] That mirror is abandoned and http://pypi.openstack.org/simple/ is the one we're maintaining for our jobs now. However, there's no reason to be using our mirror for YOUR systems. If you're not running a PyPI mirror of your own, you should just use pypi.python.org instead. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] Picking a Name for the Tempest Library
2014-08-17 1:27 GMT+09:00 Marc Koderer m...@koderer.com: Hi all, Am 15.08.2014 um 23:31 schrieb Jay Pipes jaypi...@gmail.com: I suggest that tempest should be the name of the import'able library, and that the integration tests themselves should be what is pulled out of the current Tempest repository, into their own repo called openstack-integration-tests or os-integration-tests“. why not keeping it simple: tempest: importable test library tempest-tests: all the test cases Simple, obvious and clear ;) +1 :-) Thanks Ken'ichi Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-stable-maint] stable/havana jobs failing due to keystone bug 1357652
On 08/17/2014 01:58 PM, Matt Riedemann wrote: On 8/17/2014 3:36 PM, Alan Pevec wrote: 2014-08-17 22:25 GMT+02:00 Matt Riedemann mrie...@linux.vnet.ibm.com: The other thing I thought was we could cap the version of python-keystoneclient in stable/havana, would that be bad? stable/havana is going to be end of life pretty soon anyway. No, we had cap on some clients and it was creating situations with conflicting requirements, last example was swiftclient2. Another alternative was to start stable/* from clients but that was rejected in the past. Theory is that *clients are backward compatible but I'm not sure if addition of new dependencies was considered when decision to go with master-only clients was made. I think it's fine to add new test-requirements on stable, we should just somehow get an early warning that client change is going to break stable branch and update test-req preemptively. Cheers, Alan OK, so here is where we appear to be: 1. We need the oslo.utils changes in python-keystoneclient reverted on master to get the stable/havana backports for global-requirements to pass Jenkins. The revert is here: https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+branch:master+topic:bug/1357652,n,z 2. The backports for oslo.i18n and oslo.utils to stable/havana are here: https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:stable/havana+topic:bug/1357652,n,z Jenkins is failing for stable/icehouse because of oslo.utils too: https://review.openstack.org/113744 What seems odd is that oslo.utils was already added to global-requirements.txt for stable/icehouse: https://review.openstack.org/#/c/112337/ Despite the above global-requirements.txt change, the tests are still failing. It seems like something more will be needed to get the tests passing for both stable/icehouse and stable/havana. 3. Once 1 and 2 are done, we can restore the changes to python-keystoneclient on master. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] backport fixes to old branches
On Friday, August 15, 2014 8:48 PM, Ihar Hrachyshka wrote: There was an issue with jenkins running py33 checks for stable ceilometer branches, which is wrong. Should be fixed now. Thank you for your response. I couldn't solve this by myself but Dina Belova and Julien Danjou solved this issue with: https://review.openstack.org/#/c/113842/ Best Regards, Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-stable-maint] stable/havana jobs failing due to keystone bug 1357652
On 08/17/2014 05:40 PM, Nathan Kinder wrote: On 08/17/2014 01:58 PM, Matt Riedemann wrote: On 8/17/2014 3:36 PM, Alan Pevec wrote: 2014-08-17 22:25 GMT+02:00 Matt Riedemann mrie...@linux.vnet.ibm.com: The other thing I thought was we could cap the version of python-keystoneclient in stable/havana, would that be bad? stable/havana is going to be end of life pretty soon anyway. No, we had cap on some clients and it was creating situations with conflicting requirements, last example was swiftclient2. Another alternative was to start stable/* from clients but that was rejected in the past. Theory is that *clients are backward compatible but I'm not sure if addition of new dependencies was considered when decision to go with master-only clients was made. I think it's fine to add new test-requirements on stable, we should just somehow get an early warning that client change is going to break stable branch and update test-req preemptively. Cheers, Alan OK, so here is where we appear to be: 1. We need the oslo.utils changes in python-keystoneclient reverted on master to get the stable/havana backports for global-requirements to pass Jenkins. The revert is here: https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+branch:master+topic:bug/1357652,n,z 2. The backports for oslo.i18n and oslo.utils to stable/havana are here: https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:stable/havana+topic:bug/1357652,n,z Jenkins is failing for stable/icehouse because of oslo.utils too: https://review.openstack.org/113744 What seems odd is that oslo.utils was already added to global-requirements.txt for stable/icehouse: https://review.openstack.org/#/c/112337/ Despite the above global-requirements.txt change, the tests are still failing. It seems like something more will be needed to get the tests passing for both stable/icehouse and stable/havana. I see that Brant has already proposed adding oslo.utils to test-requirements.txt for keystone in stable/havana and stable/icehouse, which should take care of these failures: havana - https://review.openstack.org/#/c/114846/ icehouse - https://review.openstack.org/#/c/114845/ 3. Once 1 and 2 are done, we can restore the changes to python-keystoneclient on master. ___ 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] gettext question about oslo.i18n library
Yes, I am interested in adding these missing gettext functions to oslo.i18n library. Guess the next step is to create a blueprint for Kilo? Thanks, Peng Wu On Fri, 2014-08-15 at 16:02 -0400, Doug Hellmann wrote: On Aug 15, 2014, at 3:18 AM, Peng Wu peng.e...@gmail.com wrote: Hi, Recently I just read the code of oslo.i18n library, The lazy translation idea is great! But I found a question about gettext contextual markers and plural form, such as pgettext and ungettext functions, see [3]. It seems the two gettext functions are missing in the oslo.i18n library. Is it correct? or will support it? Thanks, Peng Wu You’re right, those are not present. We apparently haven’t used them anywhere, yet, because they weren’t exposed via the old gettextutils module in the incubator. We should add them. Are you interested in working on a blueprint for Kilo to do that? Doug Refer URL: 1. https://github.com/openstack/oslo.i18n 2. http://lists.openstack.org/pipermail/openstack-dev/2014-July/039217.html 3. https://wiki.openstack.org/wiki/I18n/TranslatableStrings ___ 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] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches
Hi Brandon, I am trying to rebase Netscaler driver to the latest v2 patches as mentioned in https://wiki.openstack.org/wiki/GerritWorkflow But it failed during review submit It failed with the following error remote: Processing changes: refs: 1, done To ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git ! [remote rejected] HEAD - refs/publish/master/bp/netscaler-lbass-v2-driver (squash commits first) error: failed to push some refs to 'ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git' Any clues on how to proceed? Thanks, Vijay V. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches
From the looks of your error, you at least have a problem with more than one commit in your topic branch. Here¹s the process that I use. I¹m not claiming it¹s the best, but it works without rewriting Brandon¹s commits. Watch the git log at the end, and make sure the dependent hashes match what¹s in gerrit, before the Œgit review¹: git clone https://review.openstack.org/openstack/neutron neutron-juno-update1 cd neutron-juno-update1/ git review -d 105610 git checkout -b bp/a10-lbaas-driver *cherry-pick your commit from gerrit* (e.g. git fetch https://review.openstack.org/openstack/neutron refs/changes/37/106937/26 git cherry-pick FETCH_HEAD) *resolve conflicts* git cherry-pick ‹continue *make changes* git commit -a --amend git log -n5 --decorate --pretty=oneline git review If you¹re not making any changes, then you can just hit the Œrebase¹ button in the gerrit ui. Thanks, doug On 8/17/14, 8:19 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Hi Brandon, I am trying to rebase Netscaler driver to the latest v2 patches as mentioned in https://wiki.openstack.org/wiki/GerritWorkflow But it failed during review submit It failed with the following error remote: Processing changes: refs: 1, done To ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git ! [remote rejected] HEAD - refs/publish/master/bp/netscaler-lbass-v2-driver (squash commits first) error: failed to push some refs to 'ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git ' Any clues on how to proceed? Thanks, Vijay V. ___ 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] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches
Hi Vijay, Are you trying to rebase by pulling down the new changes and rebasing your branch on top of that? That'll usually end up wrong because of commit hashes. Have you tried using the rebase button gerrit provides? Let me know how exactly you're trying to rebase if you've already tried the gerrit rebase button or if you'd like to know how to do it by rebasing locally. I'm going to add more details to that GerritWorkflow wiki page. It's lacking on dependency chains and how to do rebases, cherry-picks, etc without accidentally pushing more patch sets to dependent reviews. I've been meaning to do I've just been lazy about doing that. Thanks, Brandon From: Vijay Venkatachalam [vijay.venkatacha...@citrix.com] Sent: Sunday, August 17, 2014 9:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches Hi Brandon, I am trying to rebase Netscaler driver to the latest v2 patches as mentioned in https://wiki.openstack.org/wiki/GerritWorkflow But it failed during review submit It failed with the following error remote: Processing changes: refs: 1, done To ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git ! [remote rejected] HEAD - refs/publish/master/bp/netscaler-lbass-v2-driver (squash commits first) error: failed to push some refs to 'ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git' Any clues on how to proceed? Thanks, Vijay V. ___ 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] [neutron] [third-party] What tests are required to be run
Edgar: The Cisco APIC should be reporting results for both APIC-related and non-APIC related changes now. (See http://cisco-neutron-ci.cisco.com/logs/apic/1738/). Will you be updating the wiki page? -Dane -Original Message- From: Dane Leblanc (leblancd) Sent: Friday, August 15, 2014 8:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to be run Also, you can add me as a contact person for the Cisco VPNaaS driver. -Original Message- From: Dane Leblanc (leblancd) Sent: Friday, August 15, 2014 8:14 PM To: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [neutron] [third-party] What tests are required to be run Edgar: For the Notes for the Cisco APIC, can you change the comment results are fake to something like results are only valid for APIC-related commits? I think this more accurately represents our current results (for reasons we chatted about on another thread). Thanks, Dane -Original Message- From: Edgar Magana [mailto:edgar.mag...@workday.com] Sent: Friday, August 15, 2014 6:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to be run Importance: High Team, I did a quick audit on the Neutron CI. Very sad results. Only few plugins and drivers are running properly and testing all Neutron commits. I created a report here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin _and_Drivers We will discuss the actions to take on the next Neutron IRC meeting. So please, reach me out to clarify what is the status of your CI. I had two commits to quickly verify the CI reliability: https://review.openstack.org/#/c/114393/ https://review.openstack.org/#/c/40296/ I would expect all plugins and drivers passing on the first one and failing for the second but I got so many surprises. Neutron code quality and reliability is a top priority, if you ignore this report that plugin/driver will be candidate to be remove from Neutron tree. Cheers, Edgar P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job! On 8/14/14, 8:30 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'm not sure if all CI accounts are running sufficient tests. Per the requirements wiki page here [1], everyone needs to be running more than just Tempest API tests, which I still see most neutron third-party CI setups doing. I'd like to ask everyone who operates a third-party CI account for Neutron to please look at the link below and make sure you are running appropriate tests. If you have questions, the weekly third-party meeting [2] is a great place to ask questions. Thanks, Kyle [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty ___ 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] [neutron] [third-party] What tests are required to be run
Hi Edgar, Freescale CI is not listed in the below report: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Pl We are following all the requirements of CI setup and as well participating in the IRC Meeting. Can you please let us know if we are missing any other requirements of CI Setup. Regards, Balaji.P -Original Message- From: trinath.soman...@freescale.com [mailto:trinath.soman...@freescale.com] Sent: Sunday, August 17, 2014 12:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to be run Hi Edgar, Freescale CI is reporting the results for ML2 Mechanism driver (J-1) and FWaaS Plugin (to be approved for J-3). I'm the owner for this CI. The Wiki page for this CI is https://wiki.openstack.org/wiki/ThirdPartySystems/Freescale_CI. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 -Original Message- From: Edgar Magana [mailto:edgar.mag...@workday.com] Sent: Saturday, August 16, 2014 4:06 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to be run Importance: High Team, I did a quick audit on the Neutron CI. Very sad results. Only few plugins and drivers are running properly and testing all Neutron commits. I created a report here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plug in _and_Drivers We will discuss the actions to take on the next Neutron IRC meeting. So please, reach me out to clarify what is the status of your CI. I had two commits to quickly verify the CI reliability: https://review.openstack.org/#/c/114393/ https://review.openstack.org/#/c/40296/ I would expect all plugins and drivers passing on the first one and failing for the second but I got so many surprises. Neutron code quality and reliability is a top priority, if you ignore this report that plugin/driver will be candidate to be remove from Neutron tree. Cheers, Edgar P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job! On 8/14/14, 8:30 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'm not sure if all CI accounts are running sufficient tests. Per the requirements wiki page here [1], everyone needs to be running more than just Tempest API tests, which I still see most neutron third-party CI setups doing. I'd like to ask everyone who operates a third-party CI account for Neutron to please look at the link below and make sure you are running appropriate tests. If you have questions, the weekly third-party meeting [2] is a great place to ask questions. Thanks, Kyle [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty ___ 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] [Octavia] Object Model and DB Structure
Oh hello again! You know the drill! On Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote: Hi Brandon, Responses in-line: On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Comments in-line On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote: Hi folks, I'm OK with going with no shareable child entities (Listeners, Pools, Members, TLS-related objects, L7-related objects, etc.). This will simplify a lot of things (like status reporting), and we can probably safely work under the assumption that any user who has a use case in which a shared entity is useful is probably also technically savvy enough to not only be able to manage consistency problems themselves, but is also likely to want to have that level of control. Also, an haproxy instance should map to a single listener. This makes management of the configuration template simpler and the behavior of a single haproxy instance more predictable. Also, when it comes to configuration updates (as will happen, say, when a new member gets added to a pool), it's less risky and error prone to restart the haproxy instance for just the affected listener, and not for all listeners on the Octavia VM. The only down-sides I see are that we consume slightly more memory, we don't have the advantage of a shared SSL session cache (probably doesn't matter for 99.99% of sites using TLS anyway), and certain types of persistence wouldn't carry over between different listeners if they're implemented poorly by the user. :/ (In other words, negligible down-sides to this.) This is fine by me for now, but I think this might be something we can revisit later after we have the advantage of hindsight. Maybe a configurable option. Sounds good, as long as we agree on a path forward. In the mean time, is there anything I'm missing which would be a significant advantage of having multiple Listeners configured in a single haproxy instance? (Or rather, where a single haproxy instance maps to a loadbalancer object?) No particular reason as of now. Just feel like that could be something that could hinder a particular feature or even performance in the future. It's not rooted in any fact or past experience. I have no problem with this. However, one thing I often do think about is that it's not really ever going to be load balancing anything with just a load balancer and listener. It has to have a pool and members as well. So having ACTIVE on the load balancer and listener, and still not really load balancing anything is a bit odd. Which is why I'm in favor of only doing creates by specifying the entire tree in one call (loadbalancer-listeners-pool-members). Feel free to disagree with me on this because I know this not something everyone likes. I'm sure I am forgetting something that makes this a hard thing to do. But if this were the case, then I think only having the provisioning status on the load balancer makes sense again. The reason I am advocating for the provisioning status on the load balancer is because it still simpler, and only one place to look to see if everything were successful or if there was an issue. Actually, there is one case where it makes sense to have an ACTIVE Listener when that listener has no pools or members: Probably the 2nd or 3rd most common type of load balancing service we deploy is just an HTTP listener on port 80 that redirects all requests to the HTTPS listener on port 443. While this can be done using a (small) pool of back-end servers responding to the port 80 requests, there's really no point in not having the haproxy instance do this redirect directly for sites that want all access to happen over SSL. (For users that want them we also insert HSTS headers when we do this... but I digress. ;) ) Anyway, my point is that there is a common production use case that calls for a listener with no pools or members. Yeah we do HTTPS redirect too (or HTTP redirect as I would call it...I could digress myself). I don't think its common for our customers, but it obviously should still be supported. Also, wouldn't that break the only one listener per instance rule? Also also, I think haproxy 1.5 has redirect scheme option that might do away with the extra
Re: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches
Hi Brandon, Thanks for the quick reply. I don't use a UI. This is what I did to rebase to the latest dependent patches, without doing any changes to my patchset files. git checkout netscaler-lbaas-driver-v2 # netscaler-lbaas-driver-v2 == the topic branch where I had my original changes. git review -d 105610 # this pulls the latest changes you have made for v2 into the branch review/brandon_logan/bp/lbaas-api-and-objmodel-improvement git checkout netscaler-lbaas-driver-v2 git rebase -i review/brandon_logan/bp/lbaas-api-and-objmodel-improvement # At this point the rebase didn't succeed, I resolved the conflict git add files_that_are_resolved git commit -a --amend git review errors Thanks, Vijay V. -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: 18 August 2014 08:53 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches Hi Vijay, Are you trying to rebase by pulling down the new changes and rebasing your branch on top of that? That'll usually end up wrong because of commit hashes. Have you tried using the rebase button gerrit provides? Let me know how exactly you're trying to rebase if you've already tried the gerrit rebase button or if you'd like to know how to do it by rebasing locally. I'm going to add more details to that GerritWorkflow wiki page. It's lacking on dependency chains and how to do rebases, cherry-picks, etc without accidentally pushing more patch sets to dependent reviews. I've been meaning to do I've just been lazy about doing that. Thanks, Brandon From: Vijay Venkatachalam [vijay.venkatacha...@citrix.com] Sent: Sunday, August 17, 2014 9:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches Hi Brandon, I am trying to rebase Netscaler driver to the latest v2 patches as mentioned in https://wiki.openstack.org/wiki/GerritWorkflow But it failed during review submit It failed with the following error remote: Processing changes: refs: 1, done To ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git ! [remote rejected] HEAD - refs/publish/master/bp/netscaler-lbass-v2-driver (squash commits first) error: failed to push some refs to 'ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.git' Any clues on how to proceed? Thanks, Vijay V. ___ 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] OS or os are not acronyms for OpenStack
On 08/15/2014 08:51 AM, Steve Gordon wrote: - Original Message - From: Anita Kuno ante...@anteaya.info To: openStack Development Mailing List openstack-dev@lists.openstack.org OpenStack is OpenStack. The use of openstack is also acceptable in our development conversations. OS or os is operating system. I am starting to see some people us OS or os to mean OpenStack. This is confusing and also incorrect[0]. No alterations: When using OpenStack Marks, you shall never vary the spelling, hyphenation or spacing of the any portion of the marks. Examples of Improper Display of an OpenStack Mark: Open-Stack; Open Stack; OS Stack Examples of Proper Display of an OpenStack Mark: OpenStack; OPENSTACK While this comes from the OpenStack Trademark Policy, I think it is important to remember this information and to implement it in our daily use. I have had to change at least one wikipage so far, it is far easier if folks simply employ the correct usage from the beginning. My thanks, Anita. [0] http://www.openstack.org/brand/openstack-trademark-policy/ Hi Anita, I noticed you raised this issue on this thread but didn't really understand why: http://lists.openstack.org/pipermail/openstack-dev/2014-August/043087.html Can you explain? The os types being referred to were the operating system types supported by VMware. -Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi Steve: Yes I see that now in the context of the thread. Mostly this is my mistake. I have seen the acronym used incorrectly so often the use in the subject line confused me and I posted partly to clarify for my own purposes and partly to set a data point for those who are using the acronym to mean openstack in an attempt to acknowledge its correct usage. I didn't mean to disturb the flow of conversation in your thread and if I have done so, please accept my apology. Thanks Steve, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches
This worked. Thanks! But this procedure requires to clone again. I wonder why rebase didn’t work and cherry pick worked. May be I should tried the gerrit UI. As said in the earlier mail to Brandon, this is what I did. # netscaler-lbaas-driver-v2 == the topic branch where I had my original changes. git checkout netscaler-lbaas-driver-v2 git review -d 105610 # the above command pulls the latest dependent changes into review/brandon_logan/bp/lbaas-api-and-objmodel-improvement git checkout netscaler-lbaas-driver-v2 git rebase -i review/brandon_logan/bp/lbaas-api-and-objmodel-improvement # At this point the rebase didn’t succeed, I resolved the conflicts git add files_that_are_resolved git commit -a --amend git review #At this point I got the errors. Thanks, Vijay V. -Original Message- From: Doug Wiegley [mailto:do...@a10networks.com] Sent: 18 August 2014 08:54 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Failure when trying to rebase to latest v2 patches From the looks of your error, you at least have a problem with more than one commit in your topic branch. Here¹s the process that I use. I¹m not claiming it¹s the best, but it works without rewriting Brandon¹s commits. Watch the git log at the end, and make sure the dependent hashes match what¹s in gerrit, before the Œgit review¹: git clone https://review.openstack.org/openstack/neutron neutron-juno-update1 cd neutron-juno-update1/ git review -d 105610 git checkout -b bp/a10-lbaas-driver *cherry-pick your commit from gerrit* (e.g. git fetch https://review.openstack.org/openstack/neutron refs/changes/37/106937/26 git cherry-pick FETCH_HEAD) *resolve conflicts* git cherry-pick ‹continue *make changes* git commit -a --amend git log -n5 --decorate --pretty=oneline git review If you¹re not making any changes, then you can just hit the Œrebase¹ button in the gerrit ui. Thanks, doug On 8/17/14, 8:19 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Hi Brandon, I am trying to rebase Netscaler driver to the latest v2 patches as mentioned in https://wiki.openstack.org/wiki/GerritWorkflow But it failed during review submit It failed with the following error remote: Processing changes: refs: 1, done To ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron.g it ! [remote rejected] HEAD - refs/publish/master/bp/netscaler-lbass-v2-driver (squash commits first) error: failed to push some refs to 'ssh://vijayvenkatacha...@review.openstack.org:29418/openstack/neutron. git ' Any clues on how to proceed? Thanks, Vijay V. ___ 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] Time to Samba! :-)
On Sun, 2014-08-17 at 13:05 +0400, Ruslan Kamaldinov wrote: On Sun, Aug 17, 2014 at 4:16 AM, Adam Lawson alaw...@aqorn.com wrote: Doesn't Murano address this already? Please note that Murano is no longer a windows-as-a-service or smth-as-a-serivce. Murano is an application catalog [1]. But you're absolutely right, this is a perfect use case for Murano - application developer can describe those applications and publish them in catalog, which will enable cloud users to combine those apps together. LDAP, Kerberos, Samba, ActiveDirectory - are applications in terms of Murano. [1] https://wiki.openstack.org/wiki/Murano G'Day, Indeed, I think Murano may well be the natural home of Samba deployed as an AD DC, inside a tenant. I reached out to the Murano team a few months ago, but haven't have any time to put into development of a Samba AD DC application yet. I work for Catalyst in NZ, and lurk here and quite close to our internal OpenStack team. I think OpenStack is a great opportunity for Samba and Samba is a great fit for OpenStack, particularly when we look at the emerging market of Desktop as Service, things like hosted Exchange (or more particularly OpenChange), and single-sign-on from the Windows-dominated enterprise. What I would like to do is to work closely with someone already more familiar with the OpenStack world, and provide my expertise and assistance to that existing effort. I also think that Samba does justify being beyond just being an application in Murano, because for the best results, Samba should be used, but not administered directly. Instead, what would bring the best out of Samba is deployment like in Trove, where the Tenant does not get rights to directly touch the instance - operation of the AD DC should be by OpenStack, not the end-user. Finally, yes Samba certainly plays a role in Manila, and while currently very well hidden, I think that some really great functionality can be exposed via the 'generic' driver that would be far from generic. Imagine if that driver 'just worked' with exposed snapshots via the windows 'previous versions' tab, for example. Or, imagine if we used the OpenStack machine credentials to securely get a Kerberos ticket for access to a big multi-tenant file share? As I mention, I do lurk here, but also feel free to contact me directly or the Samba lists if you are implementing Samba as an OpenStack service, and you think I can help, or think I've missed some discussion. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party] What tests are required to be run
On 2014/08/18 0:12, Kyle Mestery wrote: On Fri, Aug 15, 2014 at 5:35 PM, Edgar Magana edgar.mag...@workday.com wrote: Team, I did a quick audit on the Neutron CI. Very sad results. Only few plugins and drivers are running properly and testing all Neutron commits. I created a report here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin _and_Drivers Can you link this and/or move it to this page: https://wiki.openstack.org/wiki/NeutronPlugins This is under the NeutronPolicies wiki page which I did at the start of Juno. This tracks all policies and procedures for Neutron, and there's a Plugins page (which I linked to above) where this should land. I just added the link Neutron_Plugins_and_Drivers#Existing_Plugin to NeutronPlugins wiki. The wiki pages NeutronPlugins and Neutron_Plugins_and_Drivers cover the similar contents. According to the history of the page, the latter one was created by Mark at Nov 2013 (beginning of Icehouse cycle). It seems better to merge these two pages to avoid the confusion. Akihiro We will discuss the actions to take on the next Neutron IRC meeting. So please, reach me out to clarify what is the status of your CI. I had two commits to quickly verify the CI reliability: https://review.openstack.org/#/c/114393/ https://review.openstack.org/#/c/40296/ I would expect all plugins and drivers passing on the first one and failing for the second but I got so many surprises. Neutron code quality and reliability is a top priority, if you ignore this report that plugin/driver will be candidate to be remove from Neutron tree. Cheers, Edgar P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job! Thanks for sending this out Edgar and doing this analysis! Can you please put an agenda item on Monday's meeting to discuss this? I won't be at the meeting as I'm on PTO (Mark is running the meeting in my absence), but I'd like the team to discuss this and allow all third-party people a chance to be there and share their feelings here. Thanks, Kyle On 8/14/14, 8:30 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'm not sure if all CI accounts are running sufficient tests. Per the requirements wiki page here [1], everyone needs to be running more than just Tempest API tests, which I still see most neutron third-party CI setups doing. I'd like to ask everyone who operates a third-party CI account for Neutron to please look at the link below and make sure you are running appropriate tests. If you have questions, the weekly third-party meeting [2] is a great place to ask questions. Thanks, Kyle [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty ___ 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] Time to Samba! :-)
On Sun, 2014-08-17 at 13:00 +0400, Stan Lagun wrote: This can be addressed by Murano only if its deployed to the cloud (on VM belonging to some tenant). Having it on OpenStack service layer integrated with major OpenStack services sounds very promising. The problem I see is significant overlap with Keystone, especially in Kerberos and LDAP parts I do agree that Samba belongs, for many use cases, in the OpenStack service layer. I'm very interested to understand how you see it overlapping with Keystone - both for my understanding and for possible integration or assistance. Samba's user database I think mostly pertains to the users in a tenant (even if not managed by that tenant), wheras I understand Keystone is typically the VMs and their administrators. For those there is some overlap, but not one I think should cause us a major issue, but I'm very interested to learn more. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
