Re: [openstack-dev] [all] PBR 2.0.0 release *may* cause gate failures
On Wed, Mar 1, 2017 at 2:12 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Doug Hellmann's message of 2017-03-01 14:04:19 -0500: >> Excerpts from Andreas Jaeger's message of 2017-03-01 19:50:51 +0100: >> > On 2017-03-01 17:13, Doug Hellmann wrote: >> > > Excerpts from Andreas Jaeger's message of 2017-03-01 16:22:24 +0100: >> > >> On 2017-03-01 06:26, Tony Breeds wrote: >> > >>> Hi All, >> > >>> Earlier today the release team tagged PBR 2.0.0. The reason for >> > >>> the major >> > >>> version bump is because warnerrors has been removed in favor of >> > >>> warning-is-error from sphinx >= 1.5.0. >> > >> >> > >> Can we change the sphinx==1.3.6 line in upper-constraints now? >> > > >> > > We're currently running into failures updating requirements because of >> > > the pbr cap in several libraries. >> > > >> > > I see requestsexceptions, sqlalchemy-migrate, yaql, fairy-slipper, >> > > pypowervm, gnocchiclient, reno, and aodhclient mentioned in >> > > http://logs.openstack.org/88/439588/2/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/97625f3/console.html >> > > for example. >> > > >> > > I'm working on reno right now. >> > >> > thanks >> > >> > fairy-slipper is retired, let's remove it - >> > https://review.openstack.org/439769 >> > >> > Andreas >> >> Based on the nature of the failures, I think we're going to have to get >> releases of all of the other projects up, and then prepare one patch in >> the requirements repo to update constraints all at one time. >> >> Doug > > Most of the projects involved are trying to take action, but I haven't > seen any updates on the pypowervm pull request in > https://github.com/powervm/pypowervm/pull/1 > > Can someone contact that team and ask them to merge it and push a new > release? Done. over on #openstack-nova [11:40:49] thorst : Anyone around to merge this PR and cut a release for pypowervm? https://github.com/powervm/pypowervm/pull/1 [11:41:20] dims: Yeah, we're working on getting a new rev of that. It'd be pypowervm 1.0.0.4.1 to take in the new req. adreznec is working on it. [11:41:32] great thanks thorst and adreznec [11:41:42] dims: thorst Yep, just working on that now [11:41:44] thx for letting us know! > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] A Survey on OpenStack API Failures
Pooya, What/Where is the data collected going to be used for? Is this an effort from an existing OpenStack work group? or a university project? Thanks, Dims On Mon, Feb 27, 2017 at 9:33 PM, Pooya Musavi <musavi.p...@gmail.com> wrote: > Hi all, > > I am writing to you to request your participation in a brief survey. No > personally identifiable information will be associated with your responses > to any reports of these data. The survey is very brief and will only take > about 5 minutes to complete. Please click the link below to go to the survey > Web site: > > https://goo.gl/forms/XnHwkLfQe5uB7LR82 > > Thank you very much for your time and cooperation. > > -- > Kind Regards > Pooya > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Davanum Srinivas :: https://twitter.com/dims ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters
r some firewall rules and etc). >>> >>> >>> >>> We need to get +1 from you in [1] to create the repository with >>> >>> advanced end-user scenario tests. >>> >>> >>> >>> Thank you! >>> >>> >>> >>> [1] https://review.openstack.org/#/c/374667/ >>> >>> >>> >>> On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov <yloban...@mirantis.com> >>> wrote: >>> >>> Hi Ken, >>> >>> >>> >>> OS-Faults doesn't have any scenarios in the tree yet (the project is two >>> months old), but you can find some examples of the use in the >>> os-faults/examples directory. >>> >>> >>> >>> Regards, >>> >>> Yaroslav Lobankov. >>> >>> >>> >>> On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> >>> wrote: >>> >>> Hi Timur, >>> >>> Thanks for your explanation. >>> >>> >>> 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov <tnurlygaya...@mirantis.com>: >>> > >>> >> I am guessing the above "restart nodes" is for verifying each >>> >> OpenStack service restarts successfully, right? >>> > >>> > Yes, this is right. And we also will check that HA logic for these >>> > services works correctly (for example, rescheduling of L3 Neutron >>> > agents for networks). >>> > >>> >> But these service scripts are provided by distributors, and Devstack >>> >> itself doesn't contain service scripts IIUC. >>> >> So I'd like to know how to verify it on Devstack clouds. >>> > >>> > Yes, DevStack doesn't support many scenarios which are actual >>> > and should be supported on the production clouds. >>> > It will be not possible to run all advanced test scenarios for DevStack >>> > clouds, >>> > just because DevStack can't deploy OpenStack cloud with 3 controllers >>> > now (so, probably it will be possible in the future). >>> > >>> > Of course, some advanced scenarios will support DevStack clouds, >>> > for example, some test scenarios which are based on customer-found >>> > issues from the real production clouds, like upload of the large images >>> > (100+ Gb) >>> > to Glance with Swift backend. Such cases are important for verification >>> > of >>> > pre-production environments, but not very important for CI gate jobs. >>> > >>> > It is also important to note that in these advanced cases we are >>> > targeting >>> > to check not only the logic of Python code, but also the correct >>> > configuration >>> > of all OpenStack components on some pre-production OpenStack clusters. >>> >>> I guessed some part of os-faults can be moved to Tempest if os-faults >>> contains API tests for enabling/disabling OpenStack services. >>> Then, os-faults would be able to concentrate on more destructive tests >>> like rebooting physical nodes, etc. >>> However, I could not find any actual scenarios on current os-faults >>> (https://github.com/openstack/os-faults). >>> That seems to just contain some abstraction layers and unit tests. Can >>> we see actual test scenarios of os-faults ? >>> Maybe I missed something. >>> >>> Thanks >>> Ken Ohmichi >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> Timur, >>> >>> Senior QA Manager >>> >>> OpenStack Projects >>> >>> Mirantis Inc >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> >> Timur, >> QA Manager >> OpenStack Projects >> Mirantis Inc >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][all] Ocata release candidates frozen
Eric, No worries. thanks for the heads up. +1 to the exception -- Dims On Fri, Feb 17, 2017 at 6:18 PM, Eric K <ekcs.openst...@gmail.com> wrote: > Hi all, > > I¹d like to request an exception to release Congress RC2. I¹m really sorry > that we got bogged down by a tricky, critical bug that we didn¹t manage to > root cause and patch until the very last minute. I replied to Doug earlier > about it, but neglected to reply to the list. > > Here¹s the release request in question: > https://review.openstack.org/#/c/435551/ > > Thanks so much for considering the request. > > Eric > > On 2/17/17, 8:08 AM, "Doug Hellmann" <d...@doughellmann.com> wrote: > >>Later today we will be entering the freeze period between the release >>candidates and the final release next Wednesday. We have a couple >>of releases in progress now for senlin and python-magnumclient, but >>after those are completed we will not be releasing anything until >>after the PTG. >> >>I hope to see you in Atlanta! >> >>Doug >> >>__ >>OpenStack Development Mailing List (not for usage questions) >>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Some findings while profiling instances boot
Mike, Team, Rolling the dice here: https://review.openstack.org/#/c/435009/ Thanks, Dims On Thu, Feb 16, 2017 at 11:35 AM, Mike Bayer <mba...@redhat.com> wrote: > > > On 02/15/2017 12:46 PM, Daniel Alvarez Sanchez wrote: >> >> Also, while having a look at server profiling, around the 33% of the >> time was spent building SQL queries [1]. Mike Bayer went through this >> and suggested having a look at baked queries and also submitted a sketch >> of his proposal [2]. > > > Neutron relies heavily on a big JOIN query that returns just one row. In the > profiling, it seemed like joined eager loading overhead is significant. > Someone independently opened an upstream issue at > https://bitbucket.org/zzzeek/sqlalchemy/issues/3915/performance-degradation-on-version-10xx#comment-34442856 > with similar comments. > > While the "baked" query thing is the ultimate hammer for "ORM SQL building" > overhead, it's a very heavy hammer to swing as folks will note in the gerrit > that shows roughly how it would look, it's involved and not that easy to > work with. > > Fortunately, the joined eager load codepaths here have never been optimized > for the "many short queries" use case, and a large portion of the overhead > is all rolled up into some SQL alias objects that can be memoized so that > most of the work they do happens once, instead of thousands of times. > > In https://gerrit.sqlalchemy.org/311 (note this is SQLAlchemy's gerrit, not > openstack's) I have a patch that reduces the overhead associated > specifically with joined eager loaded entities by around 270% for a > worst-case scenario (which Neutron seems to be close to). If those folks > running the load tests can please try this revision out and see if it makes > a dent, that would be helpful. > > Note that SQLAlchemy 1.1 has been out for about five months now, and it's > time that Openstack move up to 1.1 series - that's where the performance > enhancement will be. > > > >> >> I wanted to share these findings with you (probably most of you knew but >> I'm quite new to OpenStack so It's been a really nice exercise for me to >> better understand how things work) and gather your feedback about how >> things can be improved. Also, I'll be happy to share the results and >> discuss further if you think it's worth during the PTG next week. >> >> Thanks a lot for reading and apologies for such a long email! >> >> Cheers, >> Daniel >> IRC: dalvarez >> >> [0] http://imgur.com/WQqaiYQ >> [1] http://imgur.com/6KrfJUC >> [2] https://review.openstack.org/430973 >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The end of OpenStack packages in Debian?
On Wed, Feb 15, 2017 at 10:41 AM, Tobias Urdin <tobias.ur...@crystone.com> wrote: > On 02/15/2017 01:46 PM, Thomas Goirand wrote: >> Hi there, >> >> It's been a while since I planed on writing this message. I couldn't >> write it because the situation makes me really sad. At this point, it >> starts to be urgent to post it. >> >> As for many other folks, Mirantis decided to end its contract with me. >> This happened when I was the most successful doing the job, with all of >> the packaging CI moved to OpenStack infra at the end of the OpenStack >> Newton cycle, after we were able to release Newton this way. I was >> hoping to start packaging on every commit for Ocata. That's yet another >> reason for me to be very frustrated about all of this. Such is life... >> >> Over the last few months, I hoped for having enough strengths to >> continue my packaging work anyway, and get Ocata packages done. But >> that's not what happened. The biggest reason for this is that I know >> that this needs to be a full time job. And at this point, I still don't >> know what my professional future will be. A company, in Barcelona, told >> me I'd get hired to continue my past work of packaging OpenStack in >> Debian, but so far, I'm still waiting for a definitive answer, so I'm >> looking into some other opportunities. >> >> All this to say that, unless someone wants to hire me for it (which >> would be the best outcome, but I fear this wont happen), or if someone >> steps in (this seems unlikely at this point), both the packaging-deb and >> the faith of OpenStack packages in Debian are currently compromised. >> >> I will continue to maintain OpenStack Newton during the lifetime of >> Debian Stretch though, but I don't plan on doing anything more. This >> means that maybe, Newton will be the last release of OpenStack in >> Debian. If things continue this way, I probably will ask for the removal >> of all OpenStack packages from Debian Sid after Stretch gets released >> (unless I know that someone will do the work). >> >> As a consequence, the following projects wont get packages even in >> Ubuntu (as they were "community maintained", which means done by me and >> later sync into Ubuntu...): >> >> - congress >> - gnocchi >> - magnum >> - mistral >> - murano >> - sahara >> - senlin >> - watcher >> - zaqar >> >> Hopefully, Canonical will continue to maintain the other 15 (more >> core...) projects in UCA. >> >> Thanks for the fish, >> >> Thomas Goirand (zigo) >> >> P,S: To the infra folks: please keep the packaging CI as it is, as it >> will be useful for the lifetime of Stretch. >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > Somebody please hire Thomas, he's amazing! Heartily seconded!! Thanks, Dims > Thank you for everything! > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[kubernetes-users] Re: client-python Beta Release
FYI, OpenStack Magnum has switched over to client-python (from the older python-k8sclient maintained by some OpenStack folks). OpenStack Kuryr and Kolla-Kubernetes are going to use the python client real soon now. https://review.openstack.org/#/c/432421/ https://review.openstack.org/#/c/432409/ https://review.openstack.org/#/c/433981/ Thanks, Dims On Wed, Jan 25, 2017 at 8:34 PM, 'Mehdy Bohlool' via Kubernetes developer/contributor discussion <kubernetes-...@googlegroups.com> wrote: > Python client is now in beta. Please find more information here: > https://github.com/kubernetes-incubator/client-python/ > releases/tag/v1.0.0b1 > > You can reach the maintainers of this project at SIG API Machinery > <https://github.com/kubernetes/community/tree/master/sig-api-machinery>. > If you have any problem with the client or any suggestions, please file an > issue <https://github.com/kubernetes-incubator/client-python/issues>. > > > Mehdy Bohlool | Software Engineer | me...@google.com | mbohlool@github > <https://github.com/mbohlool> > > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes developer/contributor discussion" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-dev+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/kubernetes-dev/CACd0WeG3O1t%3DXt7AGykyK7CcLmVYyJAB918c% > 2BXvteqVrW3nb7A%40mail.gmail.com > <https://groups.google.com/d/msgid/kubernetes-dev/CACd0WeG3O1t%3DXt7AGykyK7CcLmVYyJAB918c%2BXvteqVrW3nb7A%40mail.gmail.com?utm_medium=email_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Davanum Srinivas :: https://twitter.com/dims -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
Re: [openstack-dev] [governance][tc][rally] Rally (Re: [rally][release] How rally release version)
Andrey, My apologies. Thanks for the clarifications. -- Dims On Mon, Feb 13, 2017 at 10:27 AM, Andrey Kurilin <akuri...@mirantis.com> wrote: > > > On Mon, Feb 13, 2017 at 4:49 PM, Davanum Srinivas <dava...@gmail.com> wrote: >> >> Andrey, >> >> It's a question, not a proposal. > > > Sorry, but your message doesn't sound like a question. It sounds like a > polite proposal. > >> >> If you don't do use releases repo, then rally information will be stale >> here: >> https://releases.openstack.org/ >> >> Here's why we have a release team and things we do: >> >> https://governance.openstack.org/tc/reference/projects/release-management.html >> >> https://specs.openstack.org/openstack-infra/infra-specs/specs/centralize-release-tagging.html >> http://docs.openstack.org/project-team-guide/release-management.html >> >> Since Rally is following the independent model, it has a whole lot of >> leeway: >> >> http://docs.openstack.org/project-team-guide/release-management.html#independent-release-model >> >> However the absolute minimum requirement is that the releases repo >> should be kept in sync. If that is too cumbersome, i don't know... >> > > Please re-read your first mail in the thread. It is not about synchronizing > release notes at all. You are > asking about throwing Rally project out from Big Tent due to ourdated info > posted at https://releases.openstack.org. > Seriusly? > > To finish this topic: > > - As a Rally PTL, I do not want to drop the project out of Big Tent. At > least for now. Who knows what will happen > when you will extend bureaucracy someday... > > - I'll update info at openstack/releases repo soon and will try to do it in > the right time while releasing new versions. > > - Rally follows the rules described by: > * > http://docs.openstack.org/project-team-guide/release-management.html#independent-release-model > * > http://docs.openstack.org/project-team-guide/release-management.html#release-process-for-other-projects > > > OpenStack projects following a cycle-independent model can ... push > signed tags by themselves. > > - There are no reasons to continue discussion dropping Rally. I can start a > ton of topics like "Drop Nova" with similar "real" > reasons. > > - I'm not against the work done by OpenStack Release team. I had a good > experience with that while working in not-Rally projects. > >> >> Thanks, >> Dims >> >> >> >> On Mon, Feb 13, 2017 at 9:15 AM, Andrey Kurilin <akuri...@mirantis.com> >> wrote: >> > Hi Dims! >> > >> > I do not want to say except question "why you are proposing to do >> > that?". >> > >> > I tried to find any rules about releasing at >> > https://governance.openstack.org, but I could not. >> > Please point me what rule I broke. >> > >> > On Mon, Feb 13, 2017 at 3:57 PM, Davanum Srinivas <dava...@gmail.com> >> > wrote: >> >> >> >> Andrey, Rally team, >> >> >> >> Do you want Rally to be dropped from Governance and Releases >> >> repository? >> >> >> >> Thanks, >> >> Dims >> >> >> >> On Mon, Feb 13, 2017 at 8:17 AM, Jeffrey Zhang >> >> <zhang.lei@gmail.com> >> >> wrote: >> >> > @Andrey, thanks for the explanation. >> >> > >> >> > The issue is: how can i know which tag works with certain OpenStack >> >> > branch? >> >> > For example, which tag >> >> > works with OpenStack Ocata release? There is no place recording this. >> >> > >> >> > I also found there are some other project do not use >> >> > "project/releases" >> >> > project. May they are using >> >> > the same solution as rally. >> >> > >> >> > On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin >> >> > <akuri...@mirantis.com> >> >> > wrote: >> >> >> >> >> >> Hi Jeffrey, >> >> >> >> >> >> Rally team do not use "releases" repo at all, that is why >> >> >> information >> >> >> at >> >> >> [2] is outdated. >> >> >> Our release workflow is making a proper tag and pushing it via >> >> >> Gerrit. >> >> >> I >> >> >> find it more co
Re: [openstack-dev] [rally][release] How rally release version
To add, please consider appointing a CPL to coordinate the update to the releases/ repo: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management Thanks, Dims On Mon, Feb 13, 2017 at 9:15 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Andrey Kurilin's message of 2017-02-13 12:14:31 +0200: >> Hi Jeffrey, >> >> Rally team do not use "releases" repo at all, that is why information at >> [2] is outdated. >> Our release workflow is making a proper tag and pushing it via Gerrit. I >> find it more convenient. > > Please propose an update to openstack/releases to either update the > history information for Rally's releases or to delete the relevant file > entirely to avoid confusion. > > Doug > >> >> >> >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com> >> wrote: >> >> > Hey guys, >> > >> > I found rally already releases its 0.8.1 tag from[0][1]. But >> > I found nothing in openstack/releases project[2]. How rally >> > create tag? >> > >> > [0] http://tarballs.openstack.org/rally/ >> > [1] https://github.com/openstack/rally/releases >> > [2] https://github.com/openstack/releases/blob/master/deliverables/_ >> > independent/rally.yaml#L45 >> > >> > -- >> > Regards, >> > Jeffrey Zhang >> > Blog: http://xcodest.me >> > >> > __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [governance][tc][rally] Rally (Re: [rally][release] How rally release version)
Andrey, It's a question, not a proposal. If you don't do use releases repo, then rally information will be stale here: https://releases.openstack.org/ Here's why we have a release team and things we do: https://governance.openstack.org/tc/reference/projects/release-management.html https://specs.openstack.org/openstack-infra/infra-specs/specs/centralize-release-tagging.html http://docs.openstack.org/project-team-guide/release-management.html Since Rally is following the independent model, it has a whole lot of leeway: http://docs.openstack.org/project-team-guide/release-management.html#independent-release-model However the absolute minimum requirement is that the releases repo should be kept in sync. If that is too cumbersome, i don't know... Thanks, Dims On Mon, Feb 13, 2017 at 9:15 AM, Andrey Kurilin <akuri...@mirantis.com> wrote: > Hi Dims! > > I do not want to say except question "why you are proposing to do that?". > > I tried to find any rules about releasing at > https://governance.openstack.org, but I could not. > Please point me what rule I broke. > > On Mon, Feb 13, 2017 at 3:57 PM, Davanum Srinivas <dava...@gmail.com> wrote: >> >> Andrey, Rally team, >> >> Do you want Rally to be dropped from Governance and Releases repository? >> >> Thanks, >> Dims >> >> On Mon, Feb 13, 2017 at 8:17 AM, Jeffrey Zhang <zhang.lei@gmail.com> >> wrote: >> > @Andrey, thanks for the explanation. >> > >> > The issue is: how can i know which tag works with certain OpenStack >> > branch? >> > For example, which tag >> > works with OpenStack Ocata release? There is no place recording this. >> > >> > I also found there are some other project do not use "project/releases" >> > project. May they are using >> > the same solution as rally. >> > >> > On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin <akuri...@mirantis.com> >> > wrote: >> >> >> >> Hi Jeffrey, >> >> >> >> Rally team do not use "releases" repo at all, that is why information >> >> at >> >> [2] is outdated. >> >> Our release workflow is making a proper tag and pushing it via Gerrit. >> >> I >> >> find it more convenient. >> >> >> >> >> >> >> >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang >> >> <zhang.lei@gmail.com> >> >> wrote: >> >>> >> >>> Hey guys, >> >>> >> >>> I found rally already releases its 0.8.1 tag from[0][1]. But >> >>> I found nothing in openstack/releases project[2]. How rally >> >>> create tag? >> >>> >> >>> [0] http://tarballs.openstack.org/rally/ >> >>> [1] https://github.com/openstack/rally/releases >> >>> [2] >> >>> >> >>> https://github.com/openstack/releases/blob/master/deliverables/_independent/rally.yaml#L45 >> >>> >> >>> -- >> >>> Regards, >> >>> Jeffrey Zhang >> >>> Blog: http://xcodest.me >> >>> >> >>> >> >>> >> >>> __ >> >>> OpenStack Development Mailing List (not for usage questions) >> >>> Unsubscribe: >> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>> >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Andrey Kurilin. >> >> >> >> >> >> __ >> >> OpenStack Development Mailing List (not for usage questions) >> >> Unsubscribe: >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> > >> > >> > >> > -- >> > Regards, >> > Jeffrey Zhang >> > Blog: http://xcodest.me >> > >> > >> > __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> >> -- >> Davanum Srinivas :: https://twitter.com/dims >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best regards, > Andrey Kurilin. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [governance][tc][rally] Rally (Re: [rally][release] How rally release version)
Andrey, Rally team, Do you want Rally to be dropped from Governance and Releases repository? Thanks, Dims On Mon, Feb 13, 2017 at 8:17 AM, Jeffrey Zhang <zhang.lei@gmail.com> wrote: > @Andrey, thanks for the explanation. > > The issue is: how can i know which tag works with certain OpenStack branch? > For example, which tag > works with OpenStack Ocata release? There is no place recording this. > > I also found there are some other project do not use "project/releases" > project. May they are using > the same solution as rally. > > On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin <akuri...@mirantis.com> > wrote: >> >> Hi Jeffrey, >> >> Rally team do not use "releases" repo at all, that is why information at >> [2] is outdated. >> Our release workflow is making a proper tag and pushing it via Gerrit. I >> find it more convenient. >> >> >> >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com> >> wrote: >>> >>> Hey guys, >>> >>> I found rally already releases its 0.8.1 tag from[0][1]. But >>> I found nothing in openstack/releases project[2]. How rally >>> create tag? >>> >>> [0] http://tarballs.openstack.org/rally/ >>> [1] https://github.com/openstack/rally/releases >>> [2] >>> https://github.com/openstack/releases/blob/master/deliverables/_independent/rally.yaml#L45 >>> >>> -- >>> Regards, >>> Jeffrey Zhang >>> Blog: http://xcodest.me >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Best regards, >> Andrey Kurilin. >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] nova-docker deleted from github
Debdipta, github is merely a mirror. Over the last 2 years, multiple messages have gone to -dev@ and -operators@ mailing list about nova-docker not having a core team and that we needed one to keep it going. So we had to shutdown the shop on it: http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project Please feel free to use the older branches from git.openstack.org: https://git.openstack.org/cgit/openstack/nova-docker/ Since nova-docker is under Apache license, please feel free to maintain a fork on github if you choose (and i can redirect people to your fork). Thanks, Dims On Mon, Feb 13, 2017 at 1:46 AM, Debdipta Ghosh <debdipta1...@gmail.com> wrote: > Hello Devanum, > > I just noticed you have deleted nova-docker from github. I understand a lot > projects like magnum forked from nova-docker and there was no need to add > new code here. > > Still I think, there was no cost involved if there some code hosted on > github. > Can you revert back your changes? > > Thanking you, > Debdipta > > Think before you print Go Green, Reduce, Reuse & Recycle > > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] nova-docker deleted from github
Debdipta, github is merely a mirror. Over the last 2 years, multiple messages have gone to -dev@ and -operators@ mailing list about nova-docker not having a core team and that we needed one to keep it going. So we had to shutdown the shop on it: http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project Please feel free to use the older branches from git.openstack.org: https://git.openstack.org/cgit/openstack/nova-docker/ Since nova-docker is under Apache license, please feel free to maintain a fork on github if you choose (and i can redirect people to your fork). Thanks, Dims On Mon, Feb 13, 2017 at 1:46 AM, Debdipta Ghosh <debdipta1...@gmail.com> wrote: > Hello Devanum, > > I just noticed you have deleted nova-docker from github. I understand a lot > projects like magnum forked from nova-docker and there was no need to add > new code here. > > Still I think, there was no cost involved if there some code hosted on > github. > Can you revert back your changes? > > Thanking you, > Debdipta > > Think before you print Go Green, Reduce, Reuse & Recycle > > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][kuryr] python-k8sclient vs client-python (was Fwd: client-python Beta Release)
Dear Magnum Team, Please see review: https://review.openstack.org/#/c/432421/ It depends on the requirements review: https://review.openstack.org/#/c/432409/ Thanks, Dims On Mon, Jan 30, 2017 at 11:54 AM, Antoni Segura Puimedon <celeb...@gmail.com > wrote: > > > On Thu, Jan 26, 2017 at 12:41 PM, Davanum Srinivas <dava...@gmail.com> > wrote: > >> Team, >> >> A bit of history, we had a client generated from swagger definition for a >> while in Magnum, we plucked it out into python-k8sclient which then got >> used by fuel-ccp, kuryr etc. Recently the kuberneted team started an effort >> called client-python. Please see 1.0.0b1 announcement. >> >> * It's on pypi[1] and readthedocs[2] >> * i've ported the e2e tests in python-k8sclient that runs against an >> actual k8s setup and got that working >> * i've looked at various tests in kuryr, fuel-ccp, magnum etc to see what >> could be ported as well. most of it is merged already. i have a couple of >> things in progress >> >> So, when client-python hits 1.0.0, Can we please mothball our >> python-k8sclient and switch over to the k8s community supported option? >> Can you please evaluate what's missing so we can make sure those things >> get into 1.0.0 final? >> > > I am all for this. Thanks for the good work Davanum! I think this is a > perfect case where the OpenStack Community can give back to other upstream > communities and we should improve client-python where we need. > > >> >> Thanks, >> Dims >> >> [1] https://pypi.python.org/pypi/kubernetes >> [2] http://kubernetes.readthedocs.io/en/latest/kubernetes.html >> >> -- Forwarded message -- >> From: 'Mehdy Bohlool' via Kubernetes developer/contributor discussion < >> kubernetes-...@googlegroups.com> >> Date: Wed, Jan 25, 2017 at 8:34 PM >> Subject: client-python Beta Release >> To: Kubernetes developer/contributor discussion < >> kubernetes-...@googlegroups.com>, kubernetes-us...@googlegroups.com >> >> >> Python client is now in beta. Please find more information here: >> https://github.com/kubernetes-incubator/client-python/ >> releases/tag/v1.0.0b1 >> >> You can reach the maintainers of this project at SIG API Machinery >> <https://github.com/kubernetes/community/tree/master/sig-api-machinery>. >> If you have any problem with the client or any suggestions, please file an >> issue <https://github.com/kubernetes-incubator/client-python/issues>. >> >> >> Mehdy Bohlool | Software Engineer | me...@google.com | mbohlool@github >> <https://github.com/mbohlool> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Kubernetes developer/contributor discussion" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-dev+unsubscr...@googlegroups.com. >> To post to this group, send email to kubernetes-...@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/kubernetes-dev/CACd0WeG3O1t%3DXt7AGykyK7CcLmVYyJAB918c%2 >> BXvteqVrW3nb7A%40mail.gmail.com >> <https://groups.google.com/d/msgid/kubernetes-dev/CACd0WeG3O1t%3DXt7AGykyK7CcLmVYyJAB918c%2BXvteqVrW3nb7A%40mail.gmail.com?utm_medium=email_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Davanum Srinivas :: https://twitter.com/dims >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [fuel][release] Opting out of Ocata?
Dear Fuel Team, There have been no releases for fuel-* projects in the Ocata time frame: https://git.openstack.org/cgit/openstack/releases/tree/deliverables/ocata Fuel projects under governance are supposed to be following the "cycle-trailing" schedule: https://releases.openstack.org/reference/release_models.html#cycle-trailing Please see Ocata schedule: https://releases.openstack.org/ocata/schedule.html#o-trailing Is anyone still around keeping the lights on? Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Final mascot
Reminded me of the indian traditional colored patterns :) https://www.google.com/search?q=rangoli+star=lnms=isch https://www.google.com/search?tbm=isch=1=rangoli -- Dims On Fri, Feb 3, 2017 at 6:03 AM, John Garbutt <j...@johngarbutt.com> wrote: > On 3 February 2017 at 02:59, Matt Riedemann <mriede...@gmail.com> wrote: >> The Foundation wants to have the mascots finalized before the PTG. This is >> just an opportunity for people to raise issues with it if they have any. > > Honestly it looks a bit aggressive / sharp / pointy. > Maybe less spikes on the outside? I duno. > > But asking for a friendlier looking supernova seems a bit... unscientific. > > John > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] gate jobs - papercuts
Thanks Melanie! Since the last report 4 hours ago, the ServersNegativeTestJSON failed 8 more times. Is the following one of the libvirt ones? http://logs.openstack.org/24/425924/2/gate/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/f1b9229/logs/testr_results.html.gz tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2 Thanks, Dims On Wed, Feb 1, 2017 at 12:29 PM, melanie witt <melwi...@gmail.com> wrote: > On Wed, 1 Feb 2017 08:06:41 -0500, Davanum Srinivas wrote: >> >> Three more from this morning, at least the first one looks new: >> >> >> http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/testr_results.html.gz >> tempest.api.compute.images.test_list_image_filters >> >> >> http://logs.openstack.org/99/420299/3/gate/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/6e8d208/logs/testr_results.html.gz >> >> http://logs.openstack.org/23/427223/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/18e635a/logs/testr_results.html.gz >> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON > > > The last two are https://launchpad.net/bugs/1660878 being worked on here > https://review.openstack.org/#/c/427775 > > -melanie > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New driver project status?
Neil, No, this has not reached a conclusion. There are 4 competing proposals https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:formal-vote+driver-teams -- Dims On Wed, Feb 1, 2017 at 9:21 AM, Neil Jerram <n...@tigera.io> wrote: > I believe there was recently a discussion on one of the OpenStack MLs about > a possible new status for driver projects. Unfortunately I'm not > immediately managing to find it in the archives. > > Did that discussion reach a conclusion, and - if so - is that documented > somewhere? > > Thanks, > Neil > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] gate jobs - papercuts
MattR, Three more from this morning, at least the first one looks new: http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/testr_results.html.gz tempest.api.compute.images.test_list_image_filters http://logs.openstack.org/99/420299/3/gate/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/6e8d208/logs/testr_results.html.gz http://logs.openstack.org/23/427223/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/18e635a/logs/testr_results.html.gz tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON Thanks, Dims On Tue, Jan 31, 2017 at 10:23 PM, Matt Riedemann <mriede...@gmail.com> wrote: > On 1/31/2017 11:49 AM, Davanum Srinivas wrote: >> >> Folks, >> >> Here's the list of job failures that failed in the gate queue. >> captured with my script[1][2] since around 10:00 AM today. All jobs >> failed with just one bad test. >> >> >> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/ >>- >> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON >> >> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/ >> - tempest.api.compute.admin.test_servers.ServersAdminTestJSON >> >> http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/ >>- tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON >> >> http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/ >> - >> tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON >> >> http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/ >>- keystone.tests.unit.test_v3_auth.TestMFARules >> >> http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/ >> - tempest.api.compute.admin.test_servers.ServersAdminTestJSON >> >> http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/ >>- >> tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps >> >> So our gate is now 36 deep with stuff running for little more than 4 >> hours repeatedly Can folks look deeper please? >> >> Thanks, >> Dims >> >> [1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e >> [2] http://paste.openstack.org/show/597071/ >> > > I've identified a regression in nova here: > > https://bugs.launchpad.net/nova/+bug/1660878 > > -- > > Thanks, > > Matt Riedemann > > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] gate jobs - papercuts
Thanks MattT, MattR and Steve. Since that last update 4 runs failed http://logs.openstack.org/20/396620/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/e82ace8/ * tempest.api.compute.admin.test_migrations.MigrationsAdminTest - test_resize_server_revert_deleted_flavor * tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON - test_create_list_show_delete_interfaces http://logs.openstack.org/45/423645/19/gate/gate-grenade-dsvm-neutron-dvr-multinode-ubuntu-xenial/61dbd0e/ http://logs.openstack.org/45/423645/19/gate/gate-grenade-dsvm-neutron-dvr-multinode-ubuntu-xenial/61dbd0e/ * Both runs failed with the following "Failed to fetch http://mirror.regionone.osic-cloud1.openstack.org/ubuntu/pool/main/o/openssl/openssl_1.0.2g-1ubuntu4.6_amd64.deb; * http://logs.openstack.org/04/427004/2/gate/gate-keystone-python35-db/1502dbe/console.html 35 mins of zero logs and then timed out Thanks, Dims On Tue, Jan 31, 2017 at 3:32 PM, Matt Riedemann <mriede...@gmail.com> wrote: > On 1/31/2017 11:49 AM, Davanum Srinivas wrote: >> >> Folks, >> >> Here's the list of job failures that failed in the gate queue. >> captured with my script[1][2] since around 10:00 AM today. All jobs >> failed with just one bad test. >> >> >> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/ >>- >> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON >> >> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/ >> - tempest.api.compute.admin.test_servers.ServersAdminTestJSON >> >> http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/ >>- tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON >> >> http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/ >> - >> tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON >> >> http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/ >>- keystone.tests.unit.test_v3_auth.TestMFARules >> >> http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/ >> - tempest.api.compute.admin.test_servers.ServersAdminTestJSON >> >> http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/ >>- >> tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps >> >> So our gate is now 36 deep with stuff running for little more than 4 >> hours repeatedly Can folks look deeper please? >> >> Thanks, >> Dims >> >> [1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e >> [2] http://paste.openstack.org/show/597071/ >> > > I know of two issues impacting the cells v1 job, one of which is fixed, the > other has a patch recently posted. > > The first was one I posted about last night, total blocker for the cells v1 > job which was kicking things out of the gate for Nova, but that is fixed: > > https://review.openstack.org/#/c/427009/ > > The other one that's not fixed yet (was just identified today) has a patch > up now: > > https://review.openstack.org/#/c/427394/ > > -- > > Thanks, > > Matt Riedemann > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] gate jobs - papercuts
Folks, Here's the list of job failures that failed in the gate queue. captured with my script[1][2] since around 10:00 AM today. All jobs failed with just one bad test. http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/ - tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/ - tempest.api.compute.admin.test_servers.ServersAdminTestJSON http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/ - tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/ - tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/ - keystone.tests.unit.test_v3_auth.TestMFARules http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/ - tempest.api.compute.admin.test_servers.ServersAdminTestJSON http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/ - tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps So our gate is now 36 deep with stuff running for little more than 4 hours repeatedly Can folks look deeper please? Thanks, Dims [1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e [2] http://paste.openstack.org/show/597071/ -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][neutron][ffe] Jinja2 2.9.5 upper constraint
Matthew, Major, I am ok with just upper-constraints. If it were g-r then we would have to re-release 2 oslo libs at least. http://codesearch.openstack.org/?q=jinja2=fosho=.*require.*%5C.txt=oslo.middleware,oslo.reports Thanks, Dims On Mon, Jan 30, 2017 at 2:30 PM, Matthew Thode <prometheanf...@gentoo.org> wrote: > On 01/30/2017 11:55 AM, Major Hayden wrote: >> Hello there, >> >> I just submitted a patch[0] to bump Jinja2's upper constraint to 2.9.5. >> >> We previously set the upper constraint to 2.8.1[1] when a change appeared >> that broke Ansible. The bug caused the `groupby` filter to return a >> namedtuple and it was fixed later in 2.9.5, which was released[2] two days >> ago. Other than that bug, the 2.9.0-2.9.4 releases worked fine. >> >> Version 2.9.5 also contains two new tests[3] which are very helpful for the >> openstack-ansible-security role. >> >> Would it be possible to get the upper constraint for Jinja2 changed for >> Ocata? Thanks! >> >> [0] https://review.openstack.org/#/c/426857/ >> [1] https://review.openstack.org/#/c/418494/ >> [2] https://github.com/pallets/jinja/releases/tag/2.9.5 >> [3] https://github.com/pallets/jinja/pull/624 >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > This'll impact neutron as well and I'd like their ack on this. Though > it generally looks fine to me. > > -- > Matthew Thode (prometheanfire) > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [requirements][ffe] oslo.context 2.12.1 in upper-constraints
Team, We have a fix in oslo.context for the problem reported over the weekend: http://lists.openstack.org/pipermail/openstack-dev/2017-January/49.html A fix to disable warnings was merged into master, then cherry-picked to stable/ocata. Let's please update the upper-constraints with this new version. Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests
Graham, I've turned it essentially into a no-op now. i'll let the original authors debate the full revert and other implications. Thanks, Dims On Sun, Jan 29, 2017 at 3:42 PM, Hayes, Graham <graham.ha...@hpe.com> wrote: > On 29/01/2017 15:45, Davanum Srinivas wrote: >> Graham, Sławek, Joshua, >> >> Please take a look at my attempt: >> https://review.openstack.org/#/c/426576/ >> >> Thanks, >> Dims >> > > At this point, a full revert seems like the right idea. > > There is a few problem with the warning, not just the amount of them. > > Previously we have gone out of our way to avoid these issues in > libraries. (e.g. [1]) > > The stack level also seems wrong to me - it is pointing at the > consuming project not the oslo.context library. > > 1 - https://review.openstack.org/#/c/275914/ specifically > https://review.openstack.org/#/c/275914/3/oslo_versionedobjects/fields.py > L311. > >> On Sun, Jan 29, 2017 at 7:56 AM, Hayes, Graham <graham.ha...@hpe.com> wrote: >>> On 29/01/17 00:53, Davanum Srinivas wrote: >>>> Graham, Sławek, >>>> >>>> Have you seen this? >>>> >>>> Neutron has/uses a WarningFixture: >>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161 >>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70 >>>> >>>> Which uses filterwarnings: >>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80 >>>> >>>> Where "always" is being used: >>>> https://docs.python.org/2/library/warnings.html >>>> >>>> Which prints warnings every single time. >>>> >>>> So, can we please "fix" it in there quickly? >>>> >>>> Thanks, >>>> Dims >>> >>> This is still a broken release - previously in oslo libraries we have >>> been careful with issuing multiple warnings for a deprecation. >>> >>> This is still an issue, with glance-api [0] and I assume others (e.g. we >>> have not had a designate CI run with the new oslo.context yet) >>> >>> Seen as we are going into RC week, it seems very risky to keep it. >>> >>> 0 - >>> http://logstash.openstack.org/#dashboard/file/logstash.json?query=_id%3A%5C%22AVnnYuy3QVJYkPlRPEJH%5C%22 >>> >>>> On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński <sla...@kaplonski.pl> >>>> wrote: >>>>> Hello, >>>>> >>>>> Thanks. I just filled bug report to oslo project: >>>>> https://bugs.launchpad.net/oslo.context/+bug/1660088 >>>>> >>>>> -- >>>>> Best regards / Pozdrawiam >>>>> Sławek Kapłoński >>>>> sla...@kaplonski.pl >>>>> >>>>> On Sat, 28 Jan 2017, Hayes, Graham wrote: >>>>> >>>>>> On 28/01/17 20:54, Sławek Kapłoński wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I pushed today patch in Neutron to gerrit [1] and I noticed that >>>>>>> functional >>>>>>> tests are failing. In logs there is huge number of deprecation warnings >>>>>>> displayed [2]. Tests are failing because of global timeout is reached >>>>>>> and IMO >>>>>>> reason of this timeout is this huge amount of deprecation warnings. >>>>>>> I checked that those warnings are disaplyed when oslo.context==2.12.0 is >>>>>>> installed. With oslo.context==2.11.0 all is fine. >>>>>>> Should it be reported as bug in Neutron or in Oslo project? Or maybe You >>>>>>> already know about it and there is some patch to fix it but I couldn't >>>>>>> find it? >>>>>> >>>>>> Its an oslo.context bug - I can't see one filed for it yet. >>>>>>> >>>>>>> [1] https://review.openstack.org/#/c/426429/ >>>>>>> [2] >>>>>>> http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html >>>>>>> >>>>>> >>>>>> It looks like the warnings function was miss used - this should be set >>>>>> as a once only message. The stack trace level seems suspect, as it >>>>>> points as neutron/context.py as the one sending out the notice, not >>>>>> o
Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests
Graham, Sławek, Joshua, Please take a look at my attempt: https://review.openstack.org/#/c/426576/ Thanks, Dims On Sun, Jan 29, 2017 at 7:56 AM, Hayes, Graham <graham.ha...@hpe.com> wrote: > On 29/01/17 00:53, Davanum Srinivas wrote: >> Graham, Sławek, >> >> Have you seen this? >> >> Neutron has/uses a WarningFixture: >> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161 >> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70 >> >> Which uses filterwarnings: >> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80 >> >> Where "always" is being used: >> https://docs.python.org/2/library/warnings.html >> >> Which prints warnings every single time. >> >> So, can we please "fix" it in there quickly? >> >> Thanks, >> Dims > > This is still a broken release - previously in oslo libraries we have > been careful with issuing multiple warnings for a deprecation. > > This is still an issue, with glance-api [0] and I assume others (e.g. we > have not had a designate CI run with the new oslo.context yet) > > Seen as we are going into RC week, it seems very risky to keep it. > > 0 - > http://logstash.openstack.org/#dashboard/file/logstash.json?query=_id%3A%5C%22AVnnYuy3QVJYkPlRPEJH%5C%22 > >> On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński <sla...@kaplonski.pl> >> wrote: >>> Hello, >>> >>> Thanks. I just filled bug report to oslo project: >>> https://bugs.launchpad.net/oslo.context/+bug/1660088 >>> >>> -- >>> Best regards / Pozdrawiam >>> Sławek Kapłoński >>> sla...@kaplonski.pl >>> >>> On Sat, 28 Jan 2017, Hayes, Graham wrote: >>> >>>> On 28/01/17 20:54, Sławek Kapłoński wrote: >>>>> Hello, >>>>> >>>>> I pushed today patch in Neutron to gerrit [1] and I noticed that >>>>> functional >>>>> tests are failing. In logs there is huge number of deprecation warnings >>>>> displayed [2]. Tests are failing because of global timeout is reached and >>>>> IMO >>>>> reason of this timeout is this huge amount of deprecation warnings. >>>>> I checked that those warnings are disaplyed when oslo.context==2.12.0 is >>>>> installed. With oslo.context==2.11.0 all is fine. >>>>> Should it be reported as bug in Neutron or in Oslo project? Or maybe You >>>>> already know about it and there is some patch to fix it but I couldn't >>>>> find it? >>>> >>>> Its an oslo.context bug - I can't see one filed for it yet. >>>>> >>>>> [1] https://review.openstack.org/#/c/426429/ >>>>> [2] >>>>> http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html >>>>> >>>> >>>> It looks like the warnings function was miss used - this should be set >>>> as a once only message. The stack trace level seems suspect, as it >>>> points as neutron/context.py as the one sending out the notice, not >>>> oslo.contexts base class. >>>> >>>> [3] seems to the cause - I would suggest reverting this commit and >>>> doing a 2.13.0 release. This is going to be *really* noisy. (logstash >>>> has 2.5 million items for this string in the last 24 hours) >>>> >>>> 3 - >>>> https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea >>>> >>>> __ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Oslo] Huge number of deprecation warnings in functional tests
Graham, Sławek, Have you seen this? Neutron has/uses a WarningFixture: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/base.py#n161 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n70 Which uses filterwarnings: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/tools.py#n80 Where "always" is being used: https://docs.python.org/2/library/warnings.html Which prints warnings every single time. So, can we please "fix" it in there quickly? Thanks, Dims On Sat, Jan 28, 2017 at 6:46 PM, Sławek Kapłoński <sla...@kaplonski.pl> wrote: > Hello, > > Thanks. I just filled bug report to oslo project: > https://bugs.launchpad.net/oslo.context/+bug/1660088 > > -- > Best regards / Pozdrawiam > Sławek Kapłoński > sla...@kaplonski.pl > > On Sat, 28 Jan 2017, Hayes, Graham wrote: > >> On 28/01/17 20:54, Sławek Kapłoński wrote: >> > Hello, >> > >> > I pushed today patch in Neutron to gerrit [1] and I noticed that functional >> > tests are failing. In logs there is huge number of deprecation warnings >> > displayed [2]. Tests are failing because of global timeout is reached and >> > IMO >> > reason of this timeout is this huge amount of deprecation warnings. >> > I checked that those warnings are disaplyed when oslo.context==2.12.0 is >> > installed. With oslo.context==2.11.0 all is fine. >> > Should it be reported as bug in Neutron or in Oslo project? Or maybe You >> > already know about it and there is some patch to fix it but I couldn't >> > find it? >> >> Its an oslo.context bug - I can't see one filed for it yet. >> > >> > [1] https://review.openstack.org/#/c/426429/ >> > [2] >> > http://logs.openstack.org/29/426429/3/check/gate-neutron-dsvm-functional-ubuntu-xenial/7079dc5/console.html >> > >> >> It looks like the warnings function was miss used - this should be set >> as a once only message. The stack trace level seems suspect, as it >> points as neutron/context.py as the one sending out the notice, not >> oslo.contexts base class. >> >> [3] seems to the cause - I would suggest reverting this commit and >> doing a 2.13.0 release. This is going to be *really* noisy. (logstash >> has 2.5 million items for this string in the last 24 hours) >> >> 3 - >> https://github.com/openstack/oslo.context/commit/f25543fcc792ebf155728a91fde06e8dc4e96cea >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FFE][requirements] python-* clients from last 2 days
Dear Requirements Team, I've consolidated the changes to the upper-constraints into One single review: https://review.openstack.org/#/c/426116/ Thanks, Dims On Fri, Jan 27, 2017 at 5:58 AM, Davanum Srinivas <dava...@gmail.com> wrote: > Oops hit send too soon. > > Technically the release deadline was till today (27th) > https://releases.openstack.org/ocata/schedule.html > > If we have a release and do not have that in upper constraints and > hence haven't tested it, bad things can happen in the field. > > Thanks, > Dims > > On Fri, Jan 27, 2017 at 5:55 AM, Davanum Srinivas <dava...@gmail.com> wrote: >> Dear requirements team, >> >> Can you please allow the following to merge: >> https://review.openstack.org/#/q/owner:%22OpenStack+Proposal+Bot%22+status:open+project:openstack/requirements+branch:master+topic:new-release >> >> -- >> Davanum Srinivas :: https://twitter.com/dims > > > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FFE][requirements] python-* clients from last 2 days
Oops hit send too soon. Technically the release deadline was till today (27th) https://releases.openstack.org/ocata/schedule.html If we have a release and do not have that in upper constraints and hence haven't tested it, bad things can happen in the field. Thanks, Dims On Fri, Jan 27, 2017 at 5:55 AM, Davanum Srinivas <dava...@gmail.com> wrote: > Dear requirements team, > > Can you please allow the following to merge: > https://review.openstack.org/#/q/owner:%22OpenStack+Proposal+Bot%22+status:open+project:openstack/requirements+branch:master+topic:new-release > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [FFE][requirements] python-* clients from last 2 days
Dear requirements team, Can you please allow the following to merge: https://review.openstack.org/#/q/owner:%22OpenStack+Proposal+Bot%22+status:open+project:openstack/requirements+branch:master+topic:new-release -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] To rootwrap or piggyback privsep helpers?
Clint, Pike may be too soon :) as we need to make sure what we have in oslo.rootwrap/oslo.privsep work properly in py35. I saw some stuff i am still chasing. So the one after next will have my vote. -- Dims On Thu, Jan 26, 2017 at 9:55 AM, Clint Byrum <cl...@fewbar.com> wrote: > Excerpts from Thierry Carrez's message of 2017-01-26 10:08:52 +0100: >> Michael Still wrote: >> > I think #3 is the right call for now. The person we had working on >> > privsep has left the company, and I don't have anyone I could get to >> > work on this right now. Oh, and we're out of time. >> >> Yes, as much as I'm an advocate of privsep adoption, I don't think the >> last minutes before feature freeze are the best moment to introduce a >> single isolated privsep-backed command in Nova. So I'd recommend #3. >> >> In an ideal world, Nova would start migrating existing commands early in >> Pike so that in the near future, adding new privsep-backed commands >> doesn't feel so alien. >> > > Would it be too radical to propose the full migration of everything to > privsep as a Pike community goal? > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [magnum][kuryr] python-k8sclient vs client-python (was Fwd: client-python Beta Release)
Team, A bit of history, we had a client generated from swagger definition for a while in Magnum, we plucked it out into python-k8sclient which then got used by fuel-ccp, kuryr etc. Recently the kuberneted team started an effort called client-python. Please see 1.0.0b1 announcement. * It's on pypi[1] and readthedocs[2] * i've ported the e2e tests in python-k8sclient that runs against an actual k8s setup and got that working * i've looked at various tests in kuryr, fuel-ccp, magnum etc to see what could be ported as well. most of it is merged already. i have a couple of things in progress So, when client-python hits 1.0.0, Can we please mothball our python-k8sclient and switch over to the k8s community supported option? Can you please evaluate what's missing so we can make sure those things get into 1.0.0 final? Thanks, Dims [1] https://pypi.python.org/pypi/kubernetes [2] http://kubernetes.readthedocs.io/en/latest/kubernetes.html -- Forwarded message -- From: 'Mehdy Bohlool' via Kubernetes developer/contributor discussion < kubernetes-...@googlegroups.com> Date: Wed, Jan 25, 2017 at 8:34 PM Subject: client-python Beta Release To: Kubernetes developer/contributor discussion < kubernetes-...@googlegroups.com>, kubernetes-us...@googlegroups.com Python client is now in beta. Please find more information here: https://github.com/kubernetes-incubator/client-python/releases/tag/v1.0.0b1 You can reach the maintainers of this project at SIG API Machinery <https://github.com/kubernetes/community/tree/master/sig-api-machinery>. If you have any problem with the client or any suggestions, please file an issue <https://github.com/kubernetes-incubator/client-python/issues>. Mehdy Bohlool | Software Engineer | me...@google.com | mbohlool@github <https://github.com/mbohlool> -- You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/kubernetes-dev/CACd0WeG3O1t%3DXt7AGykyK7CcLmVYyJAB918c% 2BXvteqVrW3nb7A%40mail.gmail.com <https://groups.google.com/d/msgid/kubernetes-dev/CACd0WeG3O1t%3DXt7AGykyK7CcLmVYyJAB918c%2BXvteqVrW3nb7A%40mail.gmail.com?utm_medium=email_source=footer> . For more options, visit https://groups.google.com/d/optout. -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Move of openstack-salt project
Filip, Thanks for the announce. Can you please follow the steps below to retire the projects in openstack git repo? http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project Thanks, Dims On Wed, Jan 25, 2017 at 11:39 AM, Filip Pytloun <fi...@pytloun.cz> wrote: > Hello, > > I would like to announce migration of openstack-salt to join remaining > formulas of the ecosystem. > Since today, openstack-salt and other formulas are living at > github.com/salt-formulas. > > In the past few years this ecosystem has grown to more than 90 formulas > suitable for deployment of anything from base OS, CI/CD systems, IDM up > to complex systems like Openstack, Kubernetes and more. > > With this growt we believe that unifying location of all salt formulas > respecting same concepts and direction will make development and usage > simpler. Openstack formulas are only a small subset of this ecosystem so > it makes perfect sense to move them to join with the rest under one > project. > > Here are links to project resources, more are going to come soon.. > > Github: https://github.com/salt-formulas > Launchpad https://launchpad.net/salt-formulas > IRC: #salt-formulas @ irc.freenode.net > > Feel free to join and idle/discuss at IRC channel :-) > > Filip > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table
Cool. Then i'd support a backport when the review against master merges. Thanks Ann and Kirill. -- Dims On Tue, Jan 24, 2017 at 10:33 AM, Anna Taraday <akamyshnik...@mirantis.com> wrote: > Nope, this won't be necessary. > > 0.8.10 - allows us to create pk on alembic_version table automatically, but > only for new deployments. > > I propose manually add pk on this table if it is not existing. > > On Tue, Jan 24, 2017 at 7:25 PM Davanum Srinivas <dava...@gmail.com> wrote: >> >> Ann, >> >> Don't you still need alembic>=0.8.10 to be present? >> >> -- Dims >> >> On Tue, Jan 24, 2017 at 10:05 AM, Anna Taraday >> <akamyshnik...@mirantis.com> wrote: >> > We do not backport db changes, but if the existing migration does not >> > work >> > in certain circumstances, should not we fix it to make it work if it is >> > possible? >> > This will allow to deploy new deployments with Newton code on Galera. >> > >> > On Tue, Jan 24, 2017 at 6:45 PM Davanum Srinivas <dava...@gmail.com> >> > wrote: >> >> >> >> Please see >> >> >> >> http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines >> >> >> >> On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas <dava...@gmail.com> >> >> wrote: >> >> > Newton is already shipped! >> >> > >> >> > -- Dims >> >> > >> >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin >> >> > <kprosku...@mirantis.com> wrote: >> >> >> Galera only supported since Ocata? >> >> >> >> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas >> >> >> <dava...@gmail.com> >> >> >> wrote: >> >> >>> >> >> >>> Kirill, >> >> >>> >> >> >>> "If OS wants support Galera, it needs to comply with the Galera >> >> >>> requirements" <<< This is true for master/ocata NOT Newton. >> >> >>> >> >> >>> Ihar's response is perfectly acceptable thing to do for Newton in >> >> >>> the >> >> >>> community to highlight the possibility of this situation. >> >> >>> Downstream >> >> >>> folks can do what they need/have to do for Newton. >> >> >>> >> >> >>> Thanks, >> >> >>> Dims >> >> >>> >> >> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin >> >> >>> <kprosku...@mirantis.com> wrote: >> >> >>> > HI! >> >> >>> > >> >> >>> > Thing is, running Galera without enforcing it very bad idea for >> >> >>> > production >> >> >>> > use. Permissive mode was added more or less for testing purposes, >> >> >>> > running >> >> >>> > real production with it is dangerous, since it's not enforcing >> >> >>> > the >> >> >>> > mandatory >> >> >>> > Galera requirement, one of them is a "All tables must have a >> >> >>> > primary >> >> >>> > key". >> >> >>> > You cant disable a single check, you could only disable them all >> >> >>> > and >> >> >>> > this >> >> >>> > could lead to some serious problems, like data loss or >> >> >>> > corruption. >> >> >>> > >> >> >>> > If OS wants support Galera, it needs to comply with the Galera >> >> >>> > requirements. >> >> >>> > >> >> >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka >> >> >>> > <ihrac...@redhat.com> >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> An alternative could also be, for Newton and earlier, to release >> >> >>> >> a >> >> >>> >> note saying that operators should not run the code against >> >> >>> >> ENFORCING >> >> >>> >> galera mode. What are the reasons to enable that mode in >> >> >>> >>
Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table
Ann, Don't you still need alembic>=0.8.10 to be present? -- Dims On Tue, Jan 24, 2017 at 10:05 AM, Anna Taraday <akamyshnik...@mirantis.com> wrote: > We do not backport db changes, but if the existing migration does not work > in certain circumstances, should not we fix it to make it work if it is > possible? > This will allow to deploy new deployments with Newton code on Galera. > > On Tue, Jan 24, 2017 at 6:45 PM Davanum Srinivas <dava...@gmail.com> wrote: >> >> Please see >> http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines >> >> On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas <dava...@gmail.com> >> wrote: >> > Newton is already shipped! >> > >> > -- Dims >> > >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin >> > <kprosku...@mirantis.com> wrote: >> >> Galera only supported since Ocata? >> >> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas <dava...@gmail.com> >> >> wrote: >> >>> >> >>> Kirill, >> >>> >> >>> "If OS wants support Galera, it needs to comply with the Galera >> >>> requirements" <<< This is true for master/ocata NOT Newton. >> >>> >> >>> Ihar's response is perfectly acceptable thing to do for Newton in the >> >>> community to highlight the possibility of this situation. Downstream >> >>> folks can do what they need/have to do for Newton. >> >>> >> >>> Thanks, >> >>> Dims >> >>> >> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin >> >>> <kprosku...@mirantis.com> wrote: >> >>> > HI! >> >>> > >> >>> > Thing is, running Galera without enforcing it very bad idea for >> >>> > production >> >>> > use. Permissive mode was added more or less for testing purposes, >> >>> > running >> >>> > real production with it is dangerous, since it's not enforcing the >> >>> > mandatory >> >>> > Galera requirement, one of them is a "All tables must have a primary >> >>> > key". >> >>> > You cant disable a single check, you could only disable them all and >> >>> > this >> >>> > could lead to some serious problems, like data loss or corruption. >> >>> > >> >>> > If OS wants support Galera, it needs to comply with the Galera >> >>> > requirements. >> >>> > >> >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka >> >>> > <ihrac...@redhat.com> >> >>> > wrote: >> >>> >> >> >>> >> An alternative could also be, for Newton and earlier, to release a >> >>> >> note saying that operators should not run the code against >> >>> >> ENFORCING >> >>> >> galera mode. What are the reasons to enable that mode in OpenStack >> >>> >> scope that would not allow operators to live without it for another >> >>> >> cycle? >> >>> >> >> >>> >> Ihar >> >>> >> >> >>> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday >> >>> >> <akamyshnik...@mirantis.com> wrote: >> >>> >> > Hello everyone! >> >>> >> > >> >>> >> > Guys in our team faced an issue when they try to run alembic >> >>> >> > migrations >> >>> >> > on >> >>> >> > Galera with ENFORCING mode. [1] >> >>> >> > >> >>> >> > This was an issue with Alembic [2], which was quickly fixed by >> >>> >> > Mike >> >>> >> > Bayer >> >>> >> > (many thanks!) and new version of alembic was resealed [3]. >> >>> >> > The global requirements are updated [4]. >> >>> >> > >> >>> >> > I think that it is desired to fix this for Newton at least. We >> >>> >> > cannot >> >>> >> > bump >> >>> >> > requirements for Newton, so hot fix can be putting pk on this >> >>> >> > table >> >>> >> > in >> >>> >> > the >> >
Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table
Please see http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas <dava...@gmail.com> wrote: > Newton is already shipped! > > -- Dims > > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin > <kprosku...@mirantis.com> wrote: >> Galera only supported since Ocata? >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas <dava...@gmail.com> wrote: >>> >>> Kirill, >>> >>> "If OS wants support Galera, it needs to comply with the Galera >>> requirements" <<< This is true for master/ocata NOT Newton. >>> >>> Ihar's response is perfectly acceptable thing to do for Newton in the >>> community to highlight the possibility of this situation. Downstream >>> folks can do what they need/have to do for Newton. >>> >>> Thanks, >>> Dims >>> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin >>> <kprosku...@mirantis.com> wrote: >>> > HI! >>> > >>> > Thing is, running Galera without enforcing it very bad idea for >>> > production >>> > use. Permissive mode was added more or less for testing purposes, >>> > running >>> > real production with it is dangerous, since it's not enforcing the >>> > mandatory >>> > Galera requirement, one of them is a "All tables must have a primary >>> > key". >>> > You cant disable a single check, you could only disable them all and >>> > this >>> > could lead to some serious problems, like data loss or corruption. >>> > >>> > If OS wants support Galera, it needs to comply with the Galera >>> > requirements. >>> > >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka <ihrac...@redhat.com> >>> > wrote: >>> >> >>> >> An alternative could also be, for Newton and earlier, to release a >>> >> note saying that operators should not run the code against ENFORCING >>> >> galera mode. What are the reasons to enable that mode in OpenStack >>> >> scope that would not allow operators to live without it for another >>> >> cycle? >>> >> >>> >> Ihar >>> >> >>> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday >>> >> <akamyshnik...@mirantis.com> wrote: >>> >> > Hello everyone! >>> >> > >>> >> > Guys in our team faced an issue when they try to run alembic >>> >> > migrations >>> >> > on >>> >> > Galera with ENFORCING mode. [1] >>> >> > >>> >> > This was an issue with Alembic [2], which was quickly fixed by Mike >>> >> > Bayer >>> >> > (many thanks!) and new version of alembic was resealed [3]. >>> >> > The global requirements are updated [4]. >>> >> > >>> >> > I think that it is desired to fix this for Newton at least. We cannot >>> >> > bump >>> >> > requirements for Newton, so hot fix can be putting pk on this table >>> >> > in >>> >> > the >>> >> > first migration like proposed [5]. Any other ideas? >>> >> > >>> >> > [1] - https://bugs.launchpad.net/neutron/+bug/1655610 >>> >> > [2] - https://bitbucket.org/zzzeek/alembic/issues/406 >>> >> > [3] - >>> >> > >>> >> > http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10 >>> >> > [4] - https://review.openstack.org/#/c/423118/ >>> >> > [5] - https://review.openstack.org/#/c/419320/ >>> >> > >>> >> > >>> >> > -- >>> >> > Regards, >>> >> > Ann Taraday >>> >> > >>> >> > >>> >> > >>> >> > __ >>> >> > OpenStack Development Mailing List (not for usage questions) >>> >> > Unsubscribe: >>> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> > >>> >> >>> >> >>> >> ______ >
Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table
Newton is already shipped! -- Dims On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin <kprosku...@mirantis.com> wrote: > Galera only supported since Ocata? > > On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas <dava...@gmail.com> wrote: >> >> Kirill, >> >> "If OS wants support Galera, it needs to comply with the Galera >> requirements" <<< This is true for master/ocata NOT Newton. >> >> Ihar's response is perfectly acceptable thing to do for Newton in the >> community to highlight the possibility of this situation. Downstream >> folks can do what they need/have to do for Newton. >> >> Thanks, >> Dims >> >> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin >> <kprosku...@mirantis.com> wrote: >> > HI! >> > >> > Thing is, running Galera without enforcing it very bad idea for >> > production >> > use. Permissive mode was added more or less for testing purposes, >> > running >> > real production with it is dangerous, since it's not enforcing the >> > mandatory >> > Galera requirement, one of them is a "All tables must have a primary >> > key". >> > You cant disable a single check, you could only disable them all and >> > this >> > could lead to some serious problems, like data loss or corruption. >> > >> > If OS wants support Galera, it needs to comply with the Galera >> > requirements. >> > >> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka <ihrac...@redhat.com> >> > wrote: >> >> >> >> An alternative could also be, for Newton and earlier, to release a >> >> note saying that operators should not run the code against ENFORCING >> >> galera mode. What are the reasons to enable that mode in OpenStack >> >> scope that would not allow operators to live without it for another >> >> cycle? >> >> >> >> Ihar >> >> >> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday >> >> <akamyshnik...@mirantis.com> wrote: >> >> > Hello everyone! >> >> > >> >> > Guys in our team faced an issue when they try to run alembic >> >> > migrations >> >> > on >> >> > Galera with ENFORCING mode. [1] >> >> > >> >> > This was an issue with Alembic [2], which was quickly fixed by Mike >> >> > Bayer >> >> > (many thanks!) and new version of alembic was resealed [3]. >> >> > The global requirements are updated [4]. >> >> > >> >> > I think that it is desired to fix this for Newton at least. We cannot >> >> > bump >> >> > requirements for Newton, so hot fix can be putting pk on this table >> >> > in >> >> > the >> >> > first migration like proposed [5]. Any other ideas? >> >> > >> >> > [1] - https://bugs.launchpad.net/neutron/+bug/1655610 >> >> > [2] - https://bitbucket.org/zzzeek/alembic/issues/406 >> >> > [3] - >> >> > >> >> > http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10 >> >> > [4] - https://review.openstack.org/#/c/423118/ >> >> > [5] - https://review.openstack.org/#/c/419320/ >> >> > >> >> > >> >> > -- >> >> > Regards, >> >> > Ann Taraday >> >> > >> >> > >> >> > >> >> > ______ >> >> > OpenStack Development Mailing List (not for usage questions) >> >> > Unsubscribe: >> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > >> >> >> >> >> >> __ >> >> OpenStack Development Mailing List (not for usage questions) >> >> Unsubscribe: >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> > -- >> > Best regards, >> > Proskurin Kirill >> > >> > >> > __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> >> -- >> Davanum Srinivas :: https://twitter.com/dims >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best regards, > Proskurin Kirill > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table
Kirill, "If OS wants support Galera, it needs to comply with the Galera requirements" <<< This is true for master/ocata NOT Newton. Ihar's response is perfectly acceptable thing to do for Newton in the community to highlight the possibility of this situation. Downstream folks can do what they need/have to do for Newton. Thanks, Dims On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin <kprosku...@mirantis.com> wrote: > HI! > > Thing is, running Galera without enforcing it very bad idea for production > use. Permissive mode was added more or less for testing purposes, running > real production with it is dangerous, since it's not enforcing the mandatory > Galera requirement, one of them is a "All tables must have a primary key". > You cant disable a single check, you could only disable them all and this > could lead to some serious problems, like data loss or corruption. > > If OS wants support Galera, it needs to comply with the Galera requirements. > > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka <ihrac...@redhat.com> > wrote: >> >> An alternative could also be, for Newton and earlier, to release a >> note saying that operators should not run the code against ENFORCING >> galera mode. What are the reasons to enable that mode in OpenStack >> scope that would not allow operators to live without it for another >> cycle? >> >> Ihar >> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday >> <akamyshnik...@mirantis.com> wrote: >> > Hello everyone! >> > >> > Guys in our team faced an issue when they try to run alembic migrations >> > on >> > Galera with ENFORCING mode. [1] >> > >> > This was an issue with Alembic [2], which was quickly fixed by Mike >> > Bayer >> > (many thanks!) and new version of alembic was resealed [3]. >> > The global requirements are updated [4]. >> > >> > I think that it is desired to fix this for Newton at least. We cannot >> > bump >> > requirements for Newton, so hot fix can be putting pk on this table in >> > the >> > first migration like proposed [5]. Any other ideas? >> > >> > [1] - https://bugs.launchpad.net/neutron/+bug/1655610 >> > [2] - https://bitbucket.org/zzzeek/alembic/issues/406 >> > [3] - >> > http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10 >> > [4] - https://review.openstack.org/#/c/423118/ >> > [5] - https://review.openstack.org/#/c/419320/ >> > >> > >> > -- >> > Regards, >> > Ann Taraday >> > >> > >> > __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best regards, > Proskurin Kirill > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Announcing my PTL candidacy for Pike
+1 to "mentoring people that are newer to Nova but are stepping into leadership positions" Matt. Thanks, Dims On Mon, Jan 23, 2017 at 1:54 PM, Matt Riedemann <mriede...@gmail.com> wrote: > Hi everyone, > > This is my self-nomination to continue running as Nova PTL for the Pike > cycle. > > If elected, this would be a third term for me as Nova PTL. In Ocata I > thought that I did a better job of keeping on top of a broader set of > efforts than I was able to in Newton, including several non-priority > vendor-specific blueprints. > > I have also tried to make regular communication a priority. The topics vary, > but in general I try to keep people informed about the release schedule, > upcoming deadlines, areas that need attention, and recaps of smaller group > discussions back to the wider team. We have a widely distributed team and a > lot of groups are impacted by decisions made within Nova so it's important > to continue with that communication. Despite my best efforts I have also > learned in Ocata that we need to get earlier feedback on changes which > impact deployment tooling, and make documentation of such changes a high > priority earlier in the development of new features so that people working > on tooling are not left in the dark. > > Ocata has been a tough release, and I think we knew that was going to be the > case going in. It was a shorter cycle but still had some very high-priority > and high-visibility work items such as integrating the placement service > with the scheduler and further integrating support for cells v2, along with > making both of those required in a Nova deployment for Ocata. We also had to > deal with losing some key people and filling those spots. But people have > stepped up and we still made some incredible progress in Ocata despite the > difficulties. > > For Pike I want to focus on the following: > > * Continue integration of the placement service into making scheduling > decisions, including working with Neutron routed networks and work on > defining traits for resource providers so we can model the qualitative > aspects of resources in making placement decisions. > > * Continue working on cells v2 for multi-cell support including > investigating the concept of auto-registration of compute nodes to simplify > deployment automation, and also focus on multi-cell testing and Searchlight > integration. > > * Work on volume multi-attach support with the new Cinder v3 APIs introduced > in Ocata for creating and deleting volume attachments. I think we are > finally at a place where we can make some solid progress on the Nova side > with improved understanding between the Nova and Cinder teams. > > * There are going to be several efforts going on across several projects in > the Pike release, including modeling capabilities in the REST API, and Nova > is going to have to be a part of those efforts. We also need to get teams > together to figure out what are the issues with hierarchical quotas and what > progress can be made there since that is a high priority item that lots of > operators have been requesting for a long time. > > In general, we are going to have to improve our review throughput, > especially given the change in resources we experienced in Ocata. To me, a > lot of this will have to do with mentoring people that are newer to Nova but > are stepping into leadership positions, and having a shorter feedback loop > on "leveling up". > > To summarize, I aim to be of service to those using and contributing to Nova > and want to continue doing that in the PTL role for the project in the Pike > release if you will have me for another round. > > Thank you for your consideration, > > Matt > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice
"keystoneauth1 >= 2.17.0" implies python-novaclient with your fix will work for any version including 2.17.0 which is not true. you need to either do "keystoneauth1 >= 2.18.0" or "keystoneauth1 > 2.17.0" and we prefer the ">=" notation i think. Thanks, Dims On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek <abhishek.kek...@nttdata.com> wrote: > Hi Dims, > > Thank you for reply. I will propose a patch soon. Just for curiosity, > keystoneauth1 >= 2.17.0 will not install 2.18.0? > > Abhishek > > From: Davanum Srinivas <dava...@gmail.com> > Sent: Saturday, January 21, 2017 8:27:56 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ > python-cinderclient][ python-neutronclient] Remove x-openstack-request-id > logging code as it is logged twice > > Abhishek, > > 1) requirements.txt for all 4 python-*client you mentioned have > "keystoneauth1>=2.17.0", > 2) i do not see a review request to bump the minimum version in global > requirements for keystoneauth1 to "keystoneauth1>=2.18.0" > (https://review.openstack.org/#/q/project:openstack/requirements+is:open) > > Can you please file one? > > Thanks, > Dims > > > On Fri, Jan 20, 2017 at 12:52 AM, Kekane, Abhishek > <abhishek.kek...@nttdata.com> wrote: >> Hi Devs, >> >> >> >> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is >> logged >> for every HTTP response. This keystoneauth1 version will be used for >> ocata. >> >> The same request id is also logged in 'request' method of SessionClient >> class for python-novaclient, python-glanceclient, python-cinderclient and >> python-neutronclient. Once requirements.txt is synced with >> global-requirements and it uses keystoneauth1 version 2.18.0 and above, >> x-openstack-request-id will be logged twice for these clients. >> >> >> >> I have submitted patches for python-novaclient [1] and python-glanceclient >> [2] and created patches for python-cinderclient and python-neutronclient >> but >> same will not be reviewed unless and until the requirements.txt is synced >> with global-requirements and it uses keystoneauth1 version 2.18.0. >> >> >> >> As final releases for client libraries are scheduled in the next week >> (between Jan 23 - Jan 27) we want to address these issues in the above >> mentioned clients. >> >> >> >> Please let us know your opinion about the same. >> >> >> >> [1] https://review.openstack.org/422602 >> >> [2] https://review.openstack.org/422591 >> >> >> __ >> Disclaimer: This email and any attachments are sent in strictest >> confidence >> for the sole use of the addressee and may contain legally privileged, >> confidential, and proprietary data. If you are not the intended recipient, >> please advise the sender by replying promptly to this email and then >> delete >> and destroy this email and any attachments without any further use, >> copying >> or forwarding. >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > Disclaimer: This email and any attachments are sent in strictest confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then delete > and destroy this email and any attachments without any further use, copying > or forwarding. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice
Abhishek, 1) requirements.txt for all 4 python-*client you mentioned have "keystoneauth1>=2.17.0", 2) i do not see a review request to bump the minimum version in global requirements for keystoneauth1 to "keystoneauth1>=2.18.0" (https://review.openstack.org/#/q/project:openstack/requirements+is:open) Can you please file one? Thanks, Dims On Fri, Jan 20, 2017 at 12:52 AM, Kekane, Abhishek <abhishek.kek...@nttdata.com> wrote: > Hi Devs, > > > > In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is logged > for every HTTP response. This keystoneauth1 version will be used for ocata. > > The same request id is also logged in 'request' method of SessionClient > class for python-novaclient, python-glanceclient, python-cinderclient and > python-neutronclient. Once requirements.txt is synced with > global-requirements and it uses keystoneauth1 version 2.18.0 and above, > x-openstack-request-id will be logged twice for these clients. > > > > I have submitted patches for python-novaclient [1] and python-glanceclient > [2] and created patches for python-cinderclient and python-neutronclient but > same will not be reviewed unless and until the requirements.txt is synced > with global-requirements and it uses keystoneauth1 version 2.18.0. > > > > As final releases for client libraries are scheduled in the next week > (between Jan 23 - Jan 27) we want to address these issues in the above > mentioned clients. > > > > Please let us know your opinion about the same. > > > > [1] https://review.openstack.org/422602 > > [2] https://review.openstack.org/422591 > > > __ > Disclaimer: This email and any attachments are sent in strictest confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then delete > and destroy this email and any attachments without any further use, copying > or forwarding. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][stable] nominating Alan Pevec (apevec) for stable release core
+1 from me. welcome Alan On Wed, Jan 18, 2017 at 9:16 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Based on Tony's recommendation, and Alan's recent review work, I > am nominating Alan Pevec (apevec) to have core reviewer rights on > stable releases in the openstack/releases repository. > > Release team, please either +1 or raise any concerns you have. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][ptl] not planning to serve as release PTL for Pike
Many thanks for all the automation and all other initiatives Doug! On Fri, Jan 13, 2017 at 3:00 PM, Doug Hellmann <d...@doughellmann.com> wrote: > I announced this at the release team meeting on 6 Jan, but thought > I should also post to the list as well: I do not plan to serve as > the Release Management team PTL for the Pike release cycle. > > It has been my pleasure to serve as PTL, and we've almost finished > the automation work that I envisioned when I joined the team. Now > I would like to shift my focus to some other projects within the > community. I will still be an active member of the Release Management > team, helping with new initiatives and reviews for releases. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] The py35 functional nova CI job failures
Matt, Hoping this works - https://review.openstack.org/#/c/419250/ -- Dims On Wed, Jan 11, 2017 at 10:04 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > The gate-nova-tox-db-functional-py35-ubuntu-xenial job was recently added as > non-voting to the nova check queue but I see that it's got a 100% failure > rate. These are the tests that are failing: > > http://logs.openstack.org/07/282407/21/check/gate-nova-tox-db-functional-py35-ubuntu-xenial/c689c27/testr_results.html.gz > > Is there a patch up to fix or skip/blacklist these because if not we're just > burning resources on a job that's totally busted which I'd rather no be > doing as we head into feature freeze and the o-3 milestone. > > -- > > Thanks, > > Matt Riedemann > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][ptls][goals] python3 devstack+functional tests
Team, To recap: * We have devstack/devstack-gate/tempest/rally have all gotten updates to support python 3.5 * We have a bunch of jobs already running as non-voting against master branches: gate-devstack-dsvm-py35-updown-ubuntu-xenial-nv gate-rally-dsvm-py35-cinder-nv gate-rally-dsvm-py35-glance-nv gate-heat-dsvm-functional-orig-mysql-lbaasv2-py35-ubuntu-xenial-nv gate-keystone-dsvm-py35-functional-v3-only-ubuntu-xenial-nv gate-rally-dsvm-py35-neutron-neutron-ubuntu-xenial-nv gate-nova-tox-db-functional-py35-ubuntu-xenial gate-rally-dsvm-py35-rally-nova-nv * Work is being tracked at https://etherpad.openstack.org/p/support-python3.5-functional-tests please use that to coordinate It should now be easy quickly define new jobs and to spot what fails under python3.5. Hope this exercise over the last 2 weeks will help us all with our collective Pike goal. It's time to turn this over to all the individual projects. Please don't hesitate to ping me if you need a hand with something. Thanks, Dims On Sun, Jan 8, 2017 at 2:27 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Folks, > > Here's where we track the work for a little while: > https://etherpad.openstack.org/p/support-python3.5-functional-tests > > There's lots of work to be done to get stuff working properly. What we > have now is the ability to just startup a bunch of services using > py35. Does not mean they all work. > > Teams that do not have functional tests in their own projects may > still be able to look for, find and fix bugs. Example, the heat > functional tests exercises Nova, Oslo etc. So look for tracebacks > there and get going! > > This is a good chance for newbies to get involved as well. Find a > traceback to fix, propose a fix with a python3 unit test :) > > Thanks, > Dims > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?
Mehdi, I'd support switching g-r to make oslo.messaging work. period. This is dragged on way too long. Thanks, Dims On Wed, Jan 11, 2017 at 2:25 AM, Mehdi Abaakouk <sil...@sileht.net> wrote: > The library final release is really soon, and we are still blocked on > this topic. If this is not solved, we will release one more time an > unusable driver in oslo.messging. > > I want to remember that people current uses the kafka driver in > production with 'downstream patches' ready since 1 years to make it > works. > > We recently remove the kafka dep from oslo.messaging to be able to merge > some of these patches. But we can't untag the experimental flag of > this driver until the dependency issue is solved. > > So what can we do to unblock this situation ? > > > On Fri, Jan 06, 2017 at 02:31:28PM +0100, Mehdi Abaakouk wrote: >> >> Any progress ? >> >> On Thu, Dec 08, 2016 at 08:32:54AM +1100, Tony Breeds wrote: >>> >>> On Mon, Dec 05, 2016 at 04:03:13AM +, Keen, Joe wrote: >>>> >>>> I wasn’t able to set a test up on Friday and with all the other work I >>>> have for the next few days I doubt I’ll be able to get to it much before >>>> Wednesday. >>> >>> >>> It's Wednesday so can we have an update? >>> >>> Yours Tony. >> >> >> -- >> Mehdi Abaakouk >> mail: sil...@sileht.net >> >> irc: sileht > > > -- > Mehdi Abaakouk > mail: sil...@sileht.net > ]]irc: sileht > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Not running for Oslo PTL for Pike
Piling on the +1's :) Thanks for your work/guidance/leadership. -- Dims On Mon, Jan 9, 2017 at 6:27 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 03/01/17 12:03 -0800, Joshua Harlow wrote: >> >> Hi Oslo folks (and others), >> >> Happy new year! >> >> After serving for about a year I think it's a good opportunity for myself >> to let another qualified individual run for Oslo PTL (seems common to only >> go for two terms and hand-off to another). >> >> So I just wanted to let folks know that I will be doing this, so that we >> can grow others in the community that wish to try out being a PTL. >> >> I don't plan on leaving the Oslo community btw, just want to make sure we >> spread the knowledge (and the fun!) of being a PTL. >> >> Hopefully I've been a decent PTL (with room to improve) during this >> time :-) > > > Just wanted to second what other folks have said in this thread. You've done > an > amazing work over the past year. Thanks for the time spent as PTL. > > Flavio > > -- > @flaper87 > Flavio Percoco > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][ptls][goals] python3 devstack+functional tests
Folks, Here's where we track the work for a little while: https://etherpad.openstack.org/p/support-python3.5-functional-tests There's lots of work to be done to get stuff working properly. What we have now is the ability to just startup a bunch of services using py35. Does not mean they all work. Teams that do not have functional tests in their own projects may still be able to look for, find and fix bugs. Example, the heat functional tests exercises Nova, Oslo etc. So look for tracebacks there and get going! This is a good chance for newbies to get involved as well. Find a traceback to fix, propose a fix with a python3 unit test :) Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)
Sorry for top post: thanks to Tim Burke, we are past this and a few
other problems. Here's the latest work:
Swift - Review from Tim : https://review.openstack.org/#/c/401397/
Swift - My review (WIP) : https://review.openstack.org/#/c/416084/
DevStack - My review : https://review.openstack.org/#/c/416064/
With all these, we get to the point where s-proxy gets "stuck" and the
tls-proxy times out, logs are here:
http://logs.openstack.org/00/412500/9/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d453c3f/logs/
Happy to turn this over to the swift team from here on.
One more good news, Thanks to the Keystone team for their very first
DevStack+python3.5 based functional test
(gate-keystone-dsvm-py35-functional-v3-only-ubuntu-xenial-nv) with
just a couple of failures left to go:
https://review.openstack.org/#/c/412500/
Thanks,
Dims
On Wed, Jan 4, 2017 at 4:49 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from John Dickinson's message of 2017-01-03 12:00:07 -0800:
>>
>> On 3 Jan 2017, at 10:38, Doug Hellmann wrote:
>>
>> > Excerpts from John Dickinson's message of 2017-01-03 09:02:19 -0800:
>> >>
>> >> On 2 Jan 2017, at 13:06, Davanum Srinivas wrote:
>> >>
>> >>> Folks,
>> >>>
>> >>> Short Story :
>> >>> [1] has merged in devstack, it adds support for a python 3.5 based
>> >>> up/down devstack test that just starts services and brings them down.
>> >>> see [2] for a test run.
>> >>>
>> >>> Need help from swift folks:
>> >>> Swift still needs work i have gotten as far as [3] UnpicklingError on
>> >>> ring data using [4][5][6][7]. Can someone from the swift team pick
>> >>> this up?
>> >>> Once you get this working, please add "swift" to the white list in [8]
>> >>> and remove the disable_service for swift services in [9]
>> >>
>> >> IIRC the issue is the differences between pickle, json, and arrays in py2
>> >> vs py3 (short summary: you can't deserialize in py3 stuff that was
>> >> serialized in py2 without first changing the py2 code).
>> >
>> > Is that right? It seems like it would be the other way around. There
>> > are newer pickle protocols in 3 that aren't available at all for 2.
>> >
>> > There are also some new options to the load() function in 3 to do
>> > things like fix imports for standard library modules that were
>> > renamed and set the right default string encoding to make it possible
>> > to change the *3* code to be able to more easily load a pickle
>> > created by 2 [1]. Is that what you meant?
>>
>> Nah, it's not the pickle protocol. It's the different way (some versions of)
>> py27 [de]serializes arrays vs how py3 does it. The following breaks for
>> py2.7.10 and works for py2.7.12 (.11 is untested).
>>
>> python3 -c 'import array, pickle, os, sys; pickle.dump(array.array("I", [0,
>> 0, 0]), os.fdopen(1, "wb"), protocol=2)' | python -c 'import pickle, os,
>> sys; print(pickle.load(os.fdopen(0, "rb")))'
>
> o_O
>
> Sigh.
>
>>
>> So maybe there are ways to always ensure doing the right thing through some
>> combination of try/excepts, "if six.PY3" blocks, plus lots of docs for ops
>> to make sure upgrades go smoothly, but the real solution is to not use
>> pickle. This is doubly true when considering that the data structure will be
>> used by non-python code, too.
>
> "Friends don't let their friends use pickle for portable persistence."
>
>>
>> This is one of the things to put on the list for py3, and it certainly is
>> not the last.
>
> It would be good to start building up the list in the "Common Pitfalls"
> section of https://wiki.openstack.org/wiki/Python3
>
> Doug
>
>>
>> --John
>>
>> >
>> > Doug
>> >
>> > [1] https://docs.python.org/3.5/library/pickle.html#pickle.load
>> >
>> >>
>> >> We're tracking this at https://bugs.launchpad.net/swift/+bug/1644387 and
>> >> have a patch at https://review.openstack.org/#/c/401397/, but I can't
>> >> guarantee that services will start as soon as that patch lands. (i.e.
>> >> it's necessary, but might not be sufficient)
>> >>
>> >> --John
>> >>
>> >>>
>> >>> Other teams:
>> >>> Please consider adding DSVM jobs with USE_PYTHON3=True for your
>> >>> projects. This will hopefully help us get to
[openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)
Folks, Short Story : [1] has merged in devstack, it adds support for a python 3.5 based up/down devstack test that just starts services and brings them down. see [2] for a test run. Need help from swift folks: Swift still needs work i have gotten as far as [3] UnpicklingError on ring data using [4][5][6][7]. Can someone from the swift team pick this up? Once you get this working, please add "swift" to the white list in [8] and remove the disable_service for swift services in [9] Other teams: Please consider adding DSVM jobs with USE_PYTHON3=True for your projects. This will hopefully help us get to our Pike goal for Python 3.x [10] Please stop by #openstack-python3 channel to chat. Thanks, Dims [1] https://review.openstack.org/#/c/414176/ [2] http://logs.openstack.org/76/414176/11/check/gate-devstack-dsvm-py35-updown-ubuntu-xenial-nv/ [3] http://logs.openstack.org/00/412500/7/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f5a7fe7/logs/screen-s-proxy.txt.gz [4] https://review.openstack.org/#/c/412500/ [5] https://review.openstack.org/#/c/414727/ [6] https://review.openstack.org/#/c/416064/ [7] https://review.openstack.org/#/c/416084/ [8] https://review.openstack.org/#/c/414176/11/inc/python [9] https://review.openstack.org/#/c/413775/5/jenkins/jobs/devstack-gate.yaml [10] https://review.openstack.org/#/c/349069/ -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [legal-discuss] [all][tc][kolla]is it OK to modify python code in OpenStack project?
PSF is ok per (https://governance.openstack.org/tc/reference/licensing.html) Though the overriding the _read() seems like something that could break easily -- dims On Mon, Dec 26, 2016 at 12:13 PM, Michał Jastrzębski <inc...@gmail.com> wrote: > Added all and tc tags, as it might affect everyone really. > > On 25 December 2016 at 23:04, Jeffrey Zhang <zhang.lei@gmail.com> wrote: >> Recently, Kolla project has requirement to modify[1] the python's >> ConfigParser.py code[0]. >> >> Python is using PSF license[3], which is GPL compatible. But OpenStack >> is using Apache License. >> >> Here is the diff view[2]. >> >> I want to make sure: is it OK to re-license ConfigParser.py? If not, what >> the solution? >> >> [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py >> [1] https://review.openstack.org/412101 >> [2] >> https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da371/revisions?diff=split >> [3] https://docs.python.org/3/license.html >> >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me >> >> ___ >> legal-discuss mailing list >> legal-disc...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss >> > > ___ > legal-discuss mailing list > legal-disc...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?
yep, it's time to pull the plug Tony fyi, http://lists.openstack.org/pipermail/openstack-dev/2016-July/098940.html -- Dims On Thu, Dec 22, 2016 at 9:26 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: > Hi All, > I know this comes up from time to time, but as the subject says, is it > time > to retire nova-docker. > > The nova-docker has lagged behind the last 6 months of nova development and no > longer passes simple CI unit tests. There are open patches to at least get > the > unit tests to pass[1] but if the current core team no longer has time (no > offence intended) then perhaps we should just archive it. > > Thoughts? > > Yours Tony. > [1] > https://review.openstack.org/#/q/status:open+project:openstack/nova-docker+branch:master+topic:fixes_for_master > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Yahoo-eng-team] [Bug 1652157] Re: privsep configuration is invalid
** Also affects: oslo.rootwrap Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1652157 Title: privsep configuration is invalid Status in neutron: New Status in oslo.rootwrap: In Progress Bug description: http://logs.openstack.org/76/414176/6/check/gate-devstack-dsvm-py35 -updown-ubuntu-xenial- nv/e100b7f/logs/devstacklog.txt.gz#_2016-12-22_19_44_56_941 2016-12-22 19:44:56.941 | 2016-12-22 19:44:56.940 24861 ERROR neutron.agent.ovsdb.impl_vsctl [-] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Failed to spawn rootwrap process. 2016-12-22 19:44:56.941 | stderr: 2016-12-22 19:44:56.941 | b'Traceback (most recent call last):\n File "/usr/local/bin/neutron-rootwrap-daemon", line 10, in \n sys.exit(daemon())\n File "/usr/local/lib/python3.5/dist-packages/oslo_rootwrap/cmd.py", line 57, in daemon\nreturn main(run_daemon=True)\n File "/usr/local/lib/python3.5/dist-packages/oslo_rootwrap/cmd.py", line 91, in main\nfilters = wrapper.load_filters(config.filters_path)\n File "/usr/local/lib/python3.5/dist-packages/oslo_rootwrap/wrapper.py", line 120, in load_filters\nfilterconfig.read(os.path.join(filterdir, filterfile))\n File "/usr/lib/python3.5/configparser.py", line 696, in read\n self._read(fp, filename)\n File "/usr/lib/python3.5/configparser.py", line 1089, in _read\nfpname, lineno)\nconfigparser.DuplicateOptionError: While reading from \'/etc/neutron/rootwrap.d/privsep.filters\' [line 32]: option \'privsep\' in section \'Filters\' already exists\n' https://github.com/openstack/neutron/blob/master/etc/neutron/rootwrap.d/privsep.filters#L32-L36 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1652157/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
Re: [openstack-dev] [kolla][tc] Video Meetings - input requested
Seconding Doug's call. On concrete suggestion from me is to give enough time ahead of the video meeting so folks who are not able to participate can provide their input via other medium for consideration during the meeting. Folks will also be able to chime in about if the time would work or not for them as well. Definitely please don't make such meetings as a regular thing for sure. Thanks, Dims On Fri, Dec 16, 2016 at 10:40 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Michał Jastrzębski's message of 2016-12-15 14:57:10 -0600: > >> I will defend this thing as something what we needed at the time. >> Sometimes heated up video discussion helps to resolve >> misunderstandings which otherwise could grow up and become conflicts >> in community, which would be much worse. >> >> So please, let's not put artificial rules regarding our communication >> just to be "inclusive". If there is a will to be inclusive, we can be >> regardless of tool, if there is none, no tool will help. I will >> advocate to allow whichever way community decides to work to that >> community and focus on building culture of inclusiveness. >> >> If we have correct mindset, that's all that matters and I, for one, am >> strong believer that Kolla community has been built on top of this >> mindset, and we keep doing good job on following it. > > I think most people are agreeing that having video meeings sometimes > is OK, as long as there is sufficient information published after > the fact. The reason we log IRC channels and meetings is to establish > a record that we can refer to when we miss meetings or need to > refresh our memories of a decision. That just takes extra effort > for meetings held in other ways. > > I am a bit concerned that you seem to be treating this discussion > as hypothetical when it is not. Many members of the community have > explained to you why it is a problem in general, but a member of > your team has brought you direct complaints about the way these > meetings are being managed. This is from someone trusted enough to > act as temporary PTL while you were unable to serve. > > Please re-read the original complaints and the suggestions for > addressing them in this thread and consider what actions the Kolla > team can take to improve in this area. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][infra][all] Signing Keys for Ocata Release
Folks, you may have noticed the releases.openstack.org now shows the PGP signatures of all release artifacts, example: https://releases.openstack.org/ocata/index.html#ocata-nova Many thanks to the Infra team to making this happen, details are here: https://releases.openstack.org/#cryptographic-signatures https://specs.openstack.org/openstack-infra/infra-specs/specs/artifact-signing.html http://docs.openstack.org/infra/system-config/signing.html Please see the key below for Ocata named "OpenStack Infra (Ocata Cycle)", this key will be used for all artifacts and git tags as well: https://sks-keyservers.net/pks/lookup?op=vindex=0xd47bab1b7dc2e262a4f6171e8b1b03fd54e2ac07=on The Infra Root admins have already signed the key (they are the only ones with direct access to the private key to attest). Hoping to see some of the PTL(s) and Release Liaison(s) sign this key as well if they trust the Infra Root admins :) Of course anyone in the OpenStack eco system is welcome to sign the key as well. If you run into trouble, please ping us on the release or the infra channels. Thanks, Dims and Jeremy (On behalf of Infra and Release teams) -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release] Does the Ocata short cycle have an impact on planned EOL dates ?
On Wed, Dec 14, 2016 at 5:11 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2016-12-14 16:42:05 -0500 (-0500), David Moreau Simard wrote: > [...] >> This would lead upstream OpenStack (and downstream distros) to >> support 3 stable releases for a good while. > [...] > > We (upstream) supported stable/newton, stable/mitaka and > stable/liberty branches concurrently for a span of roughly 3 months > (from Newton rc1 until Liberty EOL), so it's not as if it's > impossible for us to do the same thing for an additional month or so > beyond that to accommodate the shorter Ocata development cycle. +1 Jeremy! > -- > Jeremy Stanley > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] will the release schedule be changed because of PTG?
Fred, See the diagram in the blog post from Thierry: https://ttx.re/splitting-out-design-summit.html Thanks, Dims On Thu, Dec 8, 2016 at 10:10 PM, Liyongle (Fred) <liyon...@huawei.com> wrote: > As we know, OpenStack were released in April and October. Because of the > first PTG, Ocata will be released in Feb. I checked [1] and it seems that in > the future OpenStack will be released in Feb. and Aug. Is my understanding > correct? If not, will it be still in April and October in the future? This is > important for us to plan the downstream release. > > Thanks. > > [1] http://www.openstack.org/ptg#tab_faq > > Fred (李永乐) > > 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 > 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 > 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > This e-mail and its attachments contain confidential information from HUAWEI, > which > is intended only for the person or entity whose address is listed above. Any > use of the > information contained herein in any way (including, but not limited to, total > or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tricircle]agenda of weekly meeting Dec.7
Chaoyi, Is there any interest in this work? http://cs.brown.edu/~rfonseca/pubs/yu16netex.pdf https://goo.gl/photos/hwHfMNo4xDMfVK8j8 Please let me know and i'll get you in touch with those folks. Thanks, Dims On Wed, Dec 7, 2016 at 3:00 AM, joehuang <joehu...@huawei.com> wrote: > Hello, team, > > Bug-smash and meetup in last week is very good, let's continue the weekly > meeting. > > Agenda of Dec.7 weekly meeting: > > Bug smash and meetup summary > Ocata feature development review > legacy tables clean after splitting > Open Discussion > > > How to join: > > # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on > every Wednesday starting from UTC 13:00. > > > If you have other topics to be discussed in the weekly meeting, please > reply the mail. > > > Best Regards > Chaoyi Huang (joehuang) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default
It has taken years to get here with a lot of work from many folks. -1 for Any revert! https://etherpad.openstack.org/p/v3-only-devstack http://markmail.org/message/aqq7itdom36omnf6 https://review.openstack.org/#/q/status:merged+project:openstack-dev/devstack+branch:master+topic:bp/keystonev3 Thanks, Dims On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin <akuri...@mirantis.com> wrote: > Hi folks! > > Today devstack team decided to switch to keystone v3 by default[0]. > Imo, it is important thing, but it was made in silent, so other project was > unable to prepare to that change. Also, proposed way to select Keystone API > version via devstack configuration doesn't work(IDENTITY_API_VERSION > variable doesn't work [1] ). > > Switching to keystone v3 broke at least Rally and Magnum(based on comment to > [0]) gates. Also, python-novaclient has two separate jobs for checking > compatibility with keystone V2 and V3. One of these jobs became redundant. > > That is why I submitted a revert [2] . > > PS: Please, do not make such changes in silent! > > [0] - https://review.openstack.org/#/c/386183 > [1] - > https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74 > [2] - https://review.openstack.org/405264 > > -- > Best regards, > Andrey Kurilin. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Pruning Kolla-Kubernetes core reviewers
++ sdake, inc0 On Wed, Nov 30, 2016 at 5:49 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > Hello folks, > > > > Michal (inc0) is the PTL of Kolla. He has asked me to send this message > since it was my agreement with the community in the Austin Design Summit > when I served as Kolla PTL that people that participate in the > implementation of the kolla-kubernetes deliverable at the start of the > deliverable would be granted automatic core reviewer permissions as we were > bootstrapping a new deliverable from an empty repository. Part of that > agreement was that people that were not active in the development, including > reviewing, would be pruned from the list at a later date. > > > > That later date has come. > > > > The folks being removed from kolla-kubernetes-core are: > > > > Greg Herlein > > Liyi Meng > > Davanum Srinivas > > > > On a more positive note, the purpose of this change is to enable the > resulting core reviewer team to achieve majority votes for core reviewer > nominations. There are several candidates queued up and Michal will be > nominating these individuals when the core reviewer team feels the time is > right. > > > > Michal has said he will make these changes in gerrit effective immediately. > > > > Cheers, > > -steve > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [monasca][oslo] (Re: [oslo] Should we drop kafka driver ?)
Mehdi, Problem is with Monasca team having concerns with later python-kafka versions https://bugs.launchpad.net/oslo.messaging/+bug/1639264 Adding them to the subject line -- Dims On Wed, Nov 30, 2016 at 10:28 AM, Mehdi Abaakouk <sil...@sileht.net> wrote: > Hi, > > I think my subject is clear :) , but I will add some facts that can help > to the decision: > * It uses only deprecated python-kafka API [1] [2] > * It's not python3 compatible [3] > * We still don't have kafka testing in gate > So, one year after the driver introduction, this one is still in bad shape > and doesn't match the requirements [4]. > > These reviews looks abandoned/outdated/unmaintained: > > [1] https://review.openstack.org/#/c/297994/ [2] > https://review.openstack.org/#/c/332105/ > > Other links: > > [3] https://review.openstack.org/#/c/404802/ > [4] > http://docs.openstack.org/developer/oslo.messaging/supported-messaging-drivers.html#testing > > And of course, we will not drop the code now, but just deprecate it for > removal. > Cheers, > > -- > Mehdi Abaakouk > mail: sil...@sileht.net > irc: sileht > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] rally failure in the gate
Andrey, Folks, I've fast-tracked the black list: https://review.openstack.org/400183 Thanks, Dims On Mon, Nov 21, 2016 at 6:00 AM, Andrey Kurilin <akuri...@mirantis.com> wrote: > hi folks! > > Neutron gates are broken again. New failure relates to issue with heatclient > [*] . > > [*] - https://bugs.launchpad.net/python-heatclient/+bug/1643507 > > > > On Fri, Nov 18, 2016 at 12:51 PM, Andrey Kurilin <akuri...@mirantis.com> > wrote: >> >> Hi stackers! >> >> Imo, there is a better solution - just turn off telemetry services[*] :) >> Neutron jobs do not runs any ceilometer scenarios, so enabling all telemetry >> services looks redundant and takes some time while preparing environment >> (installing devstack). >> >> >> [*] - https://review.openstack.org/#/c/399212 >> >> On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka <ihrac...@redhat.com> >> wrote: >>> >>> >>> > On 17 Nov 2016, at 20:32, Armando M. <arma...@gmail.com> wrote: >>> > >>> > Hi folks, >>> > >>> > Please do not recheck rally failures. >>> > >>> > There was a breaking change introduced by aodh [0] that prevented rally >>> > to work on trusty. We are switching to xenial as we speak anyway [1], so >>> > the >>> > glitch should be short lived. >>> >>> To give an update, the switch to Xenial occurred, and I see jobs passing >>> just fine again. >>> >>> Ihar >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> Best regards, >> Andrey Kurilin. > > > > > -- > Best regards, > Andrey Kurilin. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Embracing new languages in OpenStack
Pete, Please see below: On Thu, Nov 10, 2016 at 1:00 PM, Pete Zaitcev <zait...@redhat.com> wrote: > On Wed, 9 Nov 2016 11:14:32 + (GMT) > Chris Dent <cdent...@anticdent.org> wrote: > >> The conversations about additional languages in this community have >> been one our most alarmingly regressive and patronizing. They seem >> to be bred out of fear rather than hope and out of lack of faith in >> each other than in trust. We've got people who want to build stuff. >> Isn't that the important part? > > I dunno, it seems fine to discuss. I'm disappointed that TC voted Golang > down on August 2, but I can see where they come from. > > The problem we're grappling with on the Swift side is (in my view) mainly > that the Go reimplementation provides essential performance advantages > which manifest at a certain scale (around 100 PB with current technology). > For this reason, ignoring Hummingbird and prohibiting Go is not going to > suppress them. As the operators deploy Hummingbird in preference to the > Python implementation, the focus of the development is going to migrate, > and the end result is going to be an effective exile of a founding > project from the OpenStack. > > (Even if happens, it's probably not a big deal. Just look how well Ceph > is doing, community-wise. Operators aren't crying bloody tears either, > do they?) > > The conflict is that since re-writing e.g. Newtron in Go does not confer > the same performance advantage (AFAIK -- your VLANs aren't going to set > up and tear down 80 times faster), the disruption isn't worth the trouble > for the majority of OpenStack projects. This is why TC voted us down. > And the talk about the community is mostly there to heal psychologically. Please read the long comment from Doug Hellmann: (time stamp Aug 2 5:01 PM) https://review.openstack.org/#/c/339175/ > So, it wasn't "regressive" or "patronizing", just business. See how Flavio > outlined specific steps in a constructive manner. > > I'm quite glad that Ash wants to do something about CI. And I'm going > to look into fully supporting existing configurations. Maybe share it with > Designate and thus create something like a proto-"oslo.go.config". > Of course we need to have some code to share first. > > -- Pete > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][kolla][security] pycrypto vs cryptography
Steve, pycrypto is almost dead. The replacement is pycryptodome. BUT both cannot be installed at the same time, so there is a struggle to get all projects to work correctly with pycryptodome, Last i checked the status was this: http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n188 cryptography has been there in requirements since 2014: https://review.openstack.org/#/c/93794/ So, i'd support projects wanting to use cryptography directly. fwiw, i don't see a claim to support FIPS-140-2 in cryptography: https://cryptography.io/en/latest/development/test-vectors/ https://github.com/pyca/cryptography/tree/master/vectors/cryptography_vectors/asymmetric/ECDSA Thanks, Dims On Sun, Nov 6, 2016 at 3:05 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > Requirements team, > > > > Currently Kolla uses pycrypto in our requirements. I see a lot of big tent > projects moving to cryptography. Is this just my imagination, or was there > a decision on this from the requirements team? We are happy to comply with > whatever dep management is considered appropriate for OpenStack ESPECIALLY > as it relates to security and crypto libraries. > > > > I’d just like confirmation if we should move off pycrypto to cryptography, > or if these two things offer similar functionality, or if I’m way off base > here J. > > > > An orthogonal question I have received from one of our community members > (Pavo on irc) is whether pycrypto (or if we move to cryptography) provide > FIPS-140-2 compliance. > > > > Regards > > -steve > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] SIG-OpenStack @ Kubernetes
Folks, fyi, there's a bunch of Stackers working on Kubernetes. http://blog.kubernetes.io/2016/04/introducing-kubernetes-openstack-sig.html In Kubernetes, work is organized around Special Interest Groups: https://github.com/kubernetes/community/blob/master/README.md#special-interest-groups-sig So the OpenStack related one is: https://github.com/kubernetes/community/blob/master/sig-openstack/README.md The reason for this email is that there is a lot of work to be done in Kubernetes' OpenStack Provider and we were wondering if anyone wants to help? Issues : https://github.com/kubernetes/kubernetes/labels/area%2Fplatform%2Fopenstack Pull Requests : https://github.com/kubernetes/kubernetes/pulls?utf8=%E2%9C%93=is%3Aopen%20is%3Apr%20openstack Hopefully work on these issues/PR's will make OpenStack the best platform to run Kubernetes on and will help strengthen the cross connections between the two foundations. Thanks, Dims PS: Don't get me wrong there's enough work in Kuryr/Magnum/Zun/Kolla-Kubernetes/fuel-ccp etc :) This is just in case someone has some cycles! -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure
Amrith, Please see the older work from 2013: https://blueprints.launchpad.net/oslo.messaging/+spec/trusted-messaging https://etherpad.openstack.org/p/HavanaOsloMessaging https://blog-nkinder.rhcloud.com/?p=62 https://adam.younglogic.com/2014/04/pki-for-oslo-messaging/ -- Dims On Thu, Nov 3, 2016 at 3:35 PM, Amrith Kumar <amr...@tesora.com> wrote: > Dims, I don't think ovo addresses this issue. It isn't one of versioning that > I'm attempting to address but rather as Gordon points out, of signing and > verifying authenticity. Please see also my longer response to him on this. > > -amrith > > -Original Message----- > From: Davanum Srinivas [mailto:dava...@gmail.com] > Sent: Thursday, November 3, 2016 3:03 PM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic > representation of a python data structure > > Does oslo.versionedobjects solve some of your needs? > > http://www.slideshare.net/davanum/ovo-deep-dive > https://gorka.eguileor.com/learning-something-new-about-oslo-versioned-objects/ > http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/ > > -- Dims > > On Thu, Nov 3, 2016 at 2:24 PM, Amrith Kumar <amr...@tesora.com> wrote: >> TL;DR >> >> >> >> I want to take a python data structure (see later for details) and >> represent it in a format that will be stable across python versions, >> and platforms so that I can construct a stable hash. I’m looking for >> pointers to some best practices on how to do this. >> >> >> >> The longer version >> >> >> >> Assume that there’s some function in python that is: >> >> >> >> def fn(*args, **kwargs): >> >> … >> >> >> >> I’d like to take (args, kwargs) and construct a hash of some >> representation that is deterministic. Specifically, assume that fn() >> is a method in the API (oslo.messaging transport …). I’d like to >> construct the hash on the sender side and on the RPC server side and >> make sure that the parameters are the same. >> >> >> >> So, just before calling call() or cast(), I could compute the hash and >> stuff it into the dictionary that is being sent over, and I can do the >> same on the receiving side. But since I cannot guarantee that the >> representation on the receiving side is necessarily identical to the >> representation on the sending side, I have issues computing the hash. >> >> >> >> In IRC, jroll suggested json; can one safely assume that json.dumps() >> is a deterministic representation? >> >> >> >> Thanks for any pointers and suggestions. >> >> >> >> -amrith >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure
Does oslo.versionedobjects solve some of your needs? http://www.slideshare.net/davanum/ovo-deep-dive https://gorka.eguileor.com/learning-something-new-about-oslo-versioned-objects/ http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/ -- Dims On Thu, Nov 3, 2016 at 2:24 PM, Amrith Kumar <amr...@tesora.com> wrote: > TL;DR > > > > I want to take a python data structure (see later for details) and represent > it in a format that will be stable across python versions, and platforms so > that I can construct a stable hash. I’m looking for pointers to some best > practices on how to do this. > > > > The longer version > > > > Assume that there’s some function in python that is: > > > > def fn(*args, **kwargs): > > … > > > > I’d like to take (args, kwargs) and construct a hash of some representation > that is deterministic. Specifically, assume that fn() is a method in the API > (oslo.messaging transport …). I’d like to construct the hash on the sender > side and on the RPC server side and make sure that the parameters are the > same. > > > > So, just before calling call() or cast(), I could compute the hash and stuff > it into the dictionary that is being sent over, and I can do the same on the > receiving side. But since I cannot guarantee that the representation on the > receiving side is necessarily identical to the representation on the sending > side, I have issues computing the hash. > > > > In IRC, jroll suggested json; can one safely assume that json.dumps() is a > deterministic representation? > > > > Thanks for any pointers and suggestions. > > > > -amrith > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Splitting notifications from rpc (and questions + work around this)
Cheran, Nova and Neutron already supported this split when we started this exercise. So yes, they are already shipped :) https://review.openstack.org/#/c/266960/ https://review.openstack.org/#/c/268335/ -- Dims On Thu, Nov 3, 2016 at 1:43 PM, Elancheran Subramanian <esubraman...@godaddy.com> wrote: > Hi Dims, > Thanks for sharing… > > Just wanted to check whether there is any development for Nova and Neutron > going on, which we can leverage? > > Thanks, > Cheran > > > > > On 11/3/16, 12:51 AM, "Davanum Srinivas" <dava...@gmail.com> wrote: > >>Josh, >> >>Kirill Bespalov put together this doc of which components will work >>with separate rpc and notification configurations: >>https://docs.google.com/document/d/1CU0KjL9iV8vut76hg9cFuWQGSJawuNq_cK7vRF >>_KyAA/edit?usp=sharing >> > >From my team, Oleksii Zamiatin is trying to scale up ZMQ beyond 200+ >>nodes for RPC. >> >>Ilya Tyaptin's review is stuck because Monasca folks have trouble >>using the newer python-kafka version: >>https://review.openstack.org/#/c/332105/ >>https://review.openstack.org/#/c/316259/ >> >>As you can tell, we are trying to offer RabbitMQ or ZMQ for RPC and >>RabbitMQ or Kafka for Notifications. >> >>Hope this helps. >> >>Thanks, >>Dims >> >>On Wed, Nov 2, 2016 at 8:11 PM, Joshua Harlow <harlo...@fastmail.com> >>wrote: >>> Hi folks, >>> >>> There was a bunch of chatter at the summit about how there are really >>>two >>> different types of (oslo) messaging usage that exist in openstack and >>>how >>> they need not be backed by the same solution type (rabbitmq, qpid, >>> kafka...). >>> >>> For those that were not at the oslo sessions: >>> >>> https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Oslo >>> >>> The general gist was though that we need to make sure people really do >>>know >>> that there are two very different types of messaging usage in openstack >>>and >>> to ensure that operators (and developers) are picking the right backing >>> technology for each type. >>> >>> So some questions naturally arise out of this. >>> >>> * Where are the best practices with regard to selection of the best >>>backend >>> type for rpc (and one for notifications); is this something >>>oslo.messaging >>> should work through (or can the docs team and operator group also help >>>in >>> making this)? >>> >>> * What are the tradeoffs in using the same (or different) technology >>>for rpc >>> and notifications? >>> >>> * Is it even possible for all oslo.messaging consuming projects to be >>>able >>> to choose 2 different backends, are consuming projects consuming the >>>library >>> correctly so that they can use 2 different backends? >>> >>> * Is devstack able to run with say kafka for notifications and rabbitmq >>>for >>> rpc (if not, is there any work item the oslo group can help with to make >>> this possible) so that we can ensure and test that all projects can work >>> correctly with appropriate (and possibly different) backends? >>> >>> * Any other messaging, arch-wg work that we (oslo or others) can help >>>out >>> with to make sure that projects (and operators) are using the right >>> technology for the right use (and not just defaulting to RPC over >>>rabbitmq >>> because it exists, when in reality something else might be a better >>>choice)? >>> >>> * More(?) >>> >>> Just wanted to get this conversation started, because afaik it's one >>>that >>> has not been widely circulated (and operators have been setting up >>>rabbitmq >>> in various HA and clustered and ... modes, when in reality thinking >>>through >>> what and how it is used may be more appropriate); this also applies to >>> developers since some technical solutions in openstack seem to be >>>created >>> due to (in-part) rabbitmq shortcomings (cells v1 afaik was *in* part >>>created >>> due to scaling issues). >>> >>> -Josh >>> >>> >>>_____ >>>_ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>
Re: [openstack-dev] Splitting notifications from rpc (and questions + work around this)
Josh, Kirill Bespalov put together this doc of which components will work with separate rpc and notification configurations: https://docs.google.com/document/d/1CU0KjL9iV8vut76hg9cFuWQGSJawuNq_cK7vRF_KyAA/edit?usp=sharing >From my team, Oleksii Zamiatin is trying to scale up ZMQ beyond 200+ nodes for RPC. Ilya Tyaptin's review is stuck because Monasca folks have trouble using the newer python-kafka version: https://review.openstack.org/#/c/332105/ https://review.openstack.org/#/c/316259/ As you can tell, we are trying to offer RabbitMQ or ZMQ for RPC and RabbitMQ or Kafka for Notifications. Hope this helps. Thanks, Dims On Wed, Nov 2, 2016 at 8:11 PM, Joshua Harlow <harlo...@fastmail.com> wrote: > Hi folks, > > There was a bunch of chatter at the summit about how there are really two > different types of (oslo) messaging usage that exist in openstack and how > they need not be backed by the same solution type (rabbitmq, qpid, > kafka...). > > For those that were not at the oslo sessions: > > https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Oslo > > The general gist was though that we need to make sure people really do know > that there are two very different types of messaging usage in openstack and > to ensure that operators (and developers) are picking the right backing > technology for each type. > > So some questions naturally arise out of this. > > * Where are the best practices with regard to selection of the best backend > type for rpc (and one for notifications); is this something oslo.messaging > should work through (or can the docs team and operator group also help in > making this)? > > * What are the tradeoffs in using the same (or different) technology for rpc > and notifications? > > * Is it even possible for all oslo.messaging consuming projects to be able > to choose 2 different backends, are consuming projects consuming the library > correctly so that they can use 2 different backends? > > * Is devstack able to run with say kafka for notifications and rabbitmq for > rpc (if not, is there any work item the oslo group can help with to make > this possible) so that we can ensure and test that all projects can work > correctly with appropriate (and possibly different) backends? > > * Any other messaging, arch-wg work that we (oslo or others) can help out > with to make sure that projects (and operators) are using the right > technology for the right use (and not just defaulting to RPC over rabbitmq > because it exists, when in reality something else might be a better choice)? > > * More(?) > > Just wanted to get this conversation started, because afaik it's one that > has not been widely circulated (and operators have been setting up rabbitmq > in various HA and clustered and ... modes, when in reality thinking through > what and how it is used may be more appropriate); this also applies to > developers since some technical solutions in openstack seem to be created > due to (in-part) rabbitmq shortcomings (cells v1 afaik was *in* part created > due to scaling issues). > > -Josh > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][release] Release announcements
On Wed, Nov 2, 2016 at 1:21 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Thierry Carrez's message of 2016-11-02 17:33:51 +0100: >> Hi everyone, >> >> In Barcelona the release team has been discussing how to improve release >> announcements. Posting them on openstack-dev (for libs) and >> openstack-announce (for main services) has proven to be pretty noisy, >> especially for projects which publish lots of components, like OpenStack >> Puppet or OpenStack Ansible. This actively discouraged people to follow >> openstack-announce, which was really not the goal. >> >> At the same time, we can't just stop making announcements. Some people >> (especially on the downstream side) still want to receive release >> announces. And we still want to archive a trace of the release and >> provide a starting point for discussing immediate issues on a given >> release, especially for libraries. >> >> The proposed solution is to create a specific mailing-list for OpenStack >> release announcements (proposed name is "release-announces") where we'd > > How about either "release-announce" or "release-announcements"? slightly prefer "release-announce" over "release-announcements" to be in line with openstack-announce Thanks, Dims > >> post the automated release announcements. Only the release bot and >> release managers would be able to post to it. The "reply-to" field would >> be set to openstack-dev, in case someone wanted to start a thread about >> a given release. By default, it would be set to send in daily digest >> mode, to reduce noise and encourage people to subscribe to it. >> >> The -announce list would get back to low-noise, and be limited to >> highly-important announcements (one email for the final release, emails >> about events, elections...). >> >> Please let us know if you have comments or questions. We'll start >> implementing this plan next week if no objection is raised. >> > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] new keystone core (breton)
Great job Boris! On Mon, Oct 31, 2016 at 4:12 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > Great work Boris. Welcome to the team! > > On Mon, Oct 31, 2016 at 2:50 PM, Kristi Nikolla <kniko...@bu.edu> wrote: >> >> Congrats Boris! Well deserved! >> >> Kristi >> >> On 10/31/2016 03:46 PM, Steve Martinelli wrote: >> > I want to welcome Boris Bobrov (breton) to the keystone core team. Boris >> > has been a contributor for some time and is well respected by the >> > keystone team for bringing real-world operator experience and feedback. >> > He has recently become more active in terms of code contributions and >> > bug triaging. Upon interacting with Boris, you quickly realize he has a >> > high standard for quality and keeps us honest. >> > >> > Thanks for all your hard work Boris, I'm happy to have you on the team. >> > >> > Steve Martinelli >> > stevemar >> > >> > >> > >> > >> > __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
Adam, One distinction i heard was that this is just a runtime dependency, hence my suggestion. Thanks, Dims On Wed, Oct 19, 2016 at 11:00 AM, Adam Harwell <flux.a...@gmail.com> wrote: > Dims: that wasn't meant as hostile to you, though re-reading it kind of > sounds that way. > You were not the first in this thread to suggest bindep, and while your > links are useful, I don't think it makes a lot of sense for our use case. I > legitimately can't understand why this *one* dependency (not anything a > deployer will need to install on their control-plane instances) is suggested > as a binary dependency, when it is a python module that we include in our > code just like *everything else* in our requirements file. > > On Wed, Oct 19, 2016 at 11:02 PM Adam Harwell <flux.a...@gmail.com> wrote: >> >> We literally install every other dependency from pypi with >> requirements.txt, so I'm struggling understand why all the sudden we need to >> install this one as a binary, for our devstack specific script, when we are >> planning a move to a distro that doesn't even support binary packages? >> Should we switch our entire requirements file to bindep? If not, what makes >> this different? >> >> >> On Wed, Oct 19, 2016, 22:56 Davanum Srinivas <dava...@gmail.com> wrote: >>> >>> Adam, >>> >>> Have you see this yet? >>> >>> >>> http://docs.openstack.org/infra/bindep/readme.html#writing-requirements-files >>> >>> http://codesearch.openstack.org/?q=platform=nope=bindep.txt= >>> >>> Thanks, >>> Dims >>> >>> On Wed, Oct 19, 2016 at 9:40 AM, Adam Harwell <flux.a...@gmail.com> >>> wrote: >>> > Yes, but we need to use SOMETHING for our own devstack gate tests -- >>> > maybe >>> > it is easier to think of our devstack code as a "third party setup", >>> > and >>> > that it uses gunicorn for its DIB images (but not every deployer needs >>> > to). >>> > In this case, how do we include it? Devstack needs it to run our gate >>> > jobs, >>> > which means it has to be in our main codebase, but deployers don't >>> > necessarily need it for their deployments (though it is the default >>> > option). >>> > Do we include it in global-requirements or not? How do we use it in >>> > devstack >>> > if it is not in global-requirements? We don't install it as a binary >>> > because >>> > the plan is to stay completely distro-independant (or target a distro >>> > that >>> > doesn't even HAVE binary packages like cirros). Originally I just put >>> > the >>> > line "pip install gunicorn>=19.0" directly in our DIB script, but was >>> > told >>> > that was a dirty hack, and that it should be in requirements.txt like >>> > everything else. I'm not sure I agree, and it seems like maybe others >>> > are >>> > suggesting I go back to that method? >>> > >>> > --Adam >>> > >>> > On Wed, Oct 19, 2016 at 10:19 PM Hayes, Graham <graham.ha...@hpe.com> >>> > wrote: >>> >> >>> >> On 18/10/2016 19:57, Doug Wiegley wrote: >>> >> > >>> >> >> On Oct 18, 2016, at 12:42 PM, Doug Hellmann <d...@doughellmann.com> >>> >> >> wrote: >>> >> >> >>> >> >> Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600: >>> >> >>> >>> >> >>>> On Oct 18, 2016, at 12:10 PM, Doug Hellmann >>> >> >>>> <d...@doughellmann.com> >>> >> >>>> wrote: >>> >> >>>> >>> >> >>>> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 >>> >> >>>> -0600: >>> >> >>>>> >>> >> >>>>>> On Oct 18, 2016, at 11:30 AM, Doug Hellmann >>> >> >>>>>> <d...@doughellmann.com >>> >> >>>>>> <mailto:d...@doughellmann.com>> wrote: >>> >> >>>>>> >>> >> >>>>>> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 >>> >> >>>>>> -0600: >>> >> >>>>>>> >>> >> >>>>>>>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco >>> >> >>>
[openstack-dev] [openstack-ansible][release] OpenStack-Ansible Newton RC4 available (Re: [openstack-ansible][release] OpenStack-Ansible Newton RC3 available)
Please test RC4, same details as below :) Thanks, Dims On Thu, Oct 13, 2016 at 9:00 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Hello everyone, > > A new release candidate for OpenStack Ansible for the end of the > Newton cycle is available! > > You can find the source code tarballs at: > https://releases.openstack.org/newton/index.html#newton-openstack-ansible > > Alternatively, you can directly test the stable/newton release branch at: > http://git.openstack.org/cgit/openstack/openstack-ansible/log/?h=stable/newton > > (Note: there are many repositories named openstack/openstack-ansible*) > > If you find an issue that could be considered release-critical, please > file it at: > https://bugs.launchpad.net/openstack-ansible/+filebug > > and tag it *newton-rc-potential* to bring it to the OpenStackAnsible > release crew's attention. > > Thanks, > Dims (On behalf of the Release team) > > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla][release] Kolla Newton RC3 available (Re: [kolla][release] Kolla Newton RC2 available)
Please test: https://tarballs.openstack.org/kolla/kolla-3.0.0.0rc3.tar.gz Thanks, Dims On Thu, Oct 13, 2016 at 9:57 AM, Davanum Srinivas <dava...@gmail.com> wrote: > Hello everyone, > > A new release candidate for Kolla for the end of the Newton cycle > is available! You can find the source code tarball at: > > https://tarballs.openstack.org/kolla/kolla-3.0.0.0rc2.tar.gz > > Alternatively, you can directly test the stable/newton release > branch at: > > http://git.openstack.org/cgit/openstack/kolla/log/?h=stable/newton > > If you find an issue that could be considered release-critical, > please file it at: > > https://bugs.launchpad.net/kolla/+filebug > > and tag it *newton-rc-potential* to bring it to the PROJECT release > crew's attention. > > Thanks, > Dims (On behalf of the Release team) > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
;> >>>>>>>> <mailto:openstack-dev@lists.openstack.org>>> >> >>>>>>>> <openstack-dev@lists.openstack.org >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org>> >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org> >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org >> >>>>>>>> <mailto:openstack-dev@lists.openstack.org>>>> >> >>>>>>>> Subject: Re: [openstack-dev] [requirements][lbaas] gunicorn to >> >>>>>>>> g-r >> >>>>>>>> >> >>>>>>>>> Doug Wiegley wrote: >> >>>>>>>>>> [...] Paths forward: >> >>>>>>>>>> >> >>>>>>>>>> 1. Add gunicorn to global requirements. >> >>>>>>>>>> >> >>>>>>>>>> 2. Create a project specific “amphora-requirements.txt” file >> >>>>>>>>>> for the >> >>>>>>>>>> service VM packages (this is actually my preference.) It has >> >>>>>>>>>> been >> >>>>>>>>>> pointed out that this wouldn’t be kept up-to-date by the bot. >> >>>>>>>>>> We could >> >>>>>>>>>> modify the bot to include it in some way, or do it manually, or >> >>>>>>>>>> with a >> >>>>>>>>>> project specific job. >> >>>>>>>>>> >> >>>>>>>>>> 3. Split our service VM builds into another repo, to keep a >> >>>>>>>>>> clean >> >>>>>>>>>> separation between API services and the backend. But, even this >> >>>>>>>>>> new >> >>>>>>>>>> repo’s standlone requirements.txt file will have the g-r issue >> >>>>>>>>>> from #1. >> >>>>>>>>>> >> >>>>>>>>>> 4. Boot the backend out of OpenStack entirely. >> >>>>>>>>> >> >>>>>>>>> All those options sound valid to me, so the requirements team >> >>>>>>>>> should >> >>>>>>>>> pick what they are the most comfortable with. >> >>>>>>>>> >> >>>>>>>>> My 2c: yes g-r is mostly about runtime dependencies and ensuring >> >>>>>>>>> co-installability. However it also includes test/build-time >> >>>>>>>>> deps, and >> >>>>>>>>> generally converging dependencies overall sounds like a valid >> >>>>>>>>> goal. Is >> >>>>>>>>> there any drawback in adding gunicorn to g-r (option 1) ? >> >>>>>>>> >> >>>>>>>> The drawback (in my mind) is that new projects might start using >> >>>>>>>> it giving operators yet another thing to learn about when deploying >> >>>>>>>> a new >> >>>>>>>> component (eventlet, gevent, gunicorn, ...). >> >>>>>>>> >> >>>>>>>> On the flip, what's the benefit of adding it to g-r? >> >>>>>>> >> >>>>>>> The positive benefit is the same as Octavia’s use case: it >> >>>>>>> provides an alternative for any non-frontline-api service to run a >> >>>>>>> lightweight http/wsgi service as needed (service VMs, health monitor >> >>>>>>> agents, >> >>>>>>> etc). And something better than the built-in debug servers in most >> >>>>>>> of the >> >>>>>>> frameworks. >> >>>>>>> >> >>>>>>> On the proliferation point, it is certainly a risk, though I’ve >> >>>>>>> personally heard pretty strong guidance that all main API services
Re: [openstack-dev] [all] running non-devstack jobs in Python projects aka "it works outside devstack"
for awhile and tries to debug gate failures is at least used to > hacking on devstack and knows how it works to a certain extent. > > Anyway, as I said, I've got no problem with getting some additional optional > non-voting coverage in other projects besides devstack to at least try and > prevent breaking changes. I worry about trying to move various deployment > jobs into the check queue for multiple projects though, as I think that > would put a pretty serious strain on resources for non-voting jobs, which > we'd like to avoid I think. > > My two cents. Matt, Emilien, there's one more option, run jobs daily and add the output to the openstack health dashboard. example - http://status.openstack.org/openstack-health/#/g/build_name/periodic-ironic-py35-with-oslo-master > -- > > Thanks, > > Matt Riedemann > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack-ansible][release] OpenStack-Ansible Newton RC3 available
Hello everyone, A new release candidate for OpenStack Ansible for the end of the Newton cycle is available! You can find the source code tarballs at: https://releases.openstack.org/newton/index.html#newton-openstack-ansible Alternatively, you can directly test the stable/newton release branch at: http://git.openstack.org/cgit/openstack/openstack-ansible/log/?h=stable/newton (Note: there are many repositories named openstack/openstack-ansible*) If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/openstack-ansible/+filebug and tag it *newton-rc-potential* to bring it to the OpenStackAnsible release crew's attention. Thanks, Dims (On behalf of the Release team) -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla][release] Kolla Newton RC2 available
Hello everyone, A new release candidate for Kolla for the end of the Newton cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/kolla/kolla-3.0.0.0rc2.tar.gz Alternatively, you can directly test the stable/newton release branch at: http://git.openstack.org/cgit/openstack/kolla/log/?h=stable/newton If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/kolla/+filebug and tag it *newton-rc-potential* to bring it to the PROJECT release crew's attention. Thanks, Dims (On behalf of the Release team) -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] requests-mock
Clay, Apologies for the top post. Here's the current recommendation on dependencies - Answering your question on "I'm not acctually sure what the OpenStack policy is on dependency hygiene :D Anyway,": https://github.com/openstack/requirements#global-requirements-for-openstack-projects There is a requirements team, you can reach them on the #openstack-requirements channel: https://wiki.openstack.org/wiki/Requirements -- Dims On Tue, Oct 11, 2016 at 1:23 AM, Clay Gerrard <clay.gerr...@gmail.com> wrote: > Greetings! > > Anyone have any experience to share positive or negative using > requests-mock? I see it's been used to replace another dependency that had > some problems in many of the OpenStack python client libraries: > > Added to global requirements -> https://review.openstack.org/#/c/104067 > Added to novaclient -> https://review.openstack.org/#/c/112179/ > Added to cinderclient -> https://review.openstack.org/#/c/106665/ > Added to keystoneclient -> https://review.openstack.org/#/c/106659/ > > But I'm not sure how folks other than Jamie are getting on with it? When > writing new tests do you tend to instinctively grab for requests-mock - or > do you mostly not notice it's there? Any unexpected behaviors ever have you > checking it out with bzr and reading over the source? Do you recall ever > having any bumps or bruises in the gate or in your development workflow > because of a new release from requests-mock? No presumed fault on Jamie! > It seems like he's doing a Herculean one-man job there; but it can be > difficult go it alone: > > https://bugs.launchpad.net/requests-mock/+bug/1616690 > > It looks like the gate on this project is configured to run nova & keystone > client tests; so that may be sufficient to catch any sort of issue that > might come up in something that depends on it? Presumably once he lands a > change - he does the update to global-requirements and then all of OpenStack > get's it from there? > > I ask of course because I really don't understand how this works [1] :D > > But anyway - Jamie was kind enough to offer to refactor some tests for us - > but in the process seems to require to bring in these new dependencies - so > I'm trying to evaluate if I can recommend requiring this code in order to > develop on swiftclient [2]. > > Any feedback is greatly appreciated! > > -Clay > > 1. As you may know (thanks to some recently publicity) swift & swiftclient > joined OpenStack in the time of dinosaurs with a general policy of trying to > keep dependencies to a *minimum* - but then one day the policy changed to... > *always* add dependencies whenever possible? j/k I'm not acctually sure > what the OpenStack policy is on dependency hygiene :D Anyway, I can't say > *exactly* where that "general policy" came from originally? Presumably > crieht or gholt just had some first hand experience that the dependencies > you choose to add have a HUGE impact on your project over it's lifetime - or > read something from Joel on Software - > http://www.joelonsoftware.com/articles/fog07.html - or traveled into > the future and read the "go proverbs" and google'd "npm breaks internet, > again". Of course they've since moved on from OpenStack but the general > idea is still something that new contributors to swift & swiftclient get > acclimated to and the circle of confusion continues > https://github.com/openstack/swift/blob/master/CONTRIBUTING.rst#swift-design-principles > - but hey! maybe I can educate myself about the OpenStack policy/process; > add this dependency and maybe the next one too; then someday break the > cycle!?!? > > 2. https://review.openstack.org/#/c/360298 > > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][tc] Cross Project workshops in Barcelona including "Re-inventing the TC"
Folks, Please see the cross project schedule over at: https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Cross%20Project%20workshops%3A For those of you who are very interested in how TC works and what it can/should do. Please mark on your calendar: https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16923/cross-project-workshops-re-inventing-the-tc-the-stewardship-working-group-discussion Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][Congress] Congress Newton RC3 available (Congress Newton RC2 available)
Please verify RC3: https://tarballs.openstack.org/congress/congress-4.0.0.0rc3.tar.gz This is a release-critical fix for Newton. Thanks, Dims On Sat, Oct 1, 2016 at 10:00 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Please verify RC2: > https://tarballs.openstack.org/congress/congress-4.0.0.0rc2.tar.gz > > Thanks, > Dims > > On Fri, Sep 16, 2016 at 12:45 PM, Davanum Srinivas <dava...@gmail.com> wrote: >> Hello everyone, >> >> The release candidate for Congress for the end of the Newton cycle >> is available! You can find the RC1 source code tarball at: >> >> https://tarballs.openstack.org/congress/congress-4.0.0.0rc1.tar.gz >> >> Unless release-critical issues are found that warrant a release >> candidate respin, this RC1 will be formally released as the final >> Newton release on 6 October. You are therefore strongly >> encouraged to test and validate this tarball! >> >> Alternatively, you can directly test the stable/newton release >> branch at: >> >> http://git.openstack.org/cgit/openstack/congress/log/?h=stable/newton >> >> If you find an issue that could be considered release-critical, >> please file it at: >> >> https://bugs.launchpad.net/congress/+filebug >> >> and tag it *newton-rc-potential* to bring it to the Congress release >> crew's attention. >> >> Note that the "master" branch of Congress is now open for Ocata >> development, and feature freeze restrictions no longer apply there! >> >> Thanks, >> Dims (On behalf of the Release Team) >> >> -- >> Davanum Srinivas :: https://twitter.com/dims > > > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs
Thanks for the prompt follow up Jeremy! -- Dims On Mon, Oct 3, 2016 at 3:19 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2016-10-03 16:11:25 + (+), Jeremy Stanley wrote: > [...] >> I think we can bring this thread to a close now. Upstream deleted >> the broken wheel from PyPI a little over an hour ago, and within >> about 5 minutes it disappeared from our CI system mirrors as well >> (PyPI deletions propagate automatically through our mirroring). At >> this point things _should_ be back to normal, and projects can >> probably start working on reverting or abandoning any temporary >> workarounds. > > I just learned that we (unnecessarily) also copy available wheels > from PyPI into our separate wheel mirrors when building > architecture-specific wheels as a side effect of trivially reusing > the wheel cache to populate it. Since those mirrors are effectively > append-only we ended up persisting a copy of the broken wheel there > even after it vanished from our PyPI mirror, and so it continued to > be found by jobs in our CI system. > > In the past few minutes I've cleared out vestigial copies of it > there, and we're reflecting on ways we can enhance our wheel > building jobs to omit duplication of wheels which are already > present on PyPI (which would be more intuitive and avoid situations > like this one). As far as I can tell things seem to be working in > the gate behind the constraints revert[*] now. > > [*] https://review.openstack.org/381192 > -- > Jeremy Stanley > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Adding gdavoian to oslo-core
+1 from me! On Mon, Oct 3, 2016 at 1:40 PM, Joshua Harlow <harlo...@fastmail.com> wrote: > Greetings all stackers, > > I propose that we add Gevorg Davoian[1] to the oslo-core[2] team. > > Gevorg has been actively contributing to oslo for a while now, both in > helping make oslo better via code contribution(s) and by helping with the > review load when he can. He has provided quality reviews and is doing an > awesome job with the various oslo concepts and helping make oslo the best it > can be! > > Overall I think he would make a great addition to the core review team. > > Please respond with +1/-1. > > Thanks much! > > - Joshua Harlow > > [1] https://launchpad.net/~gdavoian > [2] https://launchpad.net/oslo > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Adding ozamiatin to oslo-core
+1 from me!. On Mon, Oct 3, 2016 at 1:42 PM, Joshua Harlow <harlo...@fastmail.com> wrote: > Greetings all stackers, > > I propose that we add Oleksii Zamiatin[1] to the oslo-core[2] team. > > Oleksii has been actively contributing to oslo for a while now, both in > helping make oslo better via code contribution(s) and by helping with the > review load when he can. He has provided quality reviews and is doing an > awesome job with the various oslo concepts and helping make oslo the best it > can be! > > Overall I think he would make a great addition to the core review team. > > Please respond with +1/-1. > > Thanks much! > > - Joshua Harlow > > [1] https://launchpad.net/~ozamiatin > [2] https://launchpad.net/oslo > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs
Fun start for release week :) Thanks for the heads up Matt -- Dims On Sun, Oct 2, 2016 at 8:54 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > There was a pycparser 2.14 package update on pypi today which is making > cinder-manager db sync fail. This is making all dsvm/grenade jobs fail in > master and stable/newton. > > The upstream issue being tracked is: > > https://github.com/eliben/pycparser/issues/147 > > -- > > Thanks, > > Matt Riedemann > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][Congress] Congress Newton RC2 available (Congress Newton RC1 available)
Please verify RC2: https://tarballs.openstack.org/congress/congress-4.0.0.0rc2.tar.gz Thanks, Dims On Fri, Sep 16, 2016 at 12:45 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Hello everyone, > > The release candidate for Congress for the end of the Newton cycle > is available! You can find the RC1 source code tarball at: > > https://tarballs.openstack.org/congress/congress-4.0.0.0rc1.tar.gz > > Unless release-critical issues are found that warrant a release > candidate respin, this RC1 will be formally released as the final > Newton release on 6 October. You are therefore strongly > encouraged to test and validate this tarball! > > Alternatively, you can directly test the stable/newton release > branch at: > > http://git.openstack.org/cgit/openstack/congress/log/?h=stable/newton > > If you find an issue that could be considered release-critical, > please file it at: > > https://bugs.launchpad.net/congress/+filebug > > and tag it *newton-rc-potential* to bring it to the Congress release > crew's attention. > > Note that the "master" branch of Congress is now open for Ocata > development, and feature freeze restrictions no longer apply there! > > Thanks, > Dims (On behalf of the Release Team) > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][Designate] Designate Newton RC2 available
Hello everyone, A new release candidate for Designate for the end of the Newton cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/designate/designate-3.0.0.0rc2.tar.gz Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/newton release branch at: http://git.openstack.org/cgit/openstack/designate/log/?h=stable/newton If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/designate/+filebug and tag it *newton-rc-potential* to bring it to the Designate release crew's attention. Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][Nova] Nova Newton RC2 available
Hello everyone, A new release candidate for Nova for the end of the Newton cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova/nova-14.0.0.0rc2.tar.gz Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/newton release branch at: http://git.openstack.org/cgit/openstack/nova/log/?h=stable/newton If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova/+filebug and tag it *newton-rc-potential* to bring it to the Nova release crew's attention. Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][searchlight] RC3 available (was: searchlight Newton RC2 available)
A translation review trickled in late for searchlight-ui. So we cut a RC3: https://tarballs.openstack.org/searchlight-ui/searchlight-ui-1.0.0.0rc3.tar.gz Thanks, Dims On Thu, Sep 29, 2016 at 11:09 AM, Davanum Srinivas <dava...@gmail.com> wrote: > Hello everyone, > > The release candidate for searchlight for the end of the Newton cycle > is available! You can find the RC2 source code tarball at: > > https://tarballs.openstack.org/searchlight/searchlight-1.0.0.0rc2.tar.gz > https://tarballs.openstack.org/searchlight-ui/searchlight-ui-1.0.0.0rc2.tar.gz > > Unless release-critical issues are found that warrant a release > candidate respin, this RC2 will be formally released as the final > Newton release on 6 October. You are therefore strongly encouraged to > test and validate this tarball! > > Alternatively, you can directly test the stable/newton release branch at: > > http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/newton > > If you find an issue that could be considered release-critical, please > file it at: > > https://bugs.launchpad.net/searchlight/+filebug > > and tag it *newton-rc-potential* to bring it to the searchlight > release crew's attention. > > Note that the "master" branch of searchlight is now open for Ocata > development, and feature freeze restrictions no longer apply there! > > Thanks, > Dims > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][openstack-ansible] OpenStack-Ansible Newton RC2 available
Hello everyone, The release candidate for OpenStack-Ansible for the end of the Newton cycle is available! You can find the details at: https://releases.openstack.org/newton/index.html#newton-openstack-ansible Unless release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test these! If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/openstack-ansible/+filebug and tag it *newton-rc-potential* to bring it to the OpenStack-Ansible release crew's attention. Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][tripleo] Tripleo Newton RC2 available
Hello everyone, The release candidate for Tripleo for the end of the Newton cycle is available! You can find the RC2 source code tarballs at: https://tarballs.openstack.org/instack-undercloud/instack-undercloud-5.0.0.0rc2.tar.gz https://tarballs.openstack.org/puppet-tripleo/puppet-tripleo-5.2.0.tar.gz https://tarballs.openstack.org/python-tripleoclient/python-tripleoclient-5.2.0.tar.gz https://tarballs.openstack.org/tripleo-common/tripleo-common-5.2.0.tar.gz https://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-5.0.0.0rc2.tar.gz https://tarballs.openstack.org/tripleo-image-elements/tripleo-image-elements-5.0.0.0rc2.tar.gz https://tarballs.openstack.org/tripleo-puppet-elements/tripleo-puppet-elements-5.0.0.0rc2.tar.gz https://tarballs.openstack.org/tripleo-ui/tripleo-ui-1.0.3.tar.gz https://tarballs.openstack.org/os-collect-config/os-collect-config-5.0.0.0rc2.tar.gz https://tarballs.openstack.org/os-net-config/os-net-config-5.0.0.0rc2.tar.gz Unless release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test and validate these tarballs! If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/tripleo/+filebug and tag it *newton-rc-potential* to bring it to the Tripleo release crew's attention. Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][searchlight] searchlight Newton RC2 available
Hello everyone, The release candidate for searchlight for the end of the Newton cycle is available! You can find the RC2 source code tarball at: https://tarballs.openstack.org/searchlight/searchlight-1.0.0.0rc2.tar.gz https://tarballs.openstack.org/searchlight-ui/searchlight-ui-1.0.0.0rc2.tar.gz Unless release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/newton release branch at: http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/newton If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/searchlight/+filebug and tag it *newton-rc-potential* to bring it to the searchlight release crew's attention. Note that the "master" branch of searchlight is now open for Ocata development, and feature freeze restrictions no longer apply there! Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][senlin] Senlin Newton RC2 available
Hello everyone, The release candidate for Senlin for the end of the Newton cycle is available! You can find the RC2 source code tarball at: https://tarballs.openstack.org/senlin/senlin-2.0.0.0rc2.tar.gz Unless release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/newton release branch at: http://git.openstack.org/cgit/openstack/senlin/log/?h=stable/newton If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/senlin/+filebug and tag it *newton-rc-potential* to bring it to the senlin release crew's attention. Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][elections] Candidate proposals for TC (Technical Committee) positions are now open
Folks, 3 incumbents are not running. Many thanks to Russell, Anne, Kyle for their service and dedication (per TC meeting logs - http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.log.html) 9 candidates are running (per https://review.openstack.org/#/q/project:openstack/election). Now's a good time to help shape the future of OpenStack. Please consider stepping up to be a candidate for the TC! Thanks, Dims On Sun, Sep 25, 2016 at 8:08 PM, Tristan Cacqueray <tdeca...@redhat.com> wrote: > Candidate proposals for the Technical Committee positions (6 positions) > are now open and will remain open until 2016-10-01, 23:45 UTC > > All candidacies must be submitted as a text file to the > openstack/election repository as explained on the election website[1]. > Please note that the name of the file has changed this cycle to be the > candidates IRC nic *not* full-name. > > Also for TC candidates, election officials refer to the community member > profiles at [2] please take this opportunity to ensure that the you > profile contains current information. > > Candidates for the Technical Committee Positions: Any Foundation > individual member can propose their candidacy for an available, > directly-elected TC seat. (except the seven (7) TC members who were > elected for a one-year seat in April[3]). > > The election will be held from October 3rd through to 23:45 October 8th, > 2015 UTC. The electorate are the Foundation individual members that are > also committers for one of the official programs projects[4] over the > Mitaka-Newton timeframe (September 5, 2015 00:00 UTC to September 4, > 2016 23:59 UTC)), as well as the extra-ATCs who are acknowledged by the > TC[5]. > > Please see the website[1] for additional details about this election. > Please find below the timeline: > > TC nomination starts @ 2016-09-26, 00:00 UTC > TC nomination ends @ 2016-10-01, 23:45 UTC > TC elections begins@ 2016-10-03, 00:00 UTC > TC elections ends @ 2016-10-08, 23:45 UTC > > If you have any questions please be sure to either voice them on the > mailing list or to the elections officials[6]. > > Thank you, and we look forward to reading your candidate proposals, > -Tristan > > [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy > [2] http://www.openstack.org/community/members/ > [3] https://wiki.openstack.org/wiki/TC_Elections_April_2016#Results > [4] > http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2016-elections > Note the tag for this repo, sept-2016-elections. > [5] Look for the extra-atcs element in [4] > [6] http://governance.openstack.org/election/#election-officials > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][Cinder] Cinder Newton RC2 available
Hello everyone, A new release candidate for Cinder for the end of the Newton cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/cinder-9.0.0.0rc2.tar.gz Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/newton release branch at: http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/newton If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/cinder/+filebug and tag it *newton-rc-potential* to bring it to the Cinder release crew's attention. Thanks, Dims (On behalf of the OpenStack Release team) -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s
. I'd like to >>> explore in >>>more depth a Kubernetes based deployment of OpenStack. I'm familiar >>> with both >>>kolla-kubernetes and fuel-ccp, their structure and direction*. Both >>> projects >>>have now advanced a bit in their implementations and made some >>> decisions. >>> >>>As someone that started looking into this topic just recently, I'd >>> love to see >>>our communities collaborate more wherever possible. For example, it'd >>> be great >>>to see us working on a reference architecture for deploying OpenStack >>> on >>>kubernetes, letting the implementation details aside for a bit. I'd >>> assume some >>>folks have done this already and I bet we can all learn more from it >>> if we work >>>on this together. >>> >>>So, let me go ahead and ask some further questions here, I might be >>> missing some >>>history and/or context: >>> >>>- Is there any public documentation that acts as a reference >>> architecture for >>> deploying OpenStack on kubernetes? >>>- Is this something the architecture working group could help with? Or >>> would it >>> be better to hijack one of kolla meetings? >>> >>>The restult I'd love to see from this collaboration is a reference >>> architecture >>>explaining how OpenStack should be run on Kubernetes. >>> >>>Thanks in advance. I look forward to see us collaborate more on this >>> area, >>>Flavio >>> >>>* thanks to all fuel and kolla contributors that helped me understand >>> better the >>> work in each of these projects and the direction they are headed >>>. >>>-- >>>@flaper87 >>>Flavio Percoco >>> >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> -- >>> @flaper87 >>> Flavio Percoco >>> >> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> -- >> @flaper87 >> Flavio Percoco >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > @flaper87 > Flavio Percoco > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][neutron] networking-ovn Newton RC2 available
Hello everyone, The release candidate for networking-ovn for the end of the Newton cycle is available! You can find the RC2 source code tarball at: https://tarballs.openstack.org/networking-ovn/networking-ovn-1.0.0.0rc2.tar.gz Unless release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/newton release branch at: http://git.openstack.org/cgit/openstack/networking-ovn/log/?h=stable/newton If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/networking-ovn/+filebug and tag it *newton-rc-potential* to bring it to the networking-ovn release crew's attention. Thanks, Dims (On behalf of the Release Team) -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security] XML Attacks and DefusedXML on Global Requirements
We already debated this in https://review.openstack.org/#/c/311857/ All the lessons learned from DefusedXML was already incorporated in various python packages. You can test this theory out by using the test xml(s) in DefusedXML if you wish. Also note that there have been no changes to the source code since 2013 (https://bitbucket.org/tiran/defusedxml/commits/branch/default) Thanks, Dims On Tue, Sep 27, 2016 at 1:24 PM, Travis McPeak <travis.mcp...@gmail.com> wrote: > There are several attacks (https://pypi.python.org/pypi/defusedxml#id3) that > can be performed when XML is parsed from untrusted input. DefusedXML offers > safe alternatives to XML parsing libraries but is not currently part of > global requirements. > > I propose adding DefusedXML to global requirements so that projects have an > option for safe XML parsing. Does anybody have any thoughts or objections? > > Thanks, > -Travis > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent
Sorry for the top post - fyi, i've submitted a review for OpenStackSalt https://review.openstack.org/#/c/377906/ -- Dims On Mon, Sep 26, 2016 at 2:58 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 22/09/16 17:15 -0400, Anita Kuno wrote: >> >> On 16-09-21 01:11 PM, Doug Hellmann wrote: >>> >>> Excerpts from Clint Byrum's message of 2016-09-21 08:56:24 -0700: >>>> >>>> I think it might also be useful if we could make the meeting bot remind >>>> teams of any pending actions they need to take such as elections upon >>>> #startmeeting. >>> >>> I could see that being useful, yes. >>> >> I am not convinced this situation arose due to lack of available >> information. > > > You may be right here but I don't think having other means to spread this > information is a bad thing, if there's a way to automate this, of course. > > Flavio > > -- > @flaper87 > Flavio Percoco > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release][Sahara] Sahara Newton RC2 available
Hello everyone, The release candidate(s) for Sahara for the end of the Newton cycle are available! You can find the RC2 source code tarballs at: https://tarballs.openstack.org/sahara/sahara-5.0.0.0rc2.tar.gz https://tarballs.openstack.org/sahara-dashboard/sahara-dashboard-5.0.0.0rc2.tar.gz https://tarballs.openstack.org/sahara-extra/sahara-extra-5.0.0.0rc2.tar.gz https://tarballs.openstack.org/sahara-image-elements/sahara-image-elements-5.0.0.0rc2.tar.gz Unless release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as the final Newton release on 6 October. You are therefore strongly encouraged to test and validate these tarballs! Alternatively, you can directly test the stable/newton release branches at: http://git.openstack.org/cgit/openstack/sahara/log/?h=stable/newton http://git.openstack.org/cgit/openstack/sahara-dashboard/log/?h=stable/newton http://git.openstack.org/cgit/openstack/sahara-extra/log/?h=stable/newton http://git.openstack.org/cgit/openstack/sahara-image-elements/log/?h=stable/newton If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/sahara/+filebug and tag it *newton-rc-potential* to bring it to the Sahara release crew's attention. Thanks, Dims (On behalf of the Release Team) -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent
Steven, Fair point. Thanks, Dims On Thu, Sep 22, 2016 at 11:04 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > Dims, > > This isn’t any of my particular business except it could affect emerging > technology projects (which I find important to OpenStack’s future) negatively > – so I thought I’d chime in. > > A lack of activity in a specs repo doesn’t mean much to me. For example, as > Kolla was an emerging project we didn’t use any specs process at all (or very > rarely). There is a reason behind this. Now that Kolla is stable and > reliable and we feel we are not an emerging project, we plan to make use of a > specs repo starting in Ocata. > > I have no particular concerns with the other commentary – but please don’t > judge a project by activity or lack of activity in one repo of its > deliverables. Judge it holistically (You are judging holistically. I > believe a lack of one repo’s activity shouldn’t be part of that judgement). > > Regards > -steve > > > On 9/21/16, 2:08 PM, "Davanum Srinivas" <dava...@gmail.com> wrote: > > Jakub, > > Please see below. > > On Wed, Sep 21, 2016 at 3:46 PM, Jakub Pavlik <jakub.pav...@tcpcloud.eu> > wrote: > > Hello all, > > > > it took us 2 years of hard working to get these official. > OpenStack-Salt is > > now used by around 40 production deployments and it is focused very on > > operation and popularity is growing. You are removing the project week > after > > one of top contributor announced that they will use that as part of > > solution. We made a mistakes, however I do not think that is reason to > > remove us. I do no think that quality of the project is measured like > this. > > Our PTL got ill and did not do properly his job for last 3 weeks, but > this > > can happen anybody. > > > > It is up to you. If you think that we are useless for community, then > > remove us and we will have to continue outside of this community. > However > > growing successful use cases will not be under official openstack > community, > > which makes my feeling bad. > > Data points so far are: > 1. No response during Barcelona planning for rooms > 2. Lack of candidates for PTL election > 3. No activity in the releases/ repository hence no entries in > https://releases.openstack.org/ > 4. Meetings are not so regular? > http://eavesdrop.openstack.org/meetings/openstack_salt/2016/ (supposed > to be weekly) > 5. Is the specs repo really active? > http://git.openstack.org/cgit/openstack/openstack-salt-specs/ is the > work being done elsewhere? > 6. Is there an effort to add stuff to the CI jobs running on openstack > infrastructure? (can't seem to find much > > http://codesearch.openstack.org/?q=salt=nope=zuul%2Flayout.yaml=project-config) > > I'll stop here and switch to #openstack-salt channel to help work you > all through if there is a consensus/willingness from the > openstack-salt team that there's significant work to be done. If you > think you are better off not on the governance, that would be your > call as well. > > Thanks, > Dims > > > Thanks, > > > > Jakub > > > > > > On 21.9.2016 21:03, Doug Hellmann wrote: > >> > >> Excerpts from Filip Pytloun's message of 2016-09-21 20:36:42 +0200: > >>> > >>> On 2016/09/21 13:23, Doug Hellmann wrote: > >>>> > >>>> The idea of splitting the contributor list comes up pretty regularly > >>>> and we rehash the same suggestions each time. Given that what we > >>>> have now worked fine for 57 of the 59 offical teams (the Astara > >>>> team knew in advance it would not have a PTL running, and Piet had > >>>> some sort of technical issue submitting his candidacy for the UX > >>>> team), I'm not yet convinced that we need to make large-scale changes > >>>> to our community communication standard practices in support of the > >>>> 2 remaining teams. > >>>> > >>>> That's not to say that the system we have now is perfect, but we > >>>> can't realistically support multiple systems at the same time. We > >>>> need everyone to use the same system, otherwise we have (even more) > >>>> fragmented communication. So, we either need everyone to agree to > >>>> some new system and
