Re: [openstack-dev] [tripleo] Workflows Squad changes
On Wed, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote: > Hi all, > > Recently, the workflows squad has been reorganized and people from the > squad are joining different squads. I would like to discuss how we are > going to adjust to this situation to make sure that tripleo-common > development is not going to be blocked in terms of feature work and reviews. > > With this change, most of the tripleo-common maintenance work goes > naturally to UI & Validations squad as CLI and GUI are the consumers of the > API provided by tripleo-common. Adriano Petrich from workflows squad has > joined UI squad to take on this work. > > As a possible solution, I would like to propose Adriano as a core reviewer > to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common > patches. > > It would be great to hear opinions especially former members of Workflows > squad and regular contributors to tripleo-common on these changes and in > general on how to establish regular reviews and maintenance to ensure that > tripleo-common codebase is moved towards converging the CLI and GUI > deployment workflow. > Well, I'm not really going that far and plan to continue working in tripleo-common for the time being. If that isn't sustainable during the next cycle, I'll make sure to shout. > 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 -- RYAN BRADY SENIOR SOFTWARE ENGINEER Red Hat Inc <https://www.redhat.com/> rbr...@redhat.comT: (919)-890-8925 IM: rbrady <https://red.ht/sig> @redhatway <https://twitter.com/redhatway> @redhatinc <https://instagram.com/redhatinc> @redhatsnaps <https://snapchat.com/add/redhatsnaps> __ 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] [TripleO] milestone-proposed branches
+1 for releases. In the past I requested a tag for tripleo-incubator to make it easier to build a package and test. In my case a common tag would be easier to track than trying to gather all of the commit hashes where the projects are compatible. Ryan - Original Message - From: "James Slagle" To: "OpenStack Development Mailing List" Sent: Thursday, January 16, 2014 10:13:58 AM Subject: [openstack-dev] [TripleO] milestone-proposed branches At last summit, we talked about doing stable branches and releases for the TripleO projects for Icehouse. I'd like to propose doing a milestone-proposed branch[1] and tagged release for icehouse milestones 2 and 3. Sort of as dry run and practice, as I think it could help tease out some things we might not have considered when we do try to do icehouse stable branches. The icehouse milestone 2 date is January 23rd [2]. So, if there is concensus to do this, we probably need to get the branches created soon, and then do any bugfixes in the branches (master too of course) up unitl the 23rd. I think it'd be nice if we had a working devtest to use with the released tarballs. This raises a couple of points: - We probably need a way in devtest to let people use a different branch (or tarball) of the stuff that is git cloned. - What about tripleo-incubator itself? We've said in the past we don't want to attempt to stabilize or release that due to it's "incubator nature". But, if we don't have a stable set of devtest instructions (and accompanying scripts like setup-endpoints, etc), then using an ever changing devtest with the branches/tarballs is not likely to work for very long. And yes, I'm volunteering to do the work to support the above, and the release work :). Thoughts? [1] https://wiki.openstack.org/wiki/BranchModel [2] https://wiki.openstack.org/wiki/Icehouse_Release_Schedule -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] milestone-proposed branches
>- Original Message - >From: "Clint Byrum" >To: "openstack-dev" >Sent: Thursday, January 16, 2014 7:29:28 PM >Subject: Re: [openstack-dev] [TripleO] milestone-proposed branches >Note that tripleo-incubator is special and should not be released. It >is intentionally kept unfrozen and unreleased to make sure there is no >illusion of stability. Same answer I got last September. :) I understand your point, but used tripleo-incubator as an example. What I'd like to say is a tag would be cool to build a package and test of [insert official maintained project from Tripleo Wiki]. >If there are components in it that need releasing, they should be moved >into relevant projects or forked into their own projects. Excerpts from Ryan Brady's message of 2014-01-16 07:42:33 -0800: > +1 for releases. > > In the past I requested a tag for tripleo-incubator to make it easier to > build a package and test. > > In my case a common tag would be easier to track than trying to gather all of > the commit hashes where > the projects are compatible. > > Ryan > > - Original Message - > From: "James Slagle" > To: "OpenStack Development Mailing List" > Sent: Thursday, January 16, 2014 10:13:58 AM > Subject: [openstack-dev] [TripleO] milestone-proposed branches > > At last summit, we talked about doing stable branches and releases for > the TripleO projects for Icehouse. > > I'd like to propose doing a milestone-proposed branch[1] and tagged > release for icehouse milestones 2 and 3. Sort of as dry run and > practice, as I think it could help tease out some things we might not > have considered when we do try to do icehouse stable branches. > > The icehouse milestone 2 date is January 23rd [2]. So, if there is > concensus to do this, we probably need to get the branches created > soon, and then do any bugfixes in the branches (master too of course) > up unitl the 23rd. > > I think it'd be nice if we had a working devtest to use with the > released tarballs. This raises a couple of points: > - We probably need a way in devtest to let people use a different > branch (or tarball) of the stuff that is git cloned. > - What about tripleo-incubator itself? We've said in the past we don't > want to attempt to stabilize or release that due to it's "incubator > nature". But, if we don't have a stable set of devtest instructions > (and accompanying scripts like setup-endpoints, etc), then using an > ever changing devtest with the branches/tarballs is not likely to work > for very long. > > And yes, I'm volunteering to do the work to support the above, and the > release work :). > > Thoughts? > > [1] https://wiki.openstack.org/wiki/BranchModel > [2] https://wiki.openstack.org/wiki/Icehouse_Release_Schedule > > -- > -- James Slagle > -- > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Specifying file encoding
- Original Message - > From: "Pádraig Brady" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Wednesday, May 28, 2014 6:28:28 AM > Subject: Re: [openstack-dev] Specifying file encoding > > On 05/28/2014 08:16 AM, Martin Geisler wrote: > > Hi everybody, > > > > I'm trying to get my feet wet with OpenStack development, Welcome aboard! Thanks for contributing. :) >> so I recently > > tried to submit some small patches. One small thing I noticed was that > > some files used > > > > # -*- encoding: utf-8 -*- > > > > to specify the file encoding for both Python and Emacs. Unfortunately, > > Emacs expects you to set "coding", not "encoding". Python is fine with > > either. I submitted a set of patches for this: > > > > * https://review.openstack.org/95862 > > * https://review.openstack.org/95864 > > * https://review.openstack.org/95865 > > * https://review.openstack.org/95869 > > * https://review.openstack.org/95871 > > * https://review.openstack.org/95880 > > * https://review.openstack.org/95882 > > * https://review.openstack.org/95886 > > > > It was pointed out to me that such a change ought to be coordinated > > better via bug(s) or the mailinglist, so here I am :) > > This is valid change. > I don't see why there is any question > as it only improves the situation for emacs > which will pop up an error when trying to edit these files. I guess I approach this differently. When I saw this patch, my first thought was to validate if the line being changed needed to exist at all. If the file has valid non-ascii characters that effect its execution, are absolutely required for documentation to convey a specific meaning, or in strings that need to translate, then I agree the change is valid. But in the case the characters in the file can be changed, it seems like the bug is the extra encoding comment itself. Taking tuskar for example, the files in question seem to only need this encoding line to support the copyright symbol. [rb@localhost tuskar]$ grep -R -i -P "[^\x00-\x7F]" ./* Binary file ./doc/source/api/img/model_v2.jpg matches Binary file ./doc/source/api/img/model_v4.odg matches Binary file ./doc/source/api/img/model.odg matches Binary file ./doc/source/api/img/model_v3.jpg matches Binary file ./doc/source/api/img/model_v3.odg matches Binary file ./doc/source/api/img/model_v2.odg matches Binary file ./doc/source/api/img/model_v4.jpg matches Binary file ./doc/source/api/img/model_v1.jpg matches Binary file ./doc/source/_static/header_bg.jpg matches Binary file ./doc/source/_static/header-line.gif matches Binary file ./doc/source/_static/openstack_logo.png matches ./tuskar/api/hooks.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) ./tuskar/api/app.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) ./tuskar/api/acl.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) ./tuskar/common/service.py:# Copyright © 2012 eNovance ./tuskar/tests/api/api.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) In the U.S., copyright notices haven't really been needed since 1989. You also only need to include one instance of the symbol, "Copyright" or "copr" [1]. If the requirements for copyright are different outside the U.S., then I hope we capture that in the copyright wiki page [2]. Maybe the current info in that wiki needs to be updated or at least notated as to why the specific notice text is suggested. Unless there is another valid requirement to keep the © in the files, I think it's best if we just remove them altogether and eliminate the need to add the encoding comments at all. - Ryan > > You could create a bug I suppose > to reference all the changes though I don't > think that's mandatory since this isn't user facing. > > cheers, > Pádraig. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > [1] http://www.copyright.gov/circs/circ03.pdf [2] https://wiki.openstack.org/wiki/Documentation/Copyright ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Specifying file encoding
- Original Message - > From: "Martin Geisler" > To: openstack-dev@lists.openstack.org > Sent: Wednesday, May 28, 2014 11:35:02 AM > Subject: Re: [openstack-dev] Specifying file encoding > > Ryan Brady writes: > > > - Original Message - > >> From: "Pádraig Brady" > >> To: "OpenStack Development Mailing List (not for usage questions)" > >> > >> Sent: Wednesday, May 28, 2014 6:28:28 AM > >> Subject: Re: [openstack-dev] Specifying file encoding > >> > >> On 05/28/2014 08:16 AM, Martin Geisler wrote: > >> > Hi everybody, > >> > > >> > I'm trying to get my feet wet with OpenStack development, > > > > Welcome aboard! Thanks for contributing. :) > > > >>> so I recently > >> > tried to submit some small patches. One small thing I noticed was that > >> > some files used > >> > > >> > # -*- encoding: utf-8 -*- > >> > > >> > to specify the file encoding for both Python and Emacs. Unfortunately, > >> > Emacs expects you to set "coding", not "encoding". Python is fine with > >> > either. I submitted a set of patches for this: > >> > > >> > * https://review.openstack.org/95862 > >> > * https://review.openstack.org/95864 > >> > * https://review.openstack.org/95865 > >> > * https://review.openstack.org/95869 > >> > * https://review.openstack.org/95871 > >> > * https://review.openstack.org/95880 > >> > * https://review.openstack.org/95882 > >> > * https://review.openstack.org/95886 > >> > > >> > It was pointed out to me that such a change ought to be coordinated > >> > better via bug(s) or the mailinglist, so here I am :) > >> > >> This is valid change. > >> I don't see why there is any question > >> as it only improves the situation for emacs > >> which will pop up an error when trying to edit these files. > > > > I guess I approach this differently. When I saw this patch, my first > > thought was to validate if the line being changed needed to exist at > > all. > > That makes a lot of sense! > > > If the file has valid non-ascii characters that effect its execution, > > are absolutely required for documentation to convey a specific > > meaning, or in strings that need to translate, then I agree the change > > is valid. But in the case the characters in the file can be changed, > > it seems like the bug is the extra encoding comment itself. > > I see what you mean -- I also try to keep my files just ASCII for > convenience (even though I'm from Denmark where we have the extra three > vowels æ, ø, and å). As a brand new contributor, changing copyright > statements seemed like a bigger change than updating the coding line :) > It helps me to think about effort, value, complexity, future maintenance, and dependencies when evaluating changes. > > Taking tuskar for example, the files in question seem to only need > > this encoding line to support the copyright symbol. > > > > [rb@localhost tuskar]$ grep -R -i -P "[^\x00-\x7F]" ./* > > Binary file ./doc/source/api/img/model_v2.jpg matches > > Binary file ./doc/source/api/img/model_v4.odg matches > > Binary file ./doc/source/api/img/model.odg matches > > Binary file ./doc/source/api/img/model_v3.jpg matches > > Binary file ./doc/source/api/img/model_v3.odg matches > > Binary file ./doc/source/api/img/model_v2.odg matches > > Binary file ./doc/source/api/img/model_v4.jpg matches > > Binary file ./doc/source/api/img/model_v1.jpg matches > > Binary file ./doc/source/_static/header_bg.jpg matches > > Binary file ./doc/source/_static/header-line.gif matches > > Binary file ./doc/source/_static/openstack_logo.png matches > > ./tuskar/api/hooks.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) > > ./tuskar/api/app.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) > > ./tuskar/api/acl.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) > > ./tuskar/common/service.py:# Copyright © 2012 eNovance > > > > ./tuskar/tests/api/api.py:# Copyright © 2012 New Dream Network, LLC > > (DreamHost) > > > > > > In the U.S., copyright notices haven't really been needed since 1989. > > You also only need to include > > one instance of the symbol, "Copyright" or "copr" [1]. If the > > requirements for copyright are different > > outside the U.S., then I hope w
Re: [openstack-dev] [TripleO] Use MariaDB by default on Fedora
- Original Message - > From: "Gregory Haynes" > To: "openstack-dev" > Sent: Monday, June 16, 2014 5:49:25 PM > Subject: Re: [openstack-dev] [TripleO] Use MariaDB by default on Fedora > > > > Id also like to propose that if we decide against doing this then these > > > elements should not live in tripleo-image-elements. > > > > I'm not so sure I agree. We have lio and tgt because lio is on RHEL but > > everywhere else is still using tgt IIRC. > > Looks like we do have a cinder-tgt and a cinder-lio which we dont > actually use anywhere Isn't cinder-tgt used in devtest_overcloud? , so you are correct. The mariadb-galera / > percona-cluster elements are much more complex and active though, and > seem very likely to have issues with forgetting to or incorrectly > porting changes between them. It might also be a moot point if we end up > making it a default. :) > > > > > However, I also am not so sure that it is actually a good idea for people > > to ship on MariaDB since it is not in the gate. As it diverges from MySQL > > (starting in earnest with 10.x), there will undoubtedly be subtle issues > > that arise. So I'd say having MariaDB get tested along with Fedora will > > actually improve those users' test coverage, which is a good thing. > > > > -- > Gregory Haynes > g...@greghaynes.net > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh
- Original Message - > From: "Chris Jones" > To: openst...@nemebean.com, "OpenStack Development Mailing List (not for > usage questions)" > > Sent: Monday, April 14, 2014 2:24:57 PM > Subject: Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh > > Hi > > Apart from special cases like the ramdisk's /init, which is a script that > needs to run in busybox's shell, everything should be using bash. There's no > point us tying ourselves in knots trying to achieve POSIX compliance for the > sake of it, when bashisms are super useful. +1 for the pragmatic approach. > > Cheers, > > Chris > > > On 14 April 2014 17:26, Ben Nemec < openst...@nemebean.com > wrote: > > > tldr: I propose we use bash explicitly for all diskimage-builder scripts (at > least for the short-term - see details below). > > This is something that was raised on my linting changes to enable set -o > pipefail. That is a bash-ism, so it could break in the diskimage-builder > scripts that are run using /bin/sh. Two possible fixes for that: switch to > /bin/bash, or don't use -o pipefail > > But I think this raises a bigger question - does diskimage-builder require > bash? If so, I think we should just add a rule to enforce that /bin/bash is > the shell used for everything. I know we have a bunch of bash-isms in the > code already, so at least in the short-term I think this is probably the way > to go, so we can get the benefits of things like -o pipefail and lose the > ambiguity we have right now. For reference, a quick grep of the > diskimage-builder source shows we have 150 scripts using bash explicitly and > only 24 that are plain sh, so making the code truly shell-agnostic is likely > to be a significant amount of work. > > In the long run it might be nice to have cross-shell compatibility, but if > we're going to do that I think we need a couple of things: 1) Someone to do > the work (I don't have a particular need to run dib in not-bash, so I'm not > signing up for that :-) 2) Testing in other shells - obviously just changing > /bin/bash to /bin/sh doesn't mean we actually support anything but bash. We > really need to be gating on other shells if we're going to make a > significant effort to support them. It's not good to ask reviewers to try to > catch every bash-ism proposed in a change. This also relates to some of the > unit testing work that is going on right now too - if we had better unit > test coverage of the scripts we would be able to do this more easily. > > Thoughts? > > Thanks. > > -Ben > > __ _ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack. org > http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev > > > > -- > Cheers, > > Chris > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tripleo] Reviews wanted for new TripleO elements
- Original Message - > From: "Ben Nemec" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Monday, April 21, 2014 11:59:22 AM > Subject: Re: [openstack-dev] [Tripleo] Reviews wanted for new TripleO elements > > Please don't make review requests on the list. Details here: > http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html > I just updated the wiki about this under "Review team" section. Some folks may have missed the email, while those that are new to OpenStack probably wouldn't know what to look for or how far back in the mailing list archives to go. -r > Thanks. > > -Ben > > On 04/20/2014 02:44 PM, Macdonald-Wallace, Matthew wrote: > > Hi all, > > > > Can I please ask for some reviews on the following: > > > > https://review.openstack.org/#/c/87226/ - Install checkmk_agent > > https://review.openstack.org/#/c/87223/ - Install icinga cgi interface > > > > I already have a souple of +1s and jenkins is happy, all I need is +2 and > > +A! :) > > > > Thanks, > > > > Matt > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon - Mockup tool
+1 for balsamiq - Original Message - From: "Sergey Lukjanov" To: "OpenStack Development Mailing List" Sent: Friday, August 30, 2013 12:54:28 AM Subject: Re: [openstack-dev] Horizon - Mockup tool I'm using balsamiq to make mockups. Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. (sent from my phone) 30.08.2013 0:37 пользователь "Endre Karlson" < endre.karl...@gmail.com > написал: Does anyone know what too is used to do mockups ? Endre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] tripleo-common docs
On Tue, May 17, 2016 at 11:01 AM, Ben Nemec wrote: > On 05/17/2016 08:16 AM, Marius Cornea wrote: > > Hi everyone, > > > > The tripleo-common readme[1] points to a broken documentation link[2]. > > What is the correct link for the docs? > > At the moment it should probably point at > http://docs.openstack.org/developer/tripleo-docs/ > > Although it would be nice to have some real developer docs in > tripleo-common at some point too. We're adding a bunch of stuff to that > repo and it's going to get unwieldy if there's no API docs for people to > look at. > There's a start at https://review.openstack.org/#/c/313109/. > > > > > Thanks > > > > [1] https://github.com/openstack/tripleo-common/blob/master/README.rst > > [2] http://docs.openstack.org/developer/tripleo-common > > > > > __ > > 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 > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [mistal] Mistral logo ideas?
On Tue, Jun 28, 2016 at 1:38 AM, Jason Rist wrote: > On 06/27/2016 06:57 AM, Dougal Matthews wrote: > > On 27 June 2016 at 07:45, Renat Akhmerov > wrote: > > > > > > > >> Ideally it would be nice to have something that matches the meaning of > > > the > > >> name. Maybe we can combine wind with one of the other ideas. > > >> > > >> I like the idea of the logo being a stylized wind turbine. Perhaps it > > > could be > > >> a turbine with a gust of wind. Then we can show that Mistral harnesses > > > the > > >> power of the wind :-) > > > > > > Yeah, I’m just wondering how it would look like :) > > > > > > > > Yeah, for this idea we probably need somebody with artistic skills far > > superior > > to anything I could manage. We are getting quite a few good ideas now > > anyway! > > > > > > Renat Akhmerov > > > @Nokia > > > > > > > > > > Ever since I saw the blueprint for a mistral logo, I've been working on > some ideas. I've presented a few to Dougal and Ryan, but I'm sharing > widely here. I also did the one Michal came up with in Illustrator as > well. Please give me some feedback! Both of the ones I thought of are > "wind" related. I thought about doing the ship before as well, but perhaps > a little too war related, and also obscure. > +1 to the mistral-tornado.png logo. I think it would be easily distinguishable at any size or distance. > Thanks, > Jason > > P.S. you may recognize my name from the DLRN logo [1] and the TripleO Logo > [2]. > > [1] > https://github.com/openstack-packages/DLRN/blob/master/doc/source/_images/DLRN.png > [2] > https://github.com/dprince/tripleosphinx/blob/master/tripleosphinx/theme/tripleo/static/tripleo_owl.svg > > -- > Jason E. Rist > Senior Software Engineer > OpenStack User Interfaces > Red Hat, Inc. > openuc: +1.972.707.6408 > mobile: +1.720.256.3933 > Freenode: jrist > github/twitter: knowncitizen > > __ > 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 > > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] Results of the TC Election
On Fri, Apr 8, 2016 at 9:14 AM, Thierry Carrez wrote: > Eoghan Glynn wrote: > >> However, the turnout continues to slide, dipping below 20% for >>> the first time: >>> >> >>Election | Electorate (delta %) | Votes | Turnout (delta %) >>=== >>Oct '13 | 1106 | 342 | 30.92 >>Apr '14 | 1510 (+36.52) | 448 | 29.69 (-4.05) >>Oct '14 | 1893 (+25.35) | 506 | 26.73 (-9.91) >>Apr '15 | 2169 (+14.58) | 548 | 25.27 (-5.48) >>Oct '15 | 2759 (+27.20) | 619 | 22.44 (-11.20) >>Apr '16 | 3284 (+19.03) | 652 | 19.85 (-11.51) >> >> >>> This ongoing trend of a decreasing proportion of the electorate >>> participating in TC elections is a concern. >>> >> > One way to look at it is that every cycle (mostly due to the habit of > giving summit passes to recent contributors) we have more and more > one-patch contributors (more than 600 in Mitaka), and those usually are not > really interested in voting... So the electorate number is a bit inflated, > resulting in an apparent drop in turnout. > > It would be interesting to run the same analysis but taking only >=3 patch > contributors as "expected voters" and see if the turnout still drops as > much. > > Long term I'd like to remove the summit pass perk (or no longer link it to > "one commit"). It will likely result in a drop in contributors numbers > (gasp), but a saner electorate. Increase the commit requirements, but don't remove the summit pass perk. You'll add a barrier for ATCs and see fewer of them at summits. > > > -- > Thierry Carrez (ttx) > > > ______ > 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 > -- Ryan Brady rbr...@redhat.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
Re: [openstack-dev] [TripleO] Can we create some subteams?
On Mon, Apr 11, 2016 at 5:54 AM, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for the other > informal subteams (tripleoclient, UI), and also add a new subteam for > tripleo-quickstart (and maybe one for releases?). > > We should make seperate ACL's for these subteams as well. The informal > approach of adding cores who can +2 anything but are told to only +2 > what they know doesn't scale very well. > +1 to subteams for selected projects. I think there should be a clearly defined practice of ensuring there is enough reviewers so that a subteam core doesn't need to +A their own patches. I don't know if that's a standing rule in tripleo core, but I think it should be explicit in subteams. -r > - trown > > __ > 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] [tripleo] composable roles team
On Fri, Apr 29, 2016 at 4:27 PM, Emilien Macchi wrote: > Hi, > > One of the most urgent tasks we need to achieve in TripleO during > Newton cycle is the composable roles support. > So we decided to build a team that would focus on it during the next weeks. > > We started this etherpad: > https://etherpad.openstack.org/p/tripleo-composable-roles-work > > So anyone can help or check where we are. > We're pushing / going to push a lot of patches, we would appreciate > some reviews and feedback. > > Also, I would like to propose to -1 every patch that is not > composable-role-helpful, it will help us to move forward. Our team > will be available to help in the patches, so we can all converge > together. > -1 everything else is too heavy handed. > > Any feedback is welcome, thanks. > -- > Emilien Macchi > > __ > 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 > -- - Ryan Ryan Brady rbr...@redhat.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
Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?
ave into smaller, more independently operable >>> > parts. The split-stack approach already discussed on the TripleO >>> > meeting >>> > and on #tripleo could help with this. Essentially separating our >>> > hardware management from our software config management. Being able to >>> > re-apply software configuration without being afraid of having nodes >>> > accidentally re-provisioned from scratch. >>> > >>> > In general i think TripleO could be a little more "UNIXy" - composed of >>> > smaller parts that make sense on their own, transparent to the >>> > operator, >>> > more modular and modifiable, and in effect more receptive of how >>> > varying >>> > are the real world deployment environments (various Neutron and Cinder >>> > plugins, Keystone backends, composable set of services, custom node >>> > types etc.). >>> > >>> > Workflow persisted in a data-like fashion is probably more modifiable >>> > by >>> > the operator than Python code of a REST API. We've seen hard >>> > assumptions >>> > cause problems in the past. (Think the unoverridable CLI parameters >>> > issue we used to have, and how we had to move to a model of "CLI >>> > provides its values, but you can always override them or provide >>> > additional ones with an environment file if needed", which we now use >>> > extensively). I'm a bit concerned that building a new REST API on top >>> > of >>> > everything would impose new rigid assumptions that could cause more >>> > harm >>> > than good in the end. I'm concerned that it would be usable only for >>> > very basic deployments, while the world of real deployments has its own >>> > pace and requirements not fitting the "best practices" as defined by >>> > the >>> > API, having to bypass the API far too often and slowly pushing it into >>> > abandonment over time. >>> > >>> > My mind is probably biased towards the the operator feedback that >>> > resonated with me the most, i've heard pro-blackbox opinions too >>> > (though >>> > not from operators yet IIRC). So take what i wrote just as my 2 cents, >>> > but i think it's necessary to consider the above issues when thinking >>> > about the implications of building a TripleO API. >>> > >>> >>> Those are completely valid points, thanks for bringing them up! >>> >>> I think I should step back a bit and express my views from a different >>> perspective (which I probably should have done far earlier). I've been >>> working with a GUI application that deploys OpenStack using TripleO. The >>> deprecation of Tuskar was somewhat disruptive, but it was understood that >>> there are workarounds while we work towards a more permanent solution. >>> >>> What this application wants from TripleO is a set of APIs that provides >>> confidence that they can use TripleO without the risk of having to >>> fundamentally change their codebase if TripleO changes. TripleO needs >>> to guarantee support for its deployment practices and to have a formal >>> deprecation process if it moves to a different architecture. >>> >>> The proposed TripleO API spec differs from Tuskar in that (in my view) >>> it's far lower level. There are operations to get/set various types of >>> deployment parameters; there's an operation to deploy the result. None >>> of that precludes us from, say, eventually adding options to allow the >>> API to distinguish between hardware management and software config, or >>> to add an operation to apply the software config. >>> >>> Another reason this is important is it addresses your point below: >>> >>> > >>> > Regarding the non-workflow kind of features we need for empowering GUI, >>> > wouldn't those be useful for normal (tenant) Heat stack deployments in >>> > the overcloud too? It sounds to me that features like "driving a Heat >>> > stack deployment with the same powers from CLI or GUI", "updating a >>> > CLI-created stack from GUI and vice versa", "understanding/parsing what >>> > are the configuration options of my Heat templates" are all features >>> > that are not specific to TripleO, and could be useful for tenant Heat >>> > stacks too. So perhaps these should be implemented in Heat? If that >>> > can't happen fast enough, then we might need to put some workarounds in >>> > place for now, but it might be better if we didn't advertise those as a >>> > stable solution. >>> > >>> >>> I think TripleO benefits from controlling the access to these operations, >>> simply because it allows the underlying TripleO architecture change >>> without forcing integrators to change all their API calls. For example, >>> let's say we create a TripleO API that gets/sets parameters in the form >>> of a Heat environment file, and then deploys through Heat. If we want >>> to move to having the deployment driven through a Mistral workflow, we >>> can change the underlying code - write the parameters into a Mistral >>> environment file, drive the deployment through Mistral - without >>> affecting the outward facing API. >> >> >> I think this is a great point, and I think it has a ton of value from the >> point of >> view for an external consumer. For the TripleO CLI and TripleO API, >> Mistral >> would likely be fine as CI etc. would make sure they don't break each >> other. >> This guarantee wouldn't exist for external consumers, granted we would >> have the same potential issue with an API (regressions happen). However, >> I think trying to put an API infront of Mistral is an extra layer of >> abstraction >> that may not be needed. >> >> I would like to see us use Mistral directly and as those workflows mature, >> if it proves to be a difficult entry point for users we can create an API >> that >> creates a clearer and nicer interface to the world of TripleO. This might >> not >> create the ideal initial situation but if feels like the right way to go >> about >> this, incrementally adding an interface as needed rather adding an API >> just in-case. >> >> Let's get the Mistral interface correct and see where they leaves us. > > I think that's mostly fair; but I would ask that there be a spec comparable > to the TripleO > API spec that explains how a Mistral-only solution would provide the same > functionality - > things like editing the parameters for a Mistral environment file, for > example. I don't like > the idea of going in code-first, as I think that sometimes leads a > discussion to end at 'can > it be done' rather than 'should it be done'. > There's really not that much difference between what the API spec is calling for and what we'd do with Mistral. The methods in the spec that deal with the plan would turn into workflows that manage a mistral environment. The methods that deal with capabilities (deployment options) or parameters (deployment configuration) would be represented as workflows too. The workflows would be called via an execution in the Mistral API[1] directly from the UI. > Gah, I git sent a bit early. I said almost everything I wanted to add, but I > just > wanted to say that I believe we can offer a stable API via Mistral just in > the > way we can with a custom API. We just need to clearly define and document > each of these points of contact. Then CI in TripleO hould help us avoid any > regressions or unplanned changes. > > It could be argued that the Mistral interface would be more stable as it > already > exists and has been proven. We would be using this standard interface. > > Depending on what you mean by 'interface', I don't entirely agree with this. > It's true that > Mistral has an established API. But both the TripleO API and the Mistral > solution would > essentially provide the same 'interface' into TripleO; the same API calls > with the same > parameters (I think). That interface is no more or less stable one way or > the other. As > an added point, I think if TripleO does go the Mistral direction, it still > needs to provide > some guarantee of stability for the API interface. I agree that continuing to explore Mistral seems like the right thing to do for now and doesn't create any technical limitations against putting a TripleO API in front of it in the future. - Ryan [1] http://docs.openstack.org/developer/mistral/developer/webapi/v2.html#executions > > > Mainn > > >>> >>> >>> Mainn >>> >>> >>> > >>> > Jirka >>> > >>> > > >>> > > Mainn >>> > > >>> > > >>> > >> >>> > >> Dan >>> > >> >>> > >>> >>> > >>> Mainn >>> > >>> >>> > >>> >>> > >>>> >>> > >>>>> I think the correct attitude is to simply look at the problem >>> > >>>>> we're >>> > >>>>> trying to solve and find the correct architecture. For these >>> > >>>>> get/set >>> > >>>>> methods that the API needs, it's pretty simple: storage -> some >>> > >>>>> logic -> >>> > >>>>> a REST API. Adding a workflow engine on top of that is unneeded, >>> > >>>>> and I >>> > >>>>> believe that means it's an incorrect solution. >>> > >>>> >>> > >>>> What may help is if we can work through the proposed API spec, and >>> > >>>> identify which calls can reasonably be considered workflows vs >>> > >>>> those where >>> > >>>> it's really just proxying an API call with some logic? >>> > >>>> >>> > >>>> When we have a defined list of "not workflow" API requirements, >>> > >>>> it'll >>> > >>>> probably be much easier to rationalize over the value of a bespoke >>> > >>>> API vs >>> > >>>> mistral? >>> > >>>> >>> > >>>> >>> > >>>> Steve >>> > >>>> >>> > >>>> >>> > >>>> ___ >>> > >>>> ___ >>> > >>>> OpenStack Development Mailing List (not for usage questions) >>> > >>>> Unsubscribe: >>> > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsu >>> > >>>> bscribe >>> > >>>> 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:unsubs >>> > >>> cribe >>> > >>> 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 >>> > > >>> > >>> > >>> > >>> > __ >>> > 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 > > > > __ > 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 > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [TripleO] Should we have a TripleO API, or simply use Mistral?
attitude that leads to > > compromises and workarounds that will quickly lead to a shaky code base > > full of design flaws that make it difficult to implement or extend any > > functionality cleanly. > > > > I think the correct attitude is to simply look at the problem we're > > trying to solve and find the correct architecture. For these get/set > > methods that the API needs, it's pretty simple: storage -> some logic -> > > a REST API. Adding a workflow engine on top of that is unneeded, and I > > believe that means it's an incorrect solution. > > > > > > Thanks, > > Tzu-Mainn Chen > > > > > > > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2016-January/083757.html > > [2] > https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities_map.yaml > > > > > __ > > 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 > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [tripleo] Logo for TripleO
On Fri, Mar 11, 2016 at 12:32 AM, Jason Rist wrote: > Hey everyone - > We've been working on a UI for TripleO for a few months now and > we're > just about to beg to be a part of upstream... and we're in need of a > logo for the login page and header. > > In my evenings, I've come up with a logo. > > It's a take on the work that Dan has already done on the Owl idea: > http://wixagrid.com/tripleo/tripleo_svg.html > > I think it'd be cool if it were used on the CI page and maybe even > tripleo.org - I ran it by the guys on #tripleo and they seem to be > pretty warm on the idea, so I thought I'd run it by here if you missed > the conversation. > > It's SVG so we can change the colors pretty easily as I have in the two > attached screenshots. It also doesn't need to be loaded as a separate > asset. Additionally, it scales well since it's basically vector instead > of rasterized. > > What do you guys think? > +1. The logo looks great. > > Can we use it? > > I can do a patch for tripleo.org and the ci and wherever else it's in use. > > -J > > -- > Jason E. Rist > Senior Software Engineer > OpenStack Infrastructure Integration > Red Hat, Inc. > openuc: +1.972.707.6408 > mobile: +1.720.256.3933 > Freenode: jrist > github/twitter: knowncitizen > > __ > 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 > > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [mistral] Mistral Custom Actions API Design
At the PTG and previous discussions in IRC, I mentioned there were two different design ideas I had for the developer experience for custom action development in mistral-lib. The purpose and intent behind the patch[1] was discussed in person at the PTG and that was helpful for me wrt to scope. I feel it would be helpful to discuss and decide together the final piece of this patch. I'd like to get any feedback on either of these two ideas as they will shape how developers integrate with Mistral in the future, impact our OpenStack integration efforts in mistral-extra. Nothing stops a developer from adopting either style in their custom action libraries, but most will likely want to remain consistent with style present in the upstream code. I have created separate declaration and usage examples in hopes of illustrating some of the similarities and differences. To me it seems the base class example is more declarative/explicit, but the mixin example is more extensible and dry. Both examples reflect on backwards compatibility and possible changes to how mistral checks for sync/async actions and how to pass the context (as needed by actions that integrate with OpenStack). base classes declaration: https://gist.github.com/rbrady/ff86c484e8e6e53ba2dc3dfa17b01b09 base class usage: https://gist.github.com/rbrady/716a02fb2bd38d822c6df8bd642d3ea6 mixins declaration: https://gist.github.com/rbrady/d30ae640b19df658a17cd93827125678 mixins usage: https://gist.github.com/rbrady/248cb52d5c5f94854d8c76eee911ce8e Thanks, Ryan -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 [1] https://review.openstack.org/#/c/411412/ __ 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] [mistral] Mistral Custom Actions API Design
On Fri, Mar 10, 2017 at 5:16 AM, Renat Akhmerov wrote: > > On 10 Mar 2017, at 15:09, Dougal Matthews wrote: > > On 10 March 2017 at 04:22, Renat Akhmerov > wrote: > >> Hi, >> >> I probably like the base class approach better too. >> >> However, I’m trying to understand if we need this variety of classes. >> >>- Do we need a separate class for asynchronous actions? IMO, since >>is_sync() is just an instance method that can potentially return both True >>and False based on the instance state shouldn’t be introduced by a special >>class. Otherwise it’s confusing that a classes declared as AsyncAction can >>actually be synchronous (if its is_sync() returns True). So maybe we >> should >>just leave this method in the base class. >>- I”m also wondering if we should just always pass “context” into >>run() method. Those action implementations that don’t need it could just >>ignore it. Not sure though. >> >> This is a good point. I had originally thought it would be backwards > incompatible to make this change - however, users will need to update their > actions to inherit from mistral-lib so they will need to opt in. Then in > mistral we can do something like... > > if isinstance(action, mistral_lib.Action): > action.run(ctx) > else: > # deprecation warning about action now inheriting from mistral_lib and > taking a context etc. > action.run() > >> > Yes, right. > The example here by Dougal looks like the way to move forward. Thanks for all of the feedback. > > As far as mixin approach, I’d say I’d be ok with having mixing for >> context-based actions. Although, like Dougal said, it may be a little >> harder to read, this approach gives a huge flexibility for long term. >> Imagine if we want to have a class of actions that some different kind of >> information. Just making it up… For example, some of my actions need to be >> aware of some policies (Congress-like) or information about metrics of the >> current operating system (this is probably a bad example because it’s easy >> to use standard Python modules but I’m just trying to illustrate the idea). >> In this case we could have PolicyMixin and OperatingSystemMixin that would >> set required info into the instance state or provide with handle interfaces >> for more advanced uses. >> > > I like the idea of mixins if we can see a future with many small > components that can be included in an action class. However, like you I > didn't manage to think of any real examples. > > It should be possible to migrate to a mixin approach later if we have the > need. > > > Well, I didn’t manage to find real use cases probably because I don’t > develop lots of actions :) Although the example with policies seems almost > real to me. This is something that was raised several times during design > sessions in the past. Anyway, I agree with you that seems like we can add > mixins later if we want to. I don’t see any reasons now why not. > > One of the pain points for me as an action developer is the OpenStack actions[1]. Since they all use the same method name to retrieve the underlying client, you cannot simply inherit from more than one so you are forced to rewrite the client access methods. We saw this in creating actions for TripleO[2]. In the base action in TripleO, we have actions that make calls to more than one OpenStack client and so we end up re-writing and maintaining code. IMO the idea of using multiple inheritance there would be helpful. It may not require the mixin approach here, but rather a design change in the generator to ensure the method names don't match. [1] https://github.com/openstack/mistral/blob/master/mistral /actions/openstack/actions.py [2] https://github.com/openstack/tripleo-common/blob/master/ tripleo_common/actions/base.py#L27 > Renat Akhmerov > @Nokia > > > > __ > 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 > > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 <(919)%20890-8925> __ 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] [mistral] Project Update Slides
Here is a link to the slides used during the project update session from this morning. https://goo.gl/I3ufIi - Ryan -- RYAN BRADY SENIOR SOFTWARE ENGINEER Red Hat Inc <https://www.redhat.com/> rbr...@redhat.comT: (919)-890-8925 IM: rbrady <https://red.ht/sig> @redhatway <https://twitter.com/redhatway> @redhatinc <https://instagram.com/redhatinc> @redhatsnaps <https://snapchat.com/add/redhatsnaps> __ 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] [mistal] Mistral logo ideas?
On Mon, Jul 18, 2016 at 12:44 AM, Renat Akhmerov wrote: > On choosing a mascot for Mistral. Let’s choose one till next Monday. > > To start this discussion I’d like to propose a couple of ideas: > > >- *Octopus* (kind of symbolic to me). How do you like this beauty? >http://nashaplaneta.su/_bl/158/78285238.jpg > > +1. Intelligence, dexterity, tool-use - many good qualitites to associate with. >- *Dandelion*: > > http://cdn1.smartvectorpics.com/images/imagesbase/veezy/misc/Flower-Dandelion-Flower_31992.jpg > > > Please feel free to propose any crazy ideas, I think we will choose one > easily. Btw, if we as a team don’t like what Foundation creates for us we > won’t have to use it. But I like the idea of following the same style > across OpenStack projects. > > Renat Akhmerov > @Nokia > > On 14 Jul 2016, at 13:24, Renat Akhmerov wrote: > > Hi, > > Please take a look at this thread: > > http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html > > The idea is to choose a mascot from the natural world (animal, fish, > plant, mountain etc.) and let OpenStack kindly do illustration work for us. > > What do you think? > > Renat Akhmerov > @Nokia > > On 30 Jun 2016, at 12:03, Renat Akhmerov wrote: > > > On 30 Jun 2016, at 00:12, Jason Rist wrote: > I was thinking of a tornado with eyes or a tasmanian devil. Both are wind > related. Thoughts? > > > Jason, that would be cool to see :) Something like this IMO would be > awesome, but as always in such cases, a particular illustration matters the > most. > > > Renat Akhmerov > @Nokia > > > > > __ > 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 > > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [tripleo] [ironic] Exception registering nodes when Ironic API with apache
On Sun, Jul 31, 2016 at 7:01 PM, Emilien Macchi wrote: > Hi, > > On Friday we landed a patch in TripleO to deploy Ironic API in WSGI with > Apache. > Since then, our baremetal CI jobs were failing randomly, and a lot of > time, with an exception. > I decided to revert the patch to bring our CI back: > https://review.openstack.org/#/c/349281/ (+2 from slagle). > > Ironic experts, please have a look at the bug report: > https://bugs.launchpad.net/tripleo/+bug/1608252 I hit a similar issue earlier this year when we tried deploying mistral with apache. https://bugs.launchpad.net/mistral/+bug/1581649 > > > I'll propose to re-activate it so we can debug more of what it fails. > > Thanks, > -- > Emilien Macchi > > __ > 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 > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [mistral] Porting security-related utils, Context and dependencies to Mistral-Lib
In accordance with the spec[1], I started a patch[2] to port security related items from mistral to mistral-lib. This may not be the right way to approach this task and I'm hoping the patch provides a means to illustrate the problem and starts a discussion on the right solution. A custom action that creates a client that requires keystone auth will need to get an endpoint for a given project to create a client object, so I ported over the utility class[3] that deals with keystone. That utility class requires the mistral.context. I started looking at the context requirements from two separate points of view: - create a security context in mistral lib that could be an attribute in the mistral context - port entire mistral context over When I looked at the attributes[4] currently in the mistral.context, most if not all of them seem to be security related anyway. I chose to port the entire context over, but that also required dependencies on 4 threading utility methods[5] and mistral.exceptions[6], so those were also ported over. I would appreciate any feedback or discussion on the current proposed design. Thanks, Ryan [1] https://specs.openstack.org/openstack/mistral-specs/specs/newton/approved/mistral-custom-actions-api.html [2] https://review.openstack.org/#/c/352435/ [3] https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py [4] https://github.com/openstack/mistral/blob/master/mistral/context.py#L76-L87 [5] https://github.com/openstack/mistral/blob/master/mistral/utils/__init__.py#L49-L94 [6] https://github.com/openstack/mistral/blob/master/mistral/exceptions.py -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [TripleO] tripleo-common bugs, bug tracking and launchpad tags
On Wed, Jul 27, 2016 at 9:06 AM, Dougal Matthews wrote: > > > On 19 July 2016 at 16:20, Steven Hardy wrote: > >> On Mon, Jul 18, 2016 at 12:28:10PM +0100, Julie Pichon wrote: >> > Hi, >> > >> > On Friday Dougal mentioned on IRC that he hadn't realised there was a >> > separate project for tripleo-common bugs on Launchpad [1] and that he'd >> > been using the TripleO main tracker [2] instead. >> > >> > Since the TripleO tracker is also used for client bugs (as far as I can >> > tell?), and there doesn't seem to be a huge amount of tripleo-common >> > bugs perhaps it would make sense to also track those in the main >> > tracker? If there is a previous conversation or document about bug >> > triaging beyond [3] I apologise for missing it (and would love a >> > URL!). At the moment it's a bit confusing. >> >> Thanks for raising this, yes there is a bit of a proliferation of LP >> projects, but FWIW the only one I'm using to track coordinated milestone >> releases for Newton is this one: >> >> https://launchpad.net/tripleo/ >> >> > If we do encourage using the same bug tracker for multiple components, >> > I think it would be useful to curate a list of official tags [4]. The >> > main advantage of doing that is that the tags will auto-complete so >> > it'd be easier to keep them consistent (and thus actually useful). >> >> +1 I'm fine with adding tags, but I would prefer that we stopped adding >> more LP projects unless the associated repos aren't planned to be part of >> the coordinated release (e.g I don't have to track them ;) >> >> > Personally, I wanted to look through open bugs against >> > python-tripleoclient but people use different ways of marking them at >> > the moment - e.g. [tripleoclient] or [python-tripleoclient] or >> > tripleoclient (or nothing?) in the bug name. I tried my luck at adding >> > a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe >> > something shorter like 'cli', 'common' would make more sense. If there >> > are other tags that come back regularly it'd probably be helpful to >> > list them explicitly as well. >> >> Sure, well I know that many python-*clients do have separate LP projects, >> but in the case of TripleO our client is quite highly coupled to the the >> other TripleO pieces, in particular tripleo-common. So my vote is to >> create some tags in the main tripleo project and use that to filter bugs >> as >> needed. >> >> There are two projects we might consider removing, tripleo-common, which >> looks pretty much unused and tripleo-validations which was recently added >> by the sub-team working on validations. >> > > I agree with retiring these and I'd also like to add tripleo-workflows to > the > list for consideration, it has been created but hasn't yet been used as > far > as I can tell. > Shortly after I started creating this, you were very vocal about being -1 to this and so we did not use it. I haven't had time to delete it yet, but it's on my task list after the N-3 items. > > Sorry the the late reply. I'm glad this was brought up, it was on my mental > todo list. It should make things clearer internally and also for users > less > familiar with the project that want to report bugs. > > > If folks find either useful then they can stay, but it's going to be easier >> to get a clear view on when to cut a release if we track everything >> considered part of the tripleo deliverable in one place IMHO. >> >> Thanks, >> >> Steve >> >> > >> > Julie >> > >> > [1] https://bugs.launchpad.net/tripleo-common >> > [2] https://bugs.launchpad.net/tripleo >> > [3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage >> > [4] https://wiki.openstack.org/wiki/Bug_Tags >> > [5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient >> > >> > >> __ >> > 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 >> >> -- >> Steve Hardy >> Red Hat Engineering, Cloud >> >> >> __ >> OpenStack Development Mailing List (n
Re: [openstack-dev] [tripleo] Proposing Alex Schultz core on puppet-tripleo
On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi wrote: > Team, > > Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few > months now. While he's very active in different areas of TripleO, his > reviews and contributions on puppet-tripleo have been very useful. > Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I > think he perfectly understands how puppet-tripleo works. His > involvement in the project and contributions on puppet-tripleo deserve > that we allow him to +2 puppet-tripleo. > > Thanks Alex for your involvement and hard work in the project, this is > very appreciated! > > As usual, I'll let the team to vote about this proposal. > +1 > > Thanks, > -- > Emilien Macchi > > __ > 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 > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci
On Tue, Jan 24, 2017 at 12:03 PM, Juan Antonio Osorio wrote: > Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both > on the current CI solution and in getting tripleo-quickstart jobs for > it); So I would like to propose him as part of the TripleO CI core team. > > I think he'll make a great addition to the team and will help move CI > issues forward quicker. > > Best Regards, > > > > -- > Juan Antonio Osorio R. > jaosorior > > > __ > 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 > > +1 __ 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] [tripleo] Update TripleO core members
On Mon, Jan 23, 2017 at 2:03 PM, Emilien Macchi wrote: > Greeting folks, > > I would like to propose some changes in our core members: > > - Remove Jay Dobies who has not been active in TripleO for a while > (thanks Jay for your hard work!). > - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates > docker bits. > - Add Steve Backer on os-collect-config and also docker bits in > tripleo-common and tripleo-heat-templates. > > Indeed, both Flavio and Steve have been involved in deploying TripleO > in containers, their contributions are very valuable. I would like to > encourage them to keep doing more reviews in and out container bits. > > As usual, core members are welcome to vote on the changes. > > Thanks, > -- > Emilien Macchi > > __ > 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 > +1 __ 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] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores
On Tue, Jan 31, 2017 at 11:02 AM, Ben Nemec wrote: > In the spirit of all the core team changes, here are a couple more I'd > like to propose. > > Dmitry has been very helpful reviewing in instack-undercloud for a long > time so this is way overdue. I'm also going to propose that he be able to > +2 anything Ironic-related in TripleO since that is his primary area of > expertise. > > Alex has ramped up quickly on TripleO and has also been helping out with > instack-undercloud quite a bit. He's already core for the puppet modules, > and a lot of the changes to instack-undercloud these days are primarily in > the puppet manifest so it's not a huge stretch to add him. > > As usual, TripleO cores please vote and/or provide comments. Thanks. > > -Ben > > +1 __ 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] [TripleO] Your draft logo & a sneak peek
On Tue, Oct 25, 2016 at 5:55 AM, Steven Hardy wrote: > Hi team, > > I recently received a draft version of our project logo, using the mascot > we selected together. A final version (and some cool swag) will be ready > for us before the Project Team Gathering in February. Before they make our > logo final, they want to be sure we're happy with our mascot. > > We can discuss any concerns in Barcelona and you can also provide direct > feedback to the designers: http://tinyurl.com/OSmascot . Logo feedback is > due Friday, Nov. 11. I feel the logo draft is missing a lot of the detail and fidelity of our current logo. The draft logo has lines that are much too thick especially in the face area. It's recognizable from a shorter distance than our current logo. Our current logo has more of a cartoon / angry birds type feel to it - something with personality. To me, the draft logo is devoid of personality. I understand why the foundation wants to have more consistency between logos, but I'm hoping this isn't the final design approach. - Ryan > To get a sense of how ours stacks up to others, check out this sneak > preview of several dozen draft logos from our community: > https://youtu.be/JmMTCWyY8Y4. > > The only comment I have made is this logo does lose some of the OoO imagery > we had with the previous owl version - please feel free to provide feedback > of your own via the url above, thanks! > > Thanks! > > 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 > > __ 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] [TripleO] Your draft logo & a sneak peek
On Thu, Oct 27, 2016 at 12:48 PM, Sven Anderson wrote: > Hi all, > > On 25.10.2016 14:28, Ryan Brady wrote: > > I feel the logo draft is missing a lot of the detail and fidelity of our > > current logo. > > The draft logo has lines that are much too thick especially in the face > > area. It's > > recognizable from a shorter distance than our current logo. > > > > Our current logo has more of a cartoon / angry birds type feel to it - > > something > > with personality. To me, the draft logo is devoid of personality. I > > understand why > > the foundation wants to have more consistency between logos, but I'm > hoping > > this isn't the final design approach. > > to balance the feedback a bit: I like the new logo. I'm sure it could be > improved, but in general I think it qualifies as a logo, while the old > version does not really from my perspective. Logos _have_ to be sparse > in detail and still expressive. How is the current draft logo expressive? What does it express to you? - Ryan > That's what differentiates it from a > normal drawing. > > Cheers, > > Sven > > __ > 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 > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [tripleo] proposing Michele Baldessari part of core team
+1 On Fri, Nov 4, 2016 at 1:40 PM, Emilien Macchi wrote: > MIchele Baldessari (bandini on IRC) has consistently demonstrated high > levels of contributions in TripleO projects, specifically in High > Availability area where's he's for us a guru (I still don't understand > how pacemaker works, but hopefully he does). > > He has done incredible work on composable services and also on > improving our HA configuration by following reference architectures. > Always here during meetings, and on #tripleo to give support to our > team, he's a great team player and we are lucky to have him onboard. > I believe he would be a great core reviewer on HA-related work and we > expect his review stats to continue improving as his scope broadens > over time. > > As usual, feedback is welcome and please vote for this proposal! > > Thanks, > -- > Emilien Macchi > > __ > 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 > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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] [TripleO] Proposing Julie Pichon for tripleo core
On Tue, Nov 22, 2016 at 12:01 PM, Dougal Matthews wrote: > Hi all, > > I would like to propose we add Julie (jpich) to the TripleO core team for > python-tripleoclient and tripleo-common. This nomination is based partially > on review stats[1] and also my experience with her reviews and > contributions. > > Julie has consistently provided thoughtful and detailed reviews since the > start of the Newton cycle. She has made a number of contributions which > improve the CLI and has been extremely helpful with other tasks that don't > often get enough attention (backports, bug triaging/reporting and improving > our processes[2]). > > I think she will be a valuable addition to the review team > +1! > > Dougal > > > [1]: http://stackalytics.com/report/contribution/tripleo-group/90 > [2]: https://review.openstack.org/#/c/352852/ > > __ > 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 > > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925 __ 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
