Re: [openstack-dev] [ironic] Stepping down as core
Sorry to see you go Sam. You were a big asset to the community! Good luck for the future. John On Thu, Oct 11, 2018 at 4:41 AM Sam Betts (sambetts) wrote: > As many of you will have seen on IRC, I've mostly been appearing AFK for > the last couple of development cycles. Due to other tasks downstream most > of my attention has been drawn away from upstream Ironic development. Going > forward I'm unlikely to be as heavily involved with the Ironic project as I > have been in the past, so I am stepping down as a core contributor to make > way for those more involved and with more time to contribute. > > That said I do not intend to disappear, Myself and my colleagues plan to > continue to support the Cisco Ironic drivers, we just won't be so heavily > involved in core ironic development and its worth noting that although I > might appear AFK on IRC because my main focus is on other things, I always > have an ear to the ground and direct pings will generally reach me. > > I will be in Berlin for the OpenStack summit, so to those that are > attending I hope to see you there. > > The Ironic project has been (and I hope continues to be) an awesome place > to contribute too, thank you > > Sam Betts > sambetts > > > __ > OpenStack Development Mailing 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] [tc][all] meetings outside IRC
On 2018-10-13 23:29:46 +0200 (+0200), Mohammed Naser wrote: > I was going over our governance documents, more specifically this > section: > > "All project meetings are held in public IRC channels and > recorded." > > Does this mean that all official projects are *required* to hold > their project meetings over IRC? If an official project team holds a regular official team meeting, then it needs to be in a public IRC channel with published logs (either the channel log or a log specific to the meeting). > Is this a hard requirement or is this something that we're a bit > more 'lax about? [...] We've not generally required this of auxiliary meetings for official teams. Sub-team meetings and unofficial/ad-hoc team discussions over conference call or video chat media have been tolerated in the past. But for an official team meeting (if the team regularly holds one) we've stuck to the quoted expectation as a requirement as far as I'm aware. -- Jeremy Stanley 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] [tc][all] meetings outside IRC
On Sat, Oct 13, 2018 at 5:30 PM Mohammed Naser wrote: > Hi everyone: > > I was going over our governance documents, more specifically this section: > > "All project meetings are held in public IRC channels and recorded." > > Does this mean that all official projects are *required* to hold their > project meetings over IRC? Is this a hard requirement or is this > something that we're a bit more 'lax about? Do members of the > community feel like it would be easier to hold their meetings if we > allowed other avenues (assuming this isn't allowed?) > > Looking forward to hearing everyone's comments. > In my opinion, IRC is the best place to run meetings in OpenStack community, however we need to acknowledge that not everyone agrees and some functional teams or sub-teams prefer some other tools, including video-conference. What remains critical to me is: - wherever you run the meeting, make it publicly reachable, accessible, visible. - if you run the meeting outside of IRC, take and share notes on public channels. In general: decisions shouldn't not be taken during meetings, but rather on Gerrit or Mailing-lists. Otherwise you're fragmenting the community between those who can attend the meeting and those who can't. My 2 cents, -- 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
Re: [openstack-dev] [openstack-ansible] dropping xenial jobs
FYI: Thanks to Jesse, he has picked up this work and it's up here: https://review.openstack.org/#/c/609329/6 On Wed, Oct 10, 2018 at 9:56 AM Jesse Pretorius wrote: > > On 10/10/18, 5:54 AM, "Mohammed Naser" wrote: > > >So I’ve been thinking of dropping the Xenial jobs to reduce our overall > > impact in terms of gate usage in master because we don’t support it. > > I think we can start dropping it given our intended supported platform for > Stein is Bionic, not Xenial. We'll have to carry Xenial & Bionic for Rocky as > voting jobs. Anything ported back and found not to work for both can be fixed > through either another patch to master which is back ported, or a > re-implementation, as necessary. > > > > > 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 -- Mohammed Naser — vexxhost - D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.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] [tc][all] meetings outside IRC
Hi everyone: I was going over our governance documents, more specifically this section: "All project meetings are held in public IRC channels and recorded." Does this mean that all official projects are *required* to hold their project meetings over IRC? Is this a hard requirement or is this something that we're a bit more 'lax about? Do members of the community feel like it would be easier to hold their meetings if we allowed other avenues (assuming this isn't allowed?) Looking forward to hearing everyone's comments. Thanks Mohammed __ OpenStack Development Mailing 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] Discussing goals (upgrades) with community @ office hours
Hi everyone! It looks like we're not going to be able to have a TC meeting every 2 weeks as I had hoped for, the majority of the TC seems to want to meet once every month. However, I wanted to ask if the community would be interested in taking one of the upcoming office hours to discuss the current community goals, more specifically upgrades. It's been brought to my attention by some community members that they feel like we've been deciding goals too early without having enough maturity in terms of implementation. In addition, it seems like the final implementation way is not fully baked in by the time we create the goal. This was brought up in the WSGI goal last time and it looks like there is some oddities at the moment with "do we implement our own stuff?" "do we use the new oslo library?" "is the library even ready?" I wanted to propose one of the upcoming office hours to perhaps invite some of the community members (PTL, developers, anyone!) as well as the TC with goal champions to perhaps discuss some of these goals to help everyone get a clear view on what's going on. Does this seem like it would be of interest to the community? I am currently trying to transform our office hours to be more of a space where we have more of the community and less of discussion between us. Regards, Mohammed __ OpenStack Development Mailing 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-operators] [all] Consistent policy names
On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad wrote > Sending a follow up here quick. > The reviewers actively participating in [0] are nearing a conclusion. > Ultimately, the convention is going to be: > > :[:][:]:[:] > Details about what that actually means can be found in the review [0]. Each > piece is denoted as being required or optional, along with examples. I think > this gives us a pretty good starting place, and the syntax is flexible > enough to support almost every policy naming convention we've stumbled > across. > Now is the time if you have any final input or feedback. Thanks for sticking > with the discussion. Thanks Lance for working on this. Current version lgtm. I would like to see some operators feedback also if this standard policy name format is clear and easy understandable. -gmann > Lance > [0] https://review.openstack.org/#/c/606214/ > > On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad wrote: > > On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann > wrote: > On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad > wrote > > > > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki > wrote: > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg > > wrote: > > > > > > Ideally I would like to see it in the form of least specific to most > specific. But more importantly in a way that there is no additional > delimiters between the service type and the resource. Finally, I do not like > the change of plurality depending on action type. > > > > > > I propose we consider > > > > > > ::[:] > > > > > > Example for keystone (note, action names below are strictly examples > I am fine with whatever form those actions take): > > > identity:projects:create > > > identity:projects:delete > > > identity:projects:list > > > identity:projects:get > > > > > > It keeps things simple and consistent when you're looking through > overrides / defaults. > > > --Morgan > > +1 -- I think the ordering if `resource` comes before > > `action|subaction` will be more clean. > > > > ++ > > These are excellent points. I especially like being able to omit the > convention about plurality. Furthermore, I'd like to add that I think we > should make the resource singular (e.g., project instead or projects). For > example: > > compute:server:list > > > compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize > (or confirm-resize) > > Do we need "action" word there? I think action name itself should convey > the operation. IMO below notation without "äction" word looks clear enough. > what you say? > > compute:server:reboot > compute:server:confirm_resize > > I agree. I simplified this in the current version up for review. > -gmann > > > > > Otherwise, someone might mistake compute:servers:get, as "list". This is > ultra-nick-picky, but something I thought of when seeing the usage of > "get_all" in policy names in favor of "list." > > In summary, the new convention based on the most recent feedback should > be: > > ::[:] > > Rules:service-type is always defined in the service types authority > > resources are always singular > > Thanks to all for sticking through this tedious discussion. I appreciate > it. > > /R > > > > Harry > > > > > > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad > wrote: > > >> > > >> Bumping this thread again and proposing two conventions based on the > discussion here. I propose we decide on one of the two following conventions: > > >> > > >> :: > > >> > > >> or > > >> > > >> :_ > > >> > > >> Where is the corresponding service type of the > project [0], and is either create, get, list, update, or delete. I > think decoupling the method from the policy name should aid in consistency, > regardless of the underlying implementation. The HTTP method specifics can > still be relayed using oslo.policy's DocumentedRuleDefault object [1]. > > >> > > >> I think the plurality of the resource should default to what makes > sense for the operation being carried out (e.g., list:foobars, > create:foobar). > > >> > > >> I don't mind the first one because it's clear about what the > delimiter is and it doesn't look weird when projects have something like: > > >> > > >> ::: > > >> > > >> If folks are ok with this, I can start working on some documentation > that explains the motivation for this. Afterward, we can figure out how we > want to track this work. > > >> > > >> What color do you want the shed to be? > > >> > > >> [0] https://service-types.openstack.org/service-types.json > > >> [1] >
