Re: [openstack-dev] [tricircle] Nominate change in tricircle core team
+1 在 2018-08-11 10:04，linghucongsong 写道： At 2018-08-09 20:04:40, "linghucongsong" wrote: Hi team, I would like to nominate Zhuo Tang (ztang) for tricircle core member. ztang has actively joined the discussion of feature development in our offline meeting and has participated in contribute important blueprints since Rocky, like network deletion reliability and service function chaining. I really think his experience will help us substantially improve tricircle. Bye the way the vote unitl 2018-8-16 beijing time. Best Wishes! Baisen __ 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][tc][election] Timing of the Upcoming Stein TC election
I created the patch to setup the tc election: https://review.openstack.org/#/c/59/ -Kendall (diablo_rojo) On Fri, Aug 10, 2018 at 9:44 AM Doug Hellmann wrote: > Excerpts from Tony Breeds's message of 2018-08-10 07:44:42 +1000: > > On Thu, Aug 09, 2018 at 05:20:53PM -0400, Doug Hellmann wrote: > > > Excerpts from Tony Breeds's message of 2018-08-08 14:39:30 +1000: > > > > Hello all, > > > > With the PTL elections behind us it's time to start looking at > the > > > > TC election. Our charter[1] says: > > > > > > > > The election is held no later than 6 weeks prior to each OpenStack > > > > Summit (on or before ‘S-6’ week), with elections held open for no > less > > > > than four business days. > > > > > > > > Assuming we have the same structure that gives us a timeline of: > > > > > > > > Summit is at: 2018-11-13 > > > > Latest possible completion is at: 2018-10-02 > > > > Moving back to Tuesday: 2018-10-02 > > > > TC Election from 2018-09-25T23:45 to 2018-10-02T23:45 > > > > TC Campaigning from 2018-09-18T23:45 to 2018-09-25T23:45 > > > > TC Nominations from 2018-09-11T23:45 to 2018-09-18T23:45 > > > > > > > > This puts the bulk of the nomination period during the PTG, which is > > > > sub-optimal as the nominations cause a distraction from the PTG but > more > > > > so because the campaigning will coincide with travel home, and some > > > > community members take vacation along with the PTG. > > > > > > > > So I'd like to bring up the idea of moving the election forward a > > > > little so that it's actually the campaigning period that overlaps > with > > > > the PTG: > > > > > > > > TC Electionfrom 2018-09-18T23:45 to 2018-09-27T23:45 > > > > TC Campaigning from 2018-09-06T23:45 to 2018-09-18T23:45 > > > > TC Nominations from 2018-08-30T23:45 to 2018-09-06T23:45 > > > > > > > > This gives us longer campaigning and election periods. > > > > > > > > There are some advantages to doing this: > > > > > > > > * A panel style Q could be held formally or informally ;P > > > > * There's improved scope for for incoming, outgoing and staying put > TC > > > >members to interact in a high bandwidth way. > > > > * In personi/private discussions with TC candidates/members. > > > > > > > > However it isn't without downsides: > > > > > > > > * Election fatigue, We've just had the PTL elections and the UC > > > > elections are currently running. Less break before the TC > elections > > > > may not be a good thing. > > > > * TC candidates that can't travel to the PTG could be disadvantaged > > > > * The campaigning would all happen at the PTG and not on the > mailing > > > > list disadvantaging community members not at the PTG. > > > > > > > > So thoughts? > > > > > > > > Yours Tony. > > > > > > > > [1] https://governance.openstack.org/tc/reference/charter.html > > > > > > Who needs to make this decision? The current TC? > > > > I believe that the TC delegated that to the Election WG [1] but the > > governance here is a little gray/fuzzy. > > OK, I'm content for the Election team to make the call I just wanted to > make sure I gave you an opinion if you were asking me for one. ;-) > > > So I kinda think that if the TC doesn't object I can propose the patch > > to the election repo and you (as TC chair) can +/-1 is as you see fit. > > > > Is it fair to ask we do that shortly after the next TC office hours? > > +1 > > > > > Yours Tony. > > > > [1] https://governance.openstack.org/tc/reference/working-groups.html > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures][masakari][release] Pre-release of openstack/masakari failed
Hi Doug, Thanks. I will fix this. --- Regards, Sampath On Fri, Aug 10, 2018 at 2:51 AM Doug Hellmann wrote: > Excerpts from zuul's message of 2018-08-09 17:23:01 +: > > Build failed. > > > > - release-openstack-python > http://logs.openstack.org/84/84135048cb372cbd11080fc27151949cee4e52d1/pre-release/release-openstack-python/095990b/ > : FAILURE in 8m 57s > > - announce-release announce-release : SKIPPED > > - propose-update-constraints propose-update-constraints : SKIPPED > > > > The RC1 build for Masakari failed with this error: > > error: can't copy 'etc/masakari/masakari-custom-recovery-methods.conf': > doesn't exist or not a regular file > > The packaging files need to be fixed so a new release candidate can be > prepared. The changes will need to be made on master and then backported > to the new stable/rocky branch. > > Doug > > > http://logs.openstack.org/84/84135048cb372cbd11080fc27151949cee4e52d1/pre-release/release-openstack-python/095990b/ara-report/result/7459d483-48d8-414f-8830-d6411158f9a2/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sdk] Pruning core team
On 08/10/2018 12:53 PM, Dean Troyer wrote: On Fri, Aug 10, 2018 at 7:06 AM, Monty Taylor wrote: I'd like to propose removing Brian Curtin, Clint Byrum, David Simard, and Ricardo Cruz. Thoughts/concerns? Reluctant +1, thanks guys for all the hard work! +100 to the reluctant - and the thanks __ 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] [sdk] Pruning core team
On Fri, Aug 10, 2018 at 7:06 AM, Monty Taylor wrote: > I'd like to propose removing Brian Curtin, Clint Byrum, David Simard, and > Ricardo Cruz. > > Thoughts/concerns? Reluctant +1, thanks guys for all the hard work! dt -- Dean Troyer dtro...@gmail.com __ 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] designate-dashboard 7.0.0.0rc1 (rocky)
Hello everyone, A new release candidate for designate-dashboard for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/designate-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Rocky release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/rocky release branch at: http://git.openstack.org/cgit/openstack/designate-dashboard/log/?h=stable/rocky Release notes for designate-dashboard can be found at: http://docs.openstack.org/releasenotes/designate-dashboard/ __ 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] masakari-monitors 6.0.0.0rc1 (rocky)
Hello everyone, A new release candidate for masakari-monitors for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/masakari-monitors/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Rocky release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/rocky release branch at: http://git.openstack.org/cgit/openstack/masakari-monitors/log/?h=stable/rocky Release notes for masakari-monitors can be found at: http://docs.openstack.org/releasenotes/masakari-monitors/ If you find an issue that could be considered release-critical, please file it at: http://bugs.launchpad.net/masakari-monitors and tag it *rocky-rc-potential* to bring it to the masakari-monitors release crew's attention. __ 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] designate 7.0.0.0rc1 (rocky)
Hello everyone, A new release candidate for designate for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/designate/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Rocky release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/rocky release branch at: http://git.openstack.org/cgit/openstack/designate/log/?h=stable/rocky Release notes for designate can be found at: http://docs.openstack.org/releasenotes/designate/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/designate and tag it *rocky-rc-potential* to bring it to the designate release crew's attention. __ 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][tricircle] FFE for python-tricircleclient
On 18-08-10 11:20:13, Sean McGinnis wrote: > This is a requirements FFE to raise the upper-constraints for > python-tricircleclient. > > This client only has some requirements and CI changes merged, but it has not > > done any releases during the rocky cycle. It is well past client lib freeze, > > but as stated in our policy, we will need to force a final release so there > is > a rocky version and these requirements and CI changes are in the stable/rocky > > branch of the repo. > > requirements FFE approved for UC only. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][karbor] FFE for python-karborclient
On 18-08-10 11:18:33, Sean McGinnis wrote: > This is requesting a requirements FFE to raise u-c for python-karborclient. > > This client only has some requirements and CI changes merged, but it has not > done any releases during the rocky cycle. It is well past client lib freeze, > but as stated in our policy, we will need to force a final release so there is > a rocky version and these requirements and CI changes are in the stable/rocky > branch of the repo. > > There is one caveat with this release in that the karbor service has not done > a > release for rocky yet. If one is not done by the final cycle-with-intermediary > deadline, karbor will need to be excluded from the Rocky coordinated release. > This would include service and clients. > requirements FFE approved for UC only. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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][tc][election] Timing of the Upcoming Stein TC election
Excerpts from Tony Breeds's message of 2018-08-10 07:44:42 +1000: > On Thu, Aug 09, 2018 at 05:20:53PM -0400, Doug Hellmann wrote: > > Excerpts from Tony Breeds's message of 2018-08-08 14:39:30 +1000: > > > Hello all, > > > With the PTL elections behind us it's time to start looking at the > > > TC election. Our charter[1] says: > > > > > > The election is held no later than 6 weeks prior to each OpenStack > > > Summit (on or before ‘S-6’ week), with elections held open for no less > > > than four business days. > > > > > > Assuming we have the same structure that gives us a timeline of: > > > > > > Summit is at: 2018-11-13 > > > Latest possible completion is at: 2018-10-02 > > > Moving back to Tuesday: 2018-10-02 > > > TC Election from 2018-09-25T23:45 to 2018-10-02T23:45 > > > TC Campaigning from 2018-09-18T23:45 to 2018-09-25T23:45 > > > TC Nominations from 2018-09-11T23:45 to 2018-09-18T23:45 > > > > > > This puts the bulk of the nomination period during the PTG, which is > > > sub-optimal as the nominations cause a distraction from the PTG but more > > > so because the campaigning will coincide with travel home, and some > > > community members take vacation along with the PTG. > > > > > > So I'd like to bring up the idea of moving the election forward a > > > little so that it's actually the campaigning period that overlaps with > > > the PTG: > > > > > > TC Electionfrom 2018-09-18T23:45 to 2018-09-27T23:45 > > > TC Campaigning from 2018-09-06T23:45 to 2018-09-18T23:45 > > > TC Nominations from 2018-08-30T23:45 to 2018-09-06T23:45 > > > > > > This gives us longer campaigning and election periods. > > > > > > There are some advantages to doing this: > > > > > > * A panel style Q could be held formally or informally ;P > > > * There's improved scope for for incoming, outgoing and staying put TC > > >members to interact in a high bandwidth way. > > > * In personi/private discussions with TC candidates/members. > > > > > > However it isn't without downsides: > > > > > > * Election fatigue, We've just had the PTL elections and the UC > > > elections are currently running. Less break before the TC elections > > > may not be a good thing. > > > * TC candidates that can't travel to the PTG could be disadvantaged > > > * The campaigning would all happen at the PTG and not on the mailing > > > list disadvantaging community members not at the PTG. > > > > > > So thoughts? > > > > > > Yours Tony. > > > > > > [1] https://governance.openstack.org/tc/reference/charter.html > > > > Who needs to make this decision? The current TC? > > I believe that the TC delegated that to the Election WG [1] but the > governance here is a little gray/fuzzy. OK, I'm content for the Election team to make the call I just wanted to make sure I gave you an opinion if you were asking me for one. ;-) > So I kinda think that if the TC doesn't object I can propose the patch > to the election repo and you (as TC chair) can +/-1 is as you see fit. > > Is it fair to ask we do that shortly after the next TC office hours? +1 > > Yours Tony. > > [1] https://governance.openstack.org/tc/reference/working-groups.html __ 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] [tc] [all] documenting appointed PTLs
Excerpts from Chris Dent's message of 2018-08-10 16:19:27 +0100: > > We've had several appointed PTLs this cycle, in some cases because > people forgot to nominate themselves, in other cases because > existing maintainers have been pulled away and volunteers stepped > up. Thanks to those people who did. > > We haven't had a formal process for documenting those appointments > and there's been some confusion on who and where it should all > happen. I've proposed a plan at > > https://review.openstack.org/#/c/590790/ > > that may not yet be perfect, but gives a starting point on which > to accrete a reasonable solution. > > If you have opinions on the matter, please leave something on the > review. > > Thanks. > Thanks for writing that up, Chris. 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-dev] [requirements][tricircle] FFE for python-tricircleclient
This is a requirements FFE to raise the upper-constraints for python-tricircleclient. This client only has some requirements and CI changes merged, but it has not done any releases during the rocky cycle. It is well past client lib freeze, but as stated in our policy, we will need to force a final release so there is a rocky version and these requirements and CI changes are in the stable/rocky branch of the repo. Sean __ 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][karbor] FFE for python-karborclient
This is requesting a requirements FFE to raise u-c for python-karborclient. This client only has some requirements and CI changes merged, but it has not done any releases during the rocky cycle. It is well past client lib freeze, but as stated in our policy, we will need to force a final release so there is a rocky version and these requirements and CI changes are in the stable/rocky branch of the repo. There is one caveat with this release in that the karbor service has not done a release for rocky yet. If one is not done by the final cycle-with-intermediary deadline, karbor will need to be excluded from the Rocky coordinated release. This would include service and clients. Sean __ 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] [keystone] Keystone Team Update - Week of 6 August 2018
# Keystone Team Update - Week of 6 August 2018 ## News ### RC1 We released RC1 this week[1]. Please try it out and be on the lookout for critical bugs. As of yet we don't seem to have any showstoppers that would require another RC. [1] https://releases.openstack.org/rocky/index.html#rocky-keystone ### Edge Discussions The OpenNFV Edge Cloud group and the Edge Computing Group are ramping up implementations of proofs of concept for the potential keystone architectures for edge cloud scenarios. Some of the models under investigation or that we've suggested[2] are keystone-to-keystone federation, regular federation with an external identity provider, database synchronization via database replication[3] and database synchronization via an agent. One idea to enhance the federation-based models is to make application credentials refreshable, which Kristi is going to write a spec for[4]. I encourage the team to join the meeting calls[5][6], to help the people working on implementations, and volunteer for technical work items. It would be great to be at a point where we can discuss design details for the next cycle at the PTG. [2] https://wiki.openstack.org/wiki/Keystone_edge_architectures [3] https://review.openstack.org/566448 [4] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-07.log.html#t2018-08-07T15:34:54 [5] https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings [6] https://wiki.opnfv.org/display/PROJ/Edge+cloud ### Flask Work Morgan has been diligently working on converting our APIs to Flask, please see the many outstanding reviews[7]. Some of these conversions should be parallelizeable so if you'd like to help him out I'm sure he would appreciate it, just coordinate with him[8]. [7] https://review.openstack.org/#/q/status:open+topic:bug/1776504 [8] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-06.log.html#t2018-08-06T20:31:19 ### Self-Service Keystone At the weekly meeting Adam suggested we make self-service keystone a focus point of the PTG[9]. Currently, policy limitations make it difficult for an unprivileged keystone user to get things done or to get information without the help of an administrator. There are some other projects that have been created to act as workflow proxies to mitigate keystone's limitations, such as Adjutant[10] (now an official OpenStack project) and Ksproj[11] (written by Kristi). The question is whether the primitives offered by keystone are sufficient building blocks for these external tools to leverage, or if we should be doing more of this logic within keystone. Certainly improving our RBAC model is going to be a major part of improving the self-service user experience. [9] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-08-07-16.00.log.html#l-121 [10] https://adjutant.readthedocs.io/en/latest/ [11] https://github.com/CCI-MOC/ksproj ### Standalone Keystone Also at the meeting and during office hours, we revived the discussion of what it would take to have a standalone keystone be a useful identity provider for non-OpenStack projects[12][13]. First up we'd need to turn keystone into a fully-fledged SAML IdP, which it's not at the moment (which is a point of confusion in our documentation), or even add support for it to act as an OpenID Connect IdP. This would be relatively easy to do (or at least not impossible). Then the application would have to use keystonemiddleware or its own middleware to route requests to keystone to issue and validate tokens (this is one aspect where we've previously discussed whether JWT could benefit us). Then the question is what should a not-OpenStack application do with keystone's "scoped RBAC"? It would all depend on how the resources of the application are grouped and whether they care about multitenancy in some form. Likely each application would have different needs and it would be difficult to find a one-size-fits-all approach. We're interested to know whether anyone has a burning use case for something like this. [12] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-08-07-16.00.log.html#l-192 [13] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-07.log.html#t2018-08-07T17:01:30 ### PTG Planning We're in the brainstorming phase for the PTG, please add topics to the etherpad[14]. Lance will organize these into an agenda soonish. [14] https://etherpad.openstack.org/p/keystone-stein-ptg ## Recently Merged Changes Search query: https://bit.ly/2IACk3F We merged 16 changes this week. ## Changes that need Attention Search query: https://bit.ly/2wv7QLK There are 54 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. Special attention should be given to patches that close bugs, and we should make sure we backport any critical bugfixes to stable/rocky.
Re: [openstack-dev] [requirements][ffe] FFE for python-designateclient 2.10.0
On 18-08-10 16:28:00, Graham Hayes wrote: > Hi all, > > I would like to ask for a FFE to release python-designateclient 2.10.0 > [1] > > We did not do a release at all during the rocky cycle, and this allows > us to create a stable/rocky branch > > It just requires a U-C bump, and contains a few bug fixes from 2.9.0. > > Thanks, > > Graham > > 1 - https://review.openstack.org/590776 > As discussed during the releases meeting, ack from reqs -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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] FFE for python-designateclient 2.10.0
Hi all, I would like to ask for a FFE to release python-designateclient 2.10.0 [1] We did not do a release at all during the rocky cycle, and this allows us to create a stable/rocky branch It just requires a U-C bump, and contains a few bug fixes from 2.9.0. Thanks, Graham 1 - https://review.openstack.org/590776 signature.asc Description: OpenPGP digital signature __ 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] [tc] [all] documenting appointed PTLs
We've had several appointed PTLs this cycle, in some cases because people forgot to nominate themselves, in other cases because existing maintainers have been pulled away and volunteers stepped up. Thanks to those people who did. We haven't had a formal process for documenting those appointments and there's been some confusion on who and where it should all happen. I've proposed a plan at https://review.openstack.org/#/c/590790/ that may not yet be perfect, but gives a starting point on which to accrete a reasonable solution. If you have opinions on the matter, please leave something on the review. Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ 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] [sdk] Propose adding Dmitry Tantsur to openstacksdk-core
+1 On Fri, Aug 10, 2018 at 17:14, David Shrewsbury wrote: +1 On Fri, Aug 10, 2018 at 8:55 AM Slawomir Kaplonski < skapl...@redhat.com [skapl...@redhat.com] > wrote: +1 > Wiadomość napisana przez Monty Taylor < mord...@inaugust.com > [mord...@inaugust.com] > w dniu 10.08.2018, o godz. 14:06: > > Hey everybody, > > I'd like to propose Dmitry Tantsur (dtantsur) as a new openstacksdk core team > member. He's been diving in to some of the hard bits, such as dealing with > microversions, and has a good grasp of the resource/proxy layer. His reviews > have been super useful broadly, and he's also helping drive Ironic related > functionality. > > Thoughts/concerns? > > Thanks! > Monty > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > [http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev] — Slawek Kaplonski Senior software engineer Red Hat __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev] -- David Shrewsbury (Shrews) __ 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-dev] [barbican][oslo] FFE request for castellan
Hi all, I'd like to request a feature freeze exception to get the following change in for castellan. https://review.openstack.org/#/c/575800/ This extends the functionality of the vault backend to provide previously uninmplemented functionality, so it should not break anyone. The castellan vault plugin is used behind barbican in the barbican- vault plugin. We'd like to get this change into Rocky so that we can release Barbican with complete functionality on this backend (along with a complete set of passing functional tests). Thanks, Ade __ 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] [sdk] Propose adding Dmitry Tantsur to openstacksdk-core
+1 On Fri, Aug 10, 2018 at 8:55 AM Slawomir Kaplonski wrote: > +1 > > > Wiadomość napisana przez Monty Taylor w dniu > 10.08.2018, o godz. 14:06: > > > > Hey everybody, > > > > I'd like to propose Dmitry Tantsur (dtantsur) as a new openstacksdk core > team member. He's been diving in to some of the hard bits, such as dealing > with microversions, and has a good grasp of the resource/proxy layer. His > reviews have been super useful broadly, and he's also helping drive Ironic > related functionality. > > > > Thoughts/concerns? > > > > Thanks! > > Monty > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > __ > 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 > -- David Shrewsbury (Shrews) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do
Hi,
On Fri, Aug 10, 2018 at 5:00 AM, Wesley Hayutin wrote:
>
>
> On Thu, Aug 9, 2018 at 5:33 PM Alex Schultz wrote:
>
>> On Thu, Aug 9, 2018 at 2:56 PM, Doug Hellmann
>> wrote:
>> > Excerpts from Alex Schultz's message of 2018-08-09 14:31:34 -0600:
>> >> Ahoy folks,
>> >>
>> >> I think it's time we come up with some basic rules/patterns on where
>> >> code lands when it comes to OpenStack related Ansible roles and as we
>> >> convert/export things. There was a recent proposal to create an
>> >> ansible-role-tempest[0] that would take what we use in
>> >> tripleo-quickstart-extras[1] and separate it for re-usability by
>> >> others. So it was asked if we could work with the openstack-ansible
>> >> team and leverage the existing openstack-ansible-os_tempest[2]. It
>> >> turns out we have a few more already existing roles laying around as
>> >> well[3][4].
>> >>
>> >> What I would like to propose is that we as a community come together
>> >> to agree on specific patterns so that we can leverage the same roles
>> >> for some of the core configuration/deployment functionality while
>> >> still allowing for specific project specific customization. What I've
>> >> noticed between all the project is that we have a few specific core
>> >> pieces of functionality that needs to be handled (or skipped as it may
>> >> be) for each service being deployed.
>> >>
>> >> 1) software installation
>> >> 2) configuration management
>> >> 3) service management
>> >> 4) misc service actions
>> >>
>> >> Depending on which flavor of the deployment you're using, the content
>> >> of each of these may be different. Just about the only thing that is
>> >> shared between them all would be the configuration management part.
>> >
>> > Does that make the 4 things separate roles, then? Isn't the role
>> > usually the unit of sharing between playbooks?
>> >
>>
>> It can be, but it doesn't have to be. The problem comes in with the
>> granularity at which you are defining the concept of the overall
>> action. If you want a role to encompass all that is "nova", you could
>> have a single nova role that you invoke 5 different times to do the
>> different actions during the overall deployment. Or you could create a
>> role for nova-install, nova-config, nova-service, nova-cells, etc etc.
>> I think splitting them out into their own role is a bit too much in
>> terms of management. In my particular openstack-ansible is already
>> creating a role to manage "nova". So is there a way that I can
>> leverage part of their process within mine without having to duplicate
>> it. You can pull in the task files themselves from a different so
>> technically I think you could define a ansible-role-tripleo-nova that
>> does some include_tasks: ../../os_nova/tasks/install.yaml but then
>> we'd have to duplicate the variables in our playbook rather than
>> invoking a role with some parameters.
>>
>> IMHO this structure is an issue with the general sharing concepts of
>> roles/tasks within ansible. It's not really well defined and there's
>> not really a concept of inheritance so I can't really extend your
>> tasks with mine in more of a programming sense. I have to duplicate it
>> or do something like include a specific task file from another role.
>> Since I can't really extend a role in the traditional OO programing
>> sense, I would like to figure out how I can leverage only part of it.
>> This can be done by establishing ansible variables to trigger specific
>> actions or just actually including the raw tasks themselves. Either
>> of these concepts needs some sort of contract to be established to the
>> other won't get broken. We had this in puppet via parameters which
>> are checked, there isn't really a similar concept in ansible so it
>> seems that we need to agree on some community established rules.
>>
>> For tripleo, I would like to just invoke the os_nova role and pass in
>> like install: false, service: false, config_dir:
>> /my/special/location/, config_data: {...} and it spit out the configs.
>> Then my roles would actually leverage these via containers/etc. Of
>> course most of this goes away if we had a unified (not file based)
>> configuration method across all services (openstack and non-openstack)
>> but we don't. :D
>>
>
> I like your idea here Alex.
> So having a role for each of these steps is too much management I agree,
> however
> establishing a pattern of using tasks for each step may be a really good
> way to cleanly handle this.
>
> Are you saying something like the following?
>
> openstack-nova-role/
> * * /tasks/
> * * /tasks/install.yml
> * * /tasks/service.yml
> * */tasks/config.yml
> * */taks/main.yml
> ---
> # main.yml
>
I like the idea. We may also add upgrade tasks here also
>
> include: install.yml
> when: nova_install|bool
>
> include: service.yml
> when: nova_service|bool
>
> include: config.yml
> when: nova_config.yml
> --
Re: [openstack-dev] [sdk] Pruning core team
Good from me, as I cannot spend cycles on reviewing code on my current position. Long live shade! El vie., 10 ago. 2018 a las 14:07, Monty Taylor () escribió: > Hey everybody, > > We have some former contributors who haven't been involved in the last > cycle that we should prune from the roster. They're all wonderful humans > and it would be awesome to have them back if life presented them an > opportunity to be involved again. > > I'd like to propose removing Brian Curtin, Clint Byrum, David Simard, > and Ricardo Cruz. > > Thoughts/concerns? > > Thanks! > Monty > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ 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] [sdk] Propose adding Dmitry Tantsur to openstacksdk-core
+1 > Wiadomość napisana przez Monty Taylor w dniu > 10.08.2018, o godz. 14:06: > > Hey everybody, > > I'd like to propose Dmitry Tantsur (dtantsur) as a new openstacksdk core team > member. He's been diving in to some of the hard bits, such as dealing with > microversions, and has a good grasp of the resource/proxy layer. His reviews > have been super useful broadly, and he's also helping drive Ironic related > functionality. > > Thoughts/concerns? > > Thanks! > Monty > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev — Slawek Kaplonski Senior software engineer Red Hat __ 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] [sdk] Propose adding Dmitry Tantsur to openstacksdk-core
+1 On Fri, 10 Aug 2018, 14:06 Monty Taylor, wrote: > Hey everybody, > > I'd like to propose Dmitry Tantsur (dtantsur) as a new openstacksdk core > team member. He's been diving in to some of the hard bits, such as > dealing with microversions, and has a good grasp of the resource/proxy > layer. His reviews have been super useful broadly, and he's also helping > drive Ironic related functionality. > > Thoughts/concerns? > > Thanks! > Monty > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ 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] [sdk] Pruning core team
Hey everybody, We have some former contributors who haven't been involved in the last cycle that we should prune from the roster. They're all wonderful humans and it would be awesome to have them back if life presented them an opportunity to be involved again. I'd like to propose removing Brian Curtin, Clint Byrum, David Simard, and Ricardo Cruz. Thoughts/concerns? Thanks! Monty __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sdk] Propose adding Dmitry Tantsur to openstacksdk-core
Hey everybody, I'd like to propose Dmitry Tantsur (dtantsur) as a new openstacksdk core team member. He's been diving in to some of the hard bits, such as dealing with microversions, and has a good grasp of the resource/proxy layer. His reviews have been super useful broadly, and he's also helping drive Ironic related functionality. Thoughts/concerns? Thanks! Monty __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do
> On 8/10/18, 3:20 AM, "Paul Belanger" wrote: > >This is basically what I do with roles i write, allow the user to decide > to step >over specific tasks. For example, I have created nodepool_task_manager > variable >with the following: > > > http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/defaults/main.yaml#n16 > > http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/tasks/main.yaml > >Been using it for a few years now, works much better then tags for me. The >phases are pre, install, configure, service right now. Hi folks, I'm really happy that this conversation is happening. Thanks to Alex for raising it! The task routing pattern is a reasonably good one, and is something which OSA is very likely to move towards in the future. Something else which I've always liked about the pattern used by the role's Paul has put together is that they clearly state the input expectation - for example, the role does not manage apt repositories, or implement any apt refreshes. This is the kind of thing that I think is going to be important - the role should be clear about what it does, clear about the inputs it expects, and the outputs of it. This will mean that the internals of the role can change, but those inputs are like an API - if you give the role that, it must always output the same result. I can see it possibly being useful to include things like how to test the service in the service role, how to evaluate the health, how to enact an upgrade, how to enact a fast-forward upgrade, etc. But a good start initially would be to define some standards which inform the development of the roles. Within OSA, for better or worse, we have a mix of role types - some are 'utility', built for include_role usage. An example is http://git.openstack.org/cgit/openstack/ansible-role-systemd_service - give it the right vars, and it lays down the type of system service unit that you asked for in a standard way. We also make use of the http://git.openstack.org/cgit/openstack/ansible-config_template action plugin *everywhere* because it allows us not to be bothers with variables for every tunable under the sun - we only need variables for specific things that glue services together, or implement 'sensible defaults'. We then have what I might call 'integration' roles - these are roles like http://git.openstack.org/cgit/openstack/openstack-ansible-os_nova which does all things nova, and uses include_role to bring in various utility roles. We try to follow the idea that a single role operates on a single host, and try to avoid orchestration across multiple hosts inside a role, but it's not always that simple for it to be cut and dried and I'm starting to think we might want to change that, for upgrades especially. Laying down something like keystone or nova, with all the options like federation or the nova drivers, is a complex thing to do. Putting it all in one role makes the role hard to understand, but at least it's obvious where you go to find it. I guess what I'm trying to get across is that trying to build commonly used roles is not going to be a simple process. All projects have very different styles, and very different ways of putting a service like nova down. However, we should start somewhere - break it down into a set of utility roles we'd like to see available, figure out the standards that matter for input/output and Ansible version support, figure out the release and branching strategy for them, get them done and move to using them and retire any previously implemented roles which duplicate their purpose, then target the next set. I think it would be beneficial to get in a room at the PTG and figure out where we start, and agree on some standards. I'd like to see a strong facilitator for the session who can ensure that we keep things on topic and productive. Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Security group logging
Hi team, Have a nice day. Since Security Group Logging was merged in Queens cycle, we've just found a critical bug which has been addressed in [1] and [2]. These patches is already in good shape now (got +2 from core reviewers). So, could you please help to review and bless these patches to be merged in Rocky stable branch? After that, we can backport to Queens stable branch. [1] https://review.openstack.org/#/c/587681/ [2] https://review.openstack.org/#/c/587770/ Thank you in advance, Best regards, An __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do
A couple of changes [1][2] that I proposed to kolla ansible recently as a PoC could be related here. Kolla ansible is full of almost identical roles for each service, with a lot of duplicated 'code' (YAML). The idea was to try to factor some of that out into shared roles. This results in less code and a more data-driven approach, which is inherently more configurable (for better or worse). The two changes are for configuration and user/service/endpoint registration. The same could easily be done with DB management and various other tasks. These roles are quite specific to kolla ansible, since they are tied to the configuration layout and the use of a kolla_toolbox container for executing keystone/DB ansible modules. [1] https://review.openstack.org/587591 [2] https://review.openstack.org/587590 Mark On 10 August 2018 at 10:59, Chandan kumar wrote: > Hello, > > On Fri, Aug 10, 2018 at 7:47 AM Paul Belanger > wrote: > > > > On Thu, Aug 09, 2018 at 08:00:13PM -0600, Wesley Hayutin wrote: > > > On Thu, Aug 9, 2018 at 5:33 PM Alex Schultz > wrote: > > > > > > > On Thu, Aug 9, 2018 at 2:56 PM, Doug Hellmann > > > > > wrote: > > > > > Excerpts from Alex Schultz's message of 2018-08-09 14:31:34 -0600: > > > > >> Ahoy folks, > > > > >> > > > > >> I think it's time we come up with some basic rules/patterns on > where > > > > >> code lands when it comes to OpenStack related Ansible roles and > as we > > > > >> convert/export things. There was a recent proposal to create an > > > > >> ansible-role-tempest[0] that would take what we use in > > > > >> tripleo-quickstart-extras[1] and separate it for re-usability by > > > > >> others. So it was asked if we could work with the > openstack-ansible > > > > >> team and leverage the existing openstack-ansible-os_tempest[2]. > It > > > > >> turns out we have a few more already existing roles laying around > as > > > > >> well[3][4]. > > > > >> > > > > >> What I would like to propose is that we as a community come > together > > > > >> to agree on specific patterns so that we can leverage the same > roles > > > > >> for some of the core configuration/deployment functionality while > > > > >> still allowing for specific project specific customization. What > I've > > > > >> noticed between all the project is that we have a few specific > core > > > > >> pieces of functionality that needs to be handled (or skipped as > it may > > > > >> be) for each service being deployed. > > > > >> > > > > >> 1) software installation > > > > >> 2) configuration management > > > > >> 3) service management > > > > >> 4) misc service actions > > > > >> > > > > >> Depending on which flavor of the deployment you're using, the > content > > > > >> of each of these may be different. Just about the only thing > that is > > > > >> shared between them all would be the configuration management > part. > > > > > > > > > > Does that make the 4 things separate roles, then? Isn't the role > > > > > usually the unit of sharing between playbooks? > > > > > > > > > > > > > It can be, but it doesn't have to be. The problem comes in with the > > > > granularity at which you are defining the concept of the overall > > > > action. If you want a role to encompass all that is "nova", you > could > > > > have a single nova role that you invoke 5 different times to do the > > > > different actions during the overall deployment. Or you could create > a > > > > role for nova-install, nova-config, nova-service, nova-cells, etc > etc. > > > > I think splitting them out into their own role is a bit too much in > > > > terms of management. In my particular openstack-ansible is already > > > > creating a role to manage "nova". So is there a way that I can > > > > leverage part of their process within mine without having to > duplicate > > > > it. You can pull in the task files themselves from a different so > > > > technically I think you could define a ansible-role-tripleo-nova that > > > > does some include_tasks: ../../os_nova/tasks/install.yaml but then > > > > we'd have to duplicate the variables in our playbook rather than > > > > invoking a role with some parameters. > > > > > > > > IMHO this structure is an issue with the general sharing concepts of > > > > roles/tasks within ansible. It's not really well defined and there's > > > > not really a concept of inheritance so I can't really extend your > > > > tasks with mine in more of a programming sense. I have to duplicate > it > > > > or do something like include a specific task file from another role. > > > > Since I can't really extend a role in the traditional OO programing > > > > sense, I would like to figure out how I can leverage only part of it. > > > > This can be done by establishing ansible variables to trigger > specific > > > > actions or just actually including the raw tasks themselves. Either > > > > of these concepts needs some sort of contract to be established to > the > > > > other won't get broken. We had this in puppet via
[openstack-dev] nova 18.0.0.0rc1 (rocky)
Hello everyone, A new release candidate for nova for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Rocky release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/rocky release branch at: http://git.openstack.org/cgit/openstack/nova/log/?h=stable/rocky Release notes for nova can be found at: http://docs.openstack.org/releasenotes/nova/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do
Hello,
On Fri, Aug 10, 2018 at 7:47 AM Paul Belanger wrote:
>
> On Thu, Aug 09, 2018 at 08:00:13PM -0600, Wesley Hayutin wrote:
> > On Thu, Aug 9, 2018 at 5:33 PM Alex Schultz wrote:
> >
> > > On Thu, Aug 9, 2018 at 2:56 PM, Doug Hellmann
> > > wrote:
> > > > Excerpts from Alex Schultz's message of 2018-08-09 14:31:34 -0600:
> > > >> Ahoy folks,
> > > >>
> > > >> I think it's time we come up with some basic rules/patterns on where
> > > >> code lands when it comes to OpenStack related Ansible roles and as we
> > > >> convert/export things. There was a recent proposal to create an
> > > >> ansible-role-tempest[0] that would take what we use in
> > > >> tripleo-quickstart-extras[1] and separate it for re-usability by
> > > >> others. So it was asked if we could work with the openstack-ansible
> > > >> team and leverage the existing openstack-ansible-os_tempest[2]. It
> > > >> turns out we have a few more already existing roles laying around as
> > > >> well[3][4].
> > > >>
> > > >> What I would like to propose is that we as a community come together
> > > >> to agree on specific patterns so that we can leverage the same roles
> > > >> for some of the core configuration/deployment functionality while
> > > >> still allowing for specific project specific customization. What I've
> > > >> noticed between all the project is that we have a few specific core
> > > >> pieces of functionality that needs to be handled (or skipped as it may
> > > >> be) for each service being deployed.
> > > >>
> > > >> 1) software installation
> > > >> 2) configuration management
> > > >> 3) service management
> > > >> 4) misc service actions
> > > >>
> > > >> Depending on which flavor of the deployment you're using, the content
> > > >> of each of these may be different. Just about the only thing that is
> > > >> shared between them all would be the configuration management part.
> > > >
> > > > Does that make the 4 things separate roles, then? Isn't the role
> > > > usually the unit of sharing between playbooks?
> > > >
> > >
> > > It can be, but it doesn't have to be. The problem comes in with the
> > > granularity at which you are defining the concept of the overall
> > > action. If you want a role to encompass all that is "nova", you could
> > > have a single nova role that you invoke 5 different times to do the
> > > different actions during the overall deployment. Or you could create a
> > > role for nova-install, nova-config, nova-service, nova-cells, etc etc.
> > > I think splitting them out into their own role is a bit too much in
> > > terms of management. In my particular openstack-ansible is already
> > > creating a role to manage "nova". So is there a way that I can
> > > leverage part of their process within mine without having to duplicate
> > > it. You can pull in the task files themselves from a different so
> > > technically I think you could define a ansible-role-tripleo-nova that
> > > does some include_tasks: ../../os_nova/tasks/install.yaml but then
> > > we'd have to duplicate the variables in our playbook rather than
> > > invoking a role with some parameters.
> > >
> > > IMHO this structure is an issue with the general sharing concepts of
> > > roles/tasks within ansible. It's not really well defined and there's
> > > not really a concept of inheritance so I can't really extend your
> > > tasks with mine in more of a programming sense. I have to duplicate it
> > > or do something like include a specific task file from another role.
> > > Since I can't really extend a role in the traditional OO programing
> > > sense, I would like to figure out how I can leverage only part of it.
> > > This can be done by establishing ansible variables to trigger specific
> > > actions or just actually including the raw tasks themselves. Either
> > > of these concepts needs some sort of contract to be established to the
> > > other won't get broken. We had this in puppet via parameters which
> > > are checked, there isn't really a similar concept in ansible so it
> > > seems that we need to agree on some community established rules.
> > >
> > > For tripleo, I would like to just invoke the os_nova role and pass in
> > > like install: false, service: false, config_dir:
> > > /my/special/location/, config_data: {...} and it spit out the configs.
> > > Then my roles would actually leverage these via containers/etc. Of
> > > course most of this goes away if we had a unified (not file based)
> > > configuration method across all services (openstack and non-openstack)
> > > but we don't. :D
> > >
> >
> > I like your idea here Alex.
> > So having a role for each of these steps is too much management I agree,
> > however
> > establishing a pattern of using tasks for each step may be a really good
> > way to cleanly handle this.
> >
> > Are you saying something like the following?
> >
> > openstack-nova-role/
> > * * /tasks/
> > * * /tasks/install.yml
> > * * /tasks/service.yml
> > * */tasks/config.yml
> > *
[openstack-dev] [monasca] Vacation
Hello everyone, I'll be on vacation until August 31st. My deputies in that time will be: * Doug Szumski (dougsz) and * Dobrosław Żybort (Dobroslaw) Thanks a lot Witek __ 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
