[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, This week's meeting was mostly ceremonial, with the main topic of discussion being the office hours for the SIG. If you have not heard the news about the API-SIG, we are converting from a regular weekly meeting time to a set of scheduled office hours. This change

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, This week's meeting brings the return of the full SIG core-quartet as all core members were in attendance. The main topics were the agenda [7] for the upcoming Denver PTG [8], and the API-SIG still being listed as TC working group in the governance repository

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was primarily focused around two topics: the IETF[7] draft proposal for Best Practices when building HTTP protocols[8], and the upcoming OpenStack Project Teams Gathering (PTG)[9]. The group had taken a collective action to read the aforementioned

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was very brief as both cdent and dtantsur were out. There were no major items of discussion, but we did acknowledge the efforts of the GraphQL proof of concept work[7] being led by Gilles Dubreuil. This work continues to make progress and should

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting covered a few topics, but was mainly focused on a few updates to the errors guideline. We began with a review of last week's actions. Ed Leafe has sent an email[7] to mailing list to let the folks working on the GraphQL experiments know that the

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was on the shorter side but covered several topics. We discussed the migration to StoryBoard, and noted that we need to send word to Gilles and the GraphQL experimentors that the board is in place and ready for their usage. The GraphQL work was also

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was brief, covering only 1 major topic. The main topic for the SIG today was the migration of bug tracking from Launchpad to StoryBoard[7]. No firm plans were made to migrate yet, but the group agreed that this migration would be positive from a

[openstack-dev] [api] notes from api-sig forum meeting on graphql experiment

hi everybody, i have added my notes to the etherpad[1] from summit. briefly, we had a great meeting about creating a graphql experiment in openstack and i tried to capture some of the questions and comments that flew back and forth. there seems to be a good consensus that a proof of concept

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was brief, primarily focused on planning for the summit sessions[7][8] that the SIG will host and facilitate. The first session[7], will be a Birds of a Feather (BoF) gathering where the topics will be determined by the attendees. One topic that

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was quite short and saw a review of everyone's status and the merging of one guideline. We began by sharing our current work and plans for the near future. Although everyone is on tight schedules currently, we discussed the next steps for the work

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was quite lively with a good discussion about versions and microversions across OpenStack and their usage within the API schema world. We began with a review of outstanding work: elmiko is continuing to work on an update to the microversion history

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Another jovial meeting of the API-SIG was convened today. We began with a few housekeeping notes and then moved into a discussion of the api-ref work and how we might continue to assist Graham Hayes with the os-api-ref changes[7] that will output a machine-readable

Re: [openstack-dev] [Openstack-sigs] [all][api] POST /api-sig/news

On Fri, Mar 16, 2018 at 4:55 AM, Chris Dent wrote: > > >> So summarize and clarify, we are talking about SDK being able to build >> their interface to Openstack APIs in an automated way but statically from >> API Schema generated by every project. Such API Schema is

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was brief and primarily covered planning for the PTG. Here's a quick recap. We began by continuing to discuss the bug [8] that is the result of the Nova API not properly including caching information in the headers of its replies. Dmitry

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was primarily focused on a request for guidance related to action endpoints and on planning topics for the upcoming PTG. Tommy Hu has sent an email to the developer list[7] describing how several types of actions are currently being handled

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Happy new year to all and welcome to the first API-SIG meeting of 2018. As the SIG is ramping back up after the holiday break we had a few topics to kick off the new year and get the ball rolling. The SIG is working to complete our year in review report that

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was relatively short and covered a few topics surrounding OpenStack SDKs and expanding the meeting times. On the topic of OpenStack SDKs, there is a proposal [7] being crafted for an SDK certification program. Our discussions mainly centered

Re: [openstack-dev] [api] api-sig weekly meeting time change request

On 12/03/2017 10:26 PM, Gilles Dubreuil wrote: Hi, Could we please change the API SIG weekly meeting time from 16pm UTC to 19pm UTC  [1]? To give a chance for those down under to attend? hey Gilles, we have proposed adding another meeting time to make things easier for folks in the APAC

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was relatively short, with a few important topics taking the spotlight. cdent has posted a message[5] seeking feedback and discussion about a session for the SIG at the upcoming Sydney Forum. If you will be in Sydney, or have topics that should

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, This week's meeting was primarily focused on reviewing the discussions and plans that were proposed at the PTG. We also merged one new guideline which was frozen prior to the PTG. For a review of PTG activity, please see the etherpad[4] One of the big

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, This week's meeting was mainly focused on discussion of plans for the PTG and about improving the outreach efforts of the SIG. The API-SIG will have a room on Monday and Tuesday at the PTG. In addition to the guided review process [6] we've mentioned before,

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, This week's meeting centered around two main topics; the Guided Review Process[0] and the inclusion of guidance to discourage extension usage[4]. As the working group has now become a Special Interest Group, we have begun the work of changing the documentation

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, Today's meeting continued the discussion about the newly posted gerrit review for the Guided Review Process[0]. There is still some work to be done before the process is in shape to announce for the Denver PTG, but the group is confident about having the process

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, Today's meeting was slightly longer than last week's, with a few more in attendance as well. There were no new major issues brought up and the main topics were last week's frozen change[4] and a few minor fixes[5][6] in the queue now. These fixes were considered

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, Today was a relatively short meeting with most the time being devoted to a discussion of Monty Taylor's document chain regarding using the service catalog for version discovery[4]. The group was largely in agreement that work is proceeding well and with a few

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, This week's meeting was lightly attended but provided a useful discussion about the future of the working group and how we will continue to improve the API experience for all OpenStack users. The group is considering its role with respect to the guidelines that

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, This week's meeting[0] was relatively light, with some discussion about the recently released Ethercalc[4], and the first draft of the API compatiblity guideline[5] (many thanks to Chris Dent). The compatibility guideline lays out some concrete standards by

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, This week's meeting of the working group saw some conversation about activities related to API topics at the upcoming OpenStack summit. There will be a "birds of a feather" session for the working group on Wednesday from 12:15-12:55, please see our etherpad for

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, Today's meeting began with a quick review of the API usability tests that are being conducted at the Barcelona Summit[7]. We also had two lively discussions which took up most of the meeting: one about collecting and improving error messages across OpenStack,

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, There was no meeting of the working group this week as several of our members have scheduling conflicts. The meeting logs are in the usual place [5]. If you find an issue with an existing guideline [3] or think of one that needs to exist, make a bug [4]. #

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, This week the working group has been discussing an interesting topic raised by Michael Krotscheck on the devel mailing list[7]. This discussion is mainly about how we can create a more consistent API version discovery mechanism across the OpenStack projects, and

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, Today's open discussion centered around the concept of capabilities and the need to ensure that however we end up doing them in APIs there should be consistency amongst the existing OpenStack services. In fact, it would be great if there were consistency between

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, This week, the API-WG was visited by Deepti Ramakrishna from the Cinder project. Deepti brought up a spec currently being implemented by the Cinder team about resource capabilities, "New public core APIs to expose system capabilities"[5][6]. The result of this

[openstack-dev] [all] [api] POST /api-wg/news

Greetings OpenStack community, No new guidelines have been merged or proposed for freeze this week. There are 19 outstanding issues in the launchpad bug tracker for the working group[4], and we are always looking for more help from the community. A few hot issues currently are the need for an

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, No new guidelines have been merged or proposed for freeze this week, but we have cleaned up some of the language in the guideline pages and have had some productive discussions initiated by the Glance team about changes they are working towards. # Recently

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, This week there are no new merged guidelines nor guidelines proposed for freeze but there is a new guideline discussing ways to ensure that URIs are semantically consistent: https://review.openstack.org/#/c/322194/ # Recently merged guidelines These guidelines

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, Welcome to another edition of the API working group's weekly newsletter. # Recently merged guidelines These guidelines have been recently merged by the group. * Description of how to use etags to avoid lost updates https://review.openstack.org/#/c/301846 *

[openstack-dev] [all][api] New guidelines ready for cross project review

The following proposed API guidelines are available for broader review by interested parties. * https://review.openstack.org/#/c/301846 Description of how to use etags to avoid lost updates * https://review.openstack.org/#/c/281511 Delete multiple metadata items with a single request these

Re: [openstack-dev] [sahara] Nominating new members to Sahara Core

On 05/13/2016 11:33 AM, Vitaly Gridnev wrote: I'd like to bring the following folks to Sahara Core: 1. Lu Huichun +2 2. Nikita Konovalov +2 3. Chad Roberts +2 regards, mike __ OpenStack Development Mailing List

[openstack-dev] [api] API-WG summit session recap

hello all, We had a great session for the API working group in Austin, and I wanted to give a brief recap and extend a thank you to all who attended. There were about 20-30 people in attendance for the double session fishbowl that took place on monday. This turnout was one of the larger we

Re: [openstack-dev] [kolla][ssecurity] Threat Analysis Design Session

On 04/16/2016 02:19 PM, Steven Dake (stdake) wrote: If the security team has a conflict with this slot that I didn't see or am unaware of, please speak up so I can have it corrected in the main schedule. Our schedule is here: sadly, i will miss the beginning of this as i have a conflicting

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

please forgive my lack of direct knowledge about the neutron process and how this fits in. i'm just commenting from the perspective of someone looking at this from the api-wg. On 04/11/2016 09:52 AM, Duncan Thomas wrote: So by adding the handling of a header to change the behaviour of the

[openstack-dev] [all][api] Recently accepted API-WG guidelines

hello all, this is a friendly update about guidelines that the API working group has recently accepted: 1. version discover guideline for API microversions https://review.openstack.org/243429 2. client interaction guideline for API microversions https://review.openstack.org/243414 3.

Re: [openstack-dev] [sahara][release] missing build artifacts

On 04/05/2016 03:56 AM, Thierry Carrez wrote: We seem to have a sahara-extra build alright: http://tarballs.openstack.org/sahara-extra/ Please ignore the noise :) ah, excellent! thanks for the clarification Thierry regards, mike

Re: [openstack-dev] [sahara][release] missing build artifacts

On 04/01/2016 04:48 PM, Doug Hellmann wrote: Excerpts from Doug Hellmann's message of 2016-04-01 16:27:42 -0400: Sahara team, We noticed in our audit of the links on http://releases.openstack.org/mitaka/index.html that the links to the build artifacts for sahara-extras point to missing files.

[openstack-dev] [security] threat analysis, tags, and the road ahead

hey all, at the most recent ossp meeting[1], there was some extended discussion about threat analysis and the work that is being done to push this forward. in this discussion, there were several topics brought up around the process for doing these analyses on current projects and how the

Re: [openstack-dev] [sahara] PTL non-candidacy

i know you are not leaving the project Sergey, but i just wanted to say that it's been a true pleasure working with you as the PTL. regards, mike On 03/15/2016 07:33 PM, Sergey Lukjanov wrote: Hi folks, the PTL self-nomination period is opened and I want to note that I won’t be running again

Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained

On 03/08/2016 04:44 PM, Doug Hellmann wrote: it seems like the main reason there are so many projects leveraging WSME is because everyone is just using Ironic or Ceilometer as the starting point for their APIs. can we officially say to all new projects who plan on copying API logic of Ironic et

Re: [openstack-dev] [sahara][sahara-tests] Sahara-tests release and launchpad project

On Fri, Mar 4, 2016 at 12:29 AM, Evgeny Sikachev > wrote: Hi, sahara folks! I would like to propose release sahara-tests. All steps from spec implemented except releases and packaging.[0] Release criteria: framework ready

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 11:33 AM, Jay Pipes wrote: OpenStack:How <-- The developer planning event. :) very nice ;) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 11:06 AM, Dmitry Tantsur wrote: +1 here. I got an impression that midcycles now usually happen in the US. Indeed, it's probably much cheaper for the majority of contributors, but would make things worse for non-US folks. cost of travel has been a big reason we have never managed

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 10:14 AM, Thierry Carrez wrote: Hi everyone, TL;DR: Let's split the events, starting after Barcelona. as a developer, i'm +1 for this. thanks for all the hard work putting this together Thierry. mike __

Re: [openstack-dev] [api] header non proliferation (that naming thing, _again_)

On 02/22/2016 07:00 AM, Sean Dague wrote: On 02/21/2016 01:41 PM, Jay Pipes wrote: On 02/21/2016 12:50 PM, Chris Dent wrote: In a recent api-wg meeting I set forth the idea that it is both a bad idea to add lots of different headers and to add headers which have meaning in the name of the

Re: [openstack-dev] [docs] [api] Why WADL when you can Swagger

On 02/12/2016 04:45 PM, Anne Gentle wrote: What's new? This week, with every build of the api-site, we are now running fairy-slipper to migrate from WADL to Swagger for API reference information. Those migrated Swagger files are then copied to

Re: [openstack-dev] [all] RFC - service naming registry under API-WG

On 02/10/2016 03:03 PM, Sean Dague wrote: On 02/04/2016 06:38 AM, Sean Dague wrote: 2) Have a registry of "common" names. Upside, we can safely use common names everywhere and not fear collision down the road. Downside, yet another contention point. A registry would clearly be under TC

Re: [openstack-dev] [keystone] Usage of trusts with v2.0 authentication

On 02/09/2016 12:06 PM, Lance Bragstad wrote: The keystone team is curious if there is anyone creating trusts using v3 and then using them against version 2.0. If not, we'd like to remove/deprecate support for that case in v2.0. If so, then we'll have to add official documentation for trusts

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 04:36 PM, Chris Dent wrote: On Fri, 5 Feb 2016, Sean Dague wrote: I'd ask for folks to try to stay on the original question: What possible naming standards could we adopt, and what are the preferences. 1. service type as described in option 2 2. managed by the api-wg with

Re: [openstack-dev] [api] microversion spec

On 02/03/2016 10:23 AM, Morgan Fainberg wrote: On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague > wrote: I've been looking through the reviews on and where it's gotten to -

Re: [openstack-dev] [all] the trouble with names

On 02/04/2016 12:57 PM, Hayes, Graham wrote: On 04/02/2016 15:40, Ryan Brown wrote: On 02/04/2016 09:32 AM, michael mccune wrote: On 02/04/2016 08:33 AM, Thierry Carrez wrote: Hayes, Graham wrote: On 04/02/2016 13:24, Doug Hellmann wrote: Excerpts from Hayes, Graham's message of 2016-02-04

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 07:56 AM, Chris Dent wrote: On Thu, 4 Feb 2016, Sean Dague wrote: 2) Have a registry of "common" names. Upside, we can safely use common names everywhere and not fear collision down the road. This is the only option presented thus far which meets the needs of end users and

Re: [openstack-dev] [all] the trouble with names

On 02/04/2016 08:33 AM, Thierry Carrez wrote: Hayes, Graham wrote: On 04/02/2016 13:24, Doug Hellmann wrote: Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +: On 04/02/2016 11:40, Sean Dague wrote: 2) Have a registry of "common" names. Upside, we can safely use common

[openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

hi all, The following API guideline is ready for cross project review. It will be merged on Feb. 9 if there is no further feedback. 1. Must not return server-side tracebacks https://review.openstack.org/#/c/183599 regards, mike

Re: [openstack-dev] [api] service type vs. project name for use in headers

On 01/28/2016 06:32 AM, Jay Pipes wrote: Couldn't agree more, Chris. -jay On 01/28/2016 11:06 AM, Chris Dent wrote: On Wed, 27 Jan 2016, Dean Troyer wrote: I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them

[openstack-dev] [api] service type vs. project name for use in headers

hi all, there have been a few reviews recently where the issue of service type versus project name have come up for use in the headers. as usual this conversation can get quite murky as there are several good examples where service type alone is not sufficient (for example if a service

Re: [openstack-dev] [api] api working group proposed actions guideline needs input

On 01/18/2016 10:05 AM, Michael Krotscheck wrote: Also: I like using the same word for things. Is there a meaningful enough difference between "Actions", "Transitions", and "Tasks", that requires different words? not that i have detected, although i would love hear other opinions on this. i

[openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

hi all, The following API guideline is ready for cross project review. It will be merged on Jan. 21 if there is no further feedback. 1. Add description of pagination parameters https://review.openstack.org/#/c/190743 regards, mike

Re: [openstack-dev] [api][all] api variation release by release

On 01/12/2016 09:55 PM, Matt Riedemann wrote: Nova and Ironic already support microversioned APIs. Cinder and Neutron are working on it I think, and there could be others. just as a heads up, sahara is also working towards implementing microversions in its next api[1] regards, mike [1]:

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On 01/12/2016 08:51 AM, Amrith Kumar wrote: My question to the ML is this, should stylistic changes of this kind be handled in a consistent way across all projects, maybe with a hacking rule and some discussion on the ML first? After all, if this change is worthwhile, it is worth ensuring

Re: [openstack-dev] [trove] [sahara] Adding support for HBase in Trove

On 01/08/2016 08:34 AM, Amrith Kumar wrote: As Kevin suggests, I'm adding [sahara] to the subject line. Others in sahara who now see this thread, apologies for sending you a delayed invitation to the party. There's still lots of food and beer so come on in! Amrith, thanks for reposting

Re: [openstack-dev] [doc] [api] Vision and changes for OpenStack API Guides

On 01/08/2016 04:39 PM, Anne Gentle wrote: Join me next week at the first pop-up Cross Project meeting, Tuesday at 1700, in #openstack-meeting-cp. Feel free to add to the agenda at i'll definitely be there Anne, i'm very curious about this topic but sadly have not had the extra cycles to

Re: [openstack-dev] [all] making project_id optional in API URLs

On 12/08/2015 05:59 PM, Adam Young wrote: I think it is kindof irrelevant. It can be there or not be there in the URL itself, so long as it does not show up in the service catalog. From an policy standpoint, having the project in the URL means that you can do an access control check without

Re: [openstack-dev] [all] making project_id optional in API URLs

On 12/03/2015 12:06 PM, Sean Dague wrote: So, for Cinder, Glance, Ironic, Manila, Magnum (and others I might have missed) where are you standing on this one? And are there volunteers in those projects to help move this forward? i'm +1 for removing the project_id from the url. sahara uses it

Re: [openstack-dev] [cross-project] Cross-project Liaisons

On 11/30/2015 08:30 PM, Mike Perez wrote: Hello all, Currently for cross-project specs, the author of the spec spends the time to explain why a certain feature makes sense to be across multiple projects. This also includes giving technical solutions for it working with a variety of services and

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

On 11/30/2015 08:45 AM, Sean Dague wrote: Ok, I'm going to assume with no real disagreement we're agreed here. I'm moving the api-wg notifications to #openstack-sdks now - https://review.openstack.org/#/c/251357/1/gerritbot/channels.yaml,cm ok, i think we've got a few spots in the

[openstack-dev] [api] link definitions guideline to help align differing styles

hello all, there has recently been some activity in the guidelines surrounding the use of links embedded in response objects. it appears that with the recently merged error guideline[1] and the currently frozen pagination guideline[2], that we are on the precipice of introducing a bifurcation

[openstack-dev] [security][sahara] creating a threat analysis to aid operators

hello all, during the security midcycle meetup we had a session about creating threat analysis for openstack projects. the folks at HPE were kind enough to offer their documentation and examples as an aid to creating these analysis. after talking with the sahara team, i am confident that we

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

On 11/16/2015 09:42 AM, Sean Dague wrote: On 11/16/2015 09:34 AM, michael mccune wrote: On 11/13/2015 07:58 AM, Sean Dague wrote: The #openstack-api IRC channel is quite quiet most days. As such it's not something that people are regularly checking in on, or often forget about (I know I've

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

On 11/13/2015 07:58 AM, Sean Dague wrote: The #openstack-api IRC channel is quite quiet most days. As such it's not something that people are regularly checking in on, or often forget about (I know I've been guilty of that). Plus we don't always have the right people in a conversation to make a

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

On 11/03/2015 05:20 PM, Boris Pavlovic wrote: What if we add new API method that will just resturn resource status by UUID? Or even just extend get request with the new argument that returns only status? Thoughts? not sure i understand the resource status by UUID, could you explain that a

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

On 10/21/2015 05:11 PM, Michael Xin wrote: Rob and Michael: Thanks for the update. We will probably not use any Openstack Logo. Here is the first draft of the flyer: http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf Please send us your

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

On 10/21/2015 03:54 AM, Michael Xin wrote: Hi, guys: Thanks for your help. We are designing a logo and a flyer for Openstack Security Project. Rachel helped us with the task. Attached is her first version of the logo. Please let us know your feedback.

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

On 10/21/2015 05:11 PM, Michael Xin wrote: Rob and Michael: Thanks for the update. We will probably not use any Openstack Logo. Here is the first draft of the flyer: http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf Please send us your

Re: [openstack-dev] [sahara] Proposing Vitaly Gridnev to core reviewer team

congrats Vitaly! On 10/15/2015 10:38 AM, Sergey Lukjanov wrote: I think we have a quorum. Vitaly, congrats! On Tue, Oct 13, 2015 at 6:39 PM, Matthew Farrellee > wrote: +1! On 10/12/2015 07:19 AM, Sergey Lukjanov wrote: Hi folks,

Re: [openstack-dev] [sahara] Proposing Vitaly Gridnev to core reviewer team

i'm +1 for this, Vitaly has been doing a great job contributing code and reviews to the project. mike On 10/12/2015 07:19 AM, Sergey Lukjanov wrote: Hi folks, I'd like to propose Vitaly Gridnev as a member of the Sahara core reviewer team. Vitaly contributing to Sahara for a long time and

Re: [openstack-dev] [Security] Weekly Meeting Agenda

On 09/23/2015 02:56 PM, Clark, Robert Graham wrote: Hi All, I won’t be available to run the weekly meeting tomorrow as I’m out travelling, Michael McCune (elmiko) has volunteered to lead the meeting. There’s IRC information on our wiki page : https://wiki.openstack.org/wiki/Security Agenda

Re: [openstack-dev] [Sahara] FFE request for improved secret storage

i am retracting this request, i think this feature would benefit from more time to test and review. thanks for the consideration, mike On 09/09/2015 12:09 PM, michael mccune wrote: hi all, i am requesting an FFE for the improved secret storage feature. this change will allow operators

[openstack-dev] [sahara] hadoop-openstack.jar and proxy users

hey all, in doing some work recently with proxy users and hadoop deployments, i am noticing that the modified version of the hadoop-openstack.jar we package from the sahara-extras repo is not being used in our current images. this jar file adds support for keystone v3 to the swift interface

[openstack-dev] [sahara] mitaka summit session ideas

hey all, i started an etherpad for us to collect ideas about our session for the mitaka summit. https://etherpad.openstack.org/p/mitaka-sahara-session-plans please drop any thoughts or suggestions about the summit there. thanks, mike

Re: [openstack-dev] [Barbican] Nominating Dave Mccowan for Barbican core

i'm not a core, but +1 from me. Dave has made solid contributions and would be a great addition to the core team. mike On 09/08/2015 12:05 PM, Juan Antonio Osorio wrote: I'd like to nominate Dave Mccowan for the Barbican core review team. He has been an active contributor both in doing

[openstack-dev] [Sahara] FFE request for improved secret storage

hi all, i am requesting an FFE for the improved secret storage feature. this change will allow operators to utilize the key manager service for offloading the passwords stored by sahara. this change does not implement mandatory usage of barbican, and defaults to a backward compatible

Re: [openstack-dev] [sahara] FFE request for nfs-as-a-data-source

i'm +1 for this feature as long as we talking about just the sahara controller and saharaclient. i agree we probably cannot get the horizon changes in before the final release. mike On 09/09/2015 03:33 AM, Chen, Weiting wrote: Hi, all. I would like to request FFE for nfs as a data source

Re: [openstack-dev] Getting Started : OpenStack

On 09/08/2015 02:05 PM, Bhagyashree Uday wrote: Hi Victoria , Thanks for the prompt reply. I go by Bee(IRC nick : bee2502) .There doesn't seem to be much information regarding this project even on the Ceilometer project page :( I will wait till the next Outreachy applications begin though to

Re: [openstack-dev] [Openstack] [Horizon] [Sahara] FFE request for Sahara unified job interface map UI

On 09/04/2015 10:40 AM, Ethan Gafford wrote: Hello all, I request a FFE for the change at: https://review.openstack.org/#/c/209683/ This change enables a significant improvement to UX in Sahara's elastic data processing flow which is already in the server and client layers of Sahara. Because

Re: [openstack-dev] [sahara] FFE request for heat wait condition support

makes sense to me, +1 mike On 09/04/2015 06:37 AM, Vitaly Gridnev wrote: +1 for FFE, because of 1. Low risk of issues, fully covered with current scenario tests; 2. Implementation already on review On Fri, Sep 4, 2015 at 12:54 PM, Sergey Reshetnyak

Re: [openstack-dev] [sahara] Request for Feature Freeze Exception

On 09/03/2015 02:49 PM, Vitaly Gridnev wrote: Hey folks! I would like to propose to add to list of FFE's following blueprint: https://blueprints.launchpad.net/sahara/+spec/drop-hadoop-1 Reasoning of that is following: 1. HDP 1.3.2 and Vanilla 1.2.1 are not gated for a whole release cycle,

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 10:36 AM, Lucas Alvares Gomes wrote: So at the present moment the [micro]framework that comes to my mind - without any testing or prototype of any sort - is Flask. just wanted to add on here, sahara is using flask. mike

Re: [openstack-dev] [sahara] Bug triage/fix and doc update days in Liberty

hey Saharans, with Doc fix day fast approaching i wanted to send out an email with the etherpad again, https://etherpad.openstack.org/p/sahara-liberty-doc-update-day it has been updated with all the docs and we are ready to roll starting on monday aug 31. mike On 08/24/2015 09:41 AM,

Re: [openstack-dev] [api] [docs] Generating API samples

On 08/24/2015 11:51 AM, Anne Gentle wrote: Hi all, I'm writing to find out how teams keep API sample requests and responses up-to-date. I know the nova team has a sample generator [1] that they've maintained for a few years now. Do other teams have something similar? If so, is your approach

Re: [openstack-dev] [all][api] New API Guidelines ready for cross project review

On 08/11/2015 10:28 AM, michael mccune wrote: 1. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 2. Add advice on when to use POST or PUT in create https://review.openstack.org/#/c/181912/ 3. Clarify the return code when server have hard-code length limit https

Re: [openstack-dev] [all][api] New API Guidelines ready for cross project review

On 08/11/2015 10:28 AM, michael mccune wrote: 1. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 2. Add advice on when to use POST or PUT in create https://review.openstack.org/#/c/181912/ 3. Clarify the return code when server have hard-code length limit https

  1   2   >