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 was
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 referen
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
dr
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 provi
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 API-
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 h
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
comm
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 will
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
will
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 on
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 do
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 f
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 already built in
>> memory du
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 Tantsur
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 throu
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 wil
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 arou
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 re
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
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 takeaways
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,
th
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 an
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
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
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 mor
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 i
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 which
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 t
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, and
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].
# Ne
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
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
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 wa
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
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 merg
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
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
* Dele
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
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 (
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 h
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
p
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
API,
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. version
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
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. T
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 ossp
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
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 a
On Fri, Mar 4, 2016 at 12:29 AM, Evgeny Sikachev mailto:esikac...@mirantis.com>> 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 for testing a new release o
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: openstack-dev-requ...@lists.openstack.
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 t
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
__
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 head
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
developer.openstack.org/draft/swagg
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 admini
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 agai
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 appeal
On 02/03/2016 10:23 AM, Morgan Fainberg wrote:
On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague mailto:s...@dague.net>> wrote:
I've been looking through the reviews on and where it's gotten to -
https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst
A coup
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 also
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-
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 names
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
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 to
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
expose
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 ha
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
_
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]: htt
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 that
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 this,
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 commi
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 fetc
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 in
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
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 documentation
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
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
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
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 d
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 lit
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 feedba
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 feedba
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.
http://5d100f09242e1d85fe65-9262bad2bd2ce9d8
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 mailto:m...@redhat.com>> wrote:
+1!
On 10/12/2015 07:19 AM, Sergey Lukjanov wrote:
Hi folks,
I'd like to pr
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 do
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
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 to
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 i
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
_
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 for
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 releva
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 behavior
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 che
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
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
mailto:sreshetn...@mirantis.com>> wrote:
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, so
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
__
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, Etha
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 like
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
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 - 100 of 168 matches
Mail list logo
