Hi all,
To be clear, both Pecan and Falcon are actively maintained and have
healthy communities. In any case, I tend to point OpenStack projects
toward Pecan as the default choice, since that lets you take advantage of
all the benefits standardization has to offer. Of course, you need to
Hi everyone,
In the past we’ve discussed how Zaqar could be leveraged by Horizon to get
status notifications and such without having to poll backend APIs. In this
way, the user experience could be improved while also removing some load
from those APIs.
During Kilo the team is finally going to
Great question. So, some use cases, like guest agent, would like to see
something around ~20ms if the agent is needing to respond to requests from a
control surface/panel while a user clicks around. I spoke with a social media
company who was also interested in low latency just because they
Right, graphing those sorts of variables has always been part of our test plan.
What I’ve done so far was just some pilot tests, and I realize now that I
wasn’t very clear on that point. I wanted to get a rough idea of where the
Redis driver sat in case there were any obvious bug fixes that
Hi crew, as promised I’ve continued to work through the performance test
plan. I’ve started a wiki page for the next batch of tests and results:
https://wiki.openstack.org/wiki/Zaqar/Performance/PubSub/Redis
I am currently running the same tests again with 2x web heads, and will
update the wiki
(keepalive_timeout 65;”).
FWIW, I started an etherpad to track a shortlist of ideas:
https://etherpad.openstack.org/p/zaqar-performance-testing
On 9/16/14, 11:58 AM, Jay Pipes jaypi...@gmail.com wrote:
On 09/16/2014 11:23 AM, Kurt Griffiths wrote:
Hi crew, as promised I’ve continued to work through
for their
careful coding and reviews!
On 9/16/14, 2:43 PM, Kurt Griffiths kurt.griffi...@rackspace.com wrote:
Results are now posted for all workloads for 2x web heads and 1x Redis
proc (Configuration 2). Stats are also available for the write-heavy
workload with 2x webheads and 2x redis procs
On 9/11/14, 2:11 PM, Devananda van der Veen devananda@gmail.com
wrote:
OK - those resource usages sound better. At least you generated enough
load to saturate the uWSGI process CPU, which is a good point to look
at performance of the system.
At that peak, what was the:
- average msgs/sec
-
Thanks! Looks good. Only thing I noticed was that footnotes were still
referenced, but did not appear at the bottom of the page.
On 9/10/14, 6:16 AM, Flavio Percoco fla...@redhat.com wrote:
I've collected the information from both performance tests and put it in
the project's wiki[0] Please,
On 9/10/14, 3:58 PM, Devananda van der Veen devananda@gmail.com
wrote:
I'm going to assume that, for these benchmarks, you configured all the
services optimally.
Sorry for any confusion; I am not trying to hide anything about the setup.
I thought I was pretty transparent about the way uWSGI,
Hi folks,
In this second round of performance testing, I benchmarked the new Redis
driver. I used the same setup and tests as in Round 1 to make it easier to
compare the two drivers. I did not test Redis in master-slave mode, but
that likely would not make a significant difference in the results
Sounds OK to me, assuming we can get this done in the next week so the
team still has time for comprehensive testing (and we commit thereto)
before the RC.
On 9/4/14, 1:39 PM, Flavio Percoco fla...@redhat.com wrote:
On 09/04/2014 06:01 PM, Victoria Martínez de la Cruz wrote:
Hi all,
I would
Thanks for your comments Gordon. I appreciate where you are coming from
and I think we are actually in agreement on a lot of things.
I just want to make it clear that from the very beginning of the project
the team has tried to communicate (but perhaps could have done a better
job at it) that we
Thanks everyone for your feedback. I think we have a consensus that this
sort of change would be best left to v2 of the API. We can start planning
v2 of the API at the Paris summit, and target some kind of “community
preview” of it to be released as part of Kilo.
On 8/29/14, 11:02 AM, Everett
Sure thing, I’ll add that to my list of things to try in “Round 2” (coming
later this week).
On 8/28/14, 9:05 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/26/2014 05:41 PM, Kurt Griffiths wrote:
* uWSGI + gevent
* config: http://paste.openstack.org/show/100592
Thanks Flavio, I added a few thoughts.
On 8/28/14, 3:27 AM, Flavio Percoco fla...@redhat.com wrote:
Greetings,
I'd like to join the early coordination effort for design sessions. I've
shamelessly copied Doug's template for Oslo into a new etherpad so we
can start proposing sessions there.
Crew, as we continue implementing v1.1 in anticipation for a “public preview”
at the summit, I’ve started to wonder again about removing the ability to GET a
message by ID from the API. Previously, I was concerned that it may be too
disruptive a change and should wait for 2.0. But consider
On 8/25/14, 9:50 AM, Ryan Brown rybr...@redhat.com wrote:
I'm actually quite partial to roles because, in my experience, service
accounts rarely have their credentials rotated more than once per eon.
Having the ability to let instances grab tokens would certainly help
Heat, especially if we start
Hi folks,
I ran some rough benchmarks to get an idea of where Zaqar currently stands
re latency and throughput for Juno. These results are by no means
conclusive, but I wanted to publish what I had so far for the sake of
discussion.
Note that these tests do not include results for our new Redis
Correction: there were 25 workers per producer process, not 10.
On 8/26/14, 4:41 PM, Kurt Griffiths kurt.griffi...@rackspace.com wrote:
### Event Broadcasting (Balanced) ###
This test uses the same number of producers and consumers, but note that
the observers are still listing (up to) 5
Hi crew, I’d like to propose Vicky (vkmc) be added to Marconi’s core reviewer
team. She is a regular contributor in terms of both code and reviews, is an
insightful and regular participant in team discussions, and leads by example in
terms of quality of work, treating others as friends and
I’m game for thursday. Love to help out.
On 8/1/14, 2:26 AM, Flavio Percoco fla...@redhat.com wrote:
On 07/31/2014 09:57 PM, Victoria Martínez de la Cruz wrote:
Hi everyone,
Earlier today I went through the documentation requirements for
graduation [0] and it looks like there is some work
Hi everyone, we have discussed a few new names for the project to avoid
trademark issues. Previously, we had chosen “Naav” but several people weren’t
feeling great about that name. So, we discussed this today in
#openstack-marconi and got consensus to rename Marconi to Zaqar. If anyone has
Hi everyone, sorry for the short notice, but we are going to hold a special
roadmap planning meeting today. Everyone is welcome to attend, but I esp. need
core reviewers to attend:
When: 2100 UTC
Where: #openstack-marconi
Agenda: https://etherpad.openstack.org/p/marconi-scratch
Hope to see you
AM, Kurt Griffiths kurt.griffi...@rackspace.com
wrote:
OK, I just checked and 1400 and 1500 are already taken, unless we want to
move our meetings to #openstack-meeting-3. If we want to stick with
#openstack-meeting-alt, it will have to be 1300 UTC.
On 7/22/14, 5:28 PM, Flavio Percoco fla
Oops, sorry folks, one correction. We will be meeting on Mondays starting
next week, rather than Tuesdays as we have been. This week we will not
hold our regular meeting, but may do a special j-3 planning session (stay
tuned for details).
On 7/28/14, 10:43 AM, Kurt Griffiths kurt.griffi
OK, I just checked and 1400 and 1500 are already taken, unless we want to
move our meetings to #openstack-meeting-3. If we want to stick with
#openstack-meeting-alt, it will have to be 1300 UTC.
On 7/22/14, 5:28 PM, Flavio Percoco fla...@redhat.com wrote:
On 07/22/2014 06:08 PM, Kurt Griffiths
FYI, we chatted about this in #openstack-marconi today and decided to try
2100 UTC for tomorrow. If we would like to alternate at an earlier time
every other week, is 1900 UTC good, or shall we do something more like
1400 UTC?
On 7/21/14, 11:21 AM, Kurt Griffiths kurt.griffi...@rackspace.com
Kamalambal wrote:
On 7/16/14 4:43 AM, Flavio Percoco fla...@redhat.com wrote:
On 07/15/2014 06:20 PM, Kurt Griffiths wrote:
Hi folks, we¹ve been talking about this in IRC, but I wanted to bring
it
to the ML to get broader feedback and make sure everyone is aware.
We¹d
like to change our meeting
Hi folks, we’ve been talking about this in IRC, but I wanted to bring it to the
ML to get broader feedback and make sure everyone is aware. We’d like to change
our meeting time to better accommodate folks that live around the globe.
Proposals:
Tuesdays, 1900 UTC
Wednessdays, 2000 UTC
/marconi/+spec/async-backend-drivers
I’d love to get your thoughts on this; it would be great if we could get some
of this work done during Juno, although I suspect we may not have enough
bandwidth to get everything where we want it to be until the K cycle.
--
Kurt Griffiths (kgriffs
alternative to MongoDB.
Instead, we can look into some other backends that offer a good mix of
durability and performance.
What does everything think about this strategy?
--
Kurt Griffiths (kgriffs)
___
OpenStack-dev mailing list
OpenStack-dev
Hi everyone, I just wanted to to congratulate Nataliia on making Marconi one of
the first OS project to pass the py33 gate!
https://pbs.twimg.com/media/BrEQrZiCMAAbfEX.png:large
Now, let’s make that gate voting. :D
---
Kurt Griffiths (kgriffs
that will
allow us to deliver version 1.1 for the Juno-2 milestone release.
You can download the juno-1 release and review the changes here:
https://launchpad.net/marconi/+milestone/juno-1
Thanks to everyone who contributed to this first milestone! It’s great to
see all the new contributors.
--
Kurt
Hey crew, as promised, I digitized the pages from the easel pad at our program
pod in Atlanta. They are now available on the wiki along with a few notes to
help everyone remember what all the scribbling is supposed to mean. :D
https://wiki.openstack.org/wiki/Juno/Notes/Marconi
Thanks everyone
be; I am describing the API as it stands today).
To my knowledge, this API can’t be mapped directly to AMQP. Perhaps
thereare other types of brokers that can do it?
On 6/10/14, 7:17 AM, Gordon Sim g...@redhat.com wrote:
On 06/09/2014 08:31 PM, Kurt Griffiths wrote:
Lately we have been talking
Will Marconi only support HTTP as a transport, or will it add other
protocols as well?
We are focusing on HTTP for Juno, but are considering adding a
lower-level, persistent transport (perhaps based on WebSocket) in the K
cycle.
Can anyone describe what is unique about the Marconi design with
This is a minor bug-fix release. Deleting claimed messages now works as
expected. You can get the latest client from PyPI, and a tarball is also
available:
https://pypi.python.org/pypi/python-marconiclient/
http://tarballs.openstack.org/python-marconiclient/
NOTE: Yes, the installation
Folks, this may be a bit of a bombshell, but I think we have been dancing
around the issue for a while now and we need to address it head on. Let me
start with some background.
Back when we started designing the Marconi API, we knew that we wanted to
support several messaging patterns. We
: Kurt Griffiths
kurt.griffi...@rackspace.commailto:kurt.griffi...@rackspace.com
Date: Tuesday, June 3, 2014 at 9:34 AM
To: OpenStack Dev
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Marconi] Adopt Spec
I think it becomes more useful
decisions (e.g. Which endpoint/verb is the best fit for pop operation?)
Maybe spec is the place for these?
We should leave it to the implementor to decide, if the bp warrants a spec or
not what should be in the spec.
From: Kurt Griffiths
kurt.griffi...@rackspace.commailto:kurt.griffi
I’ve been in roles where enormous amounts of time were spent on writing specs,
and in roles where specs where non-existent. Like most things, I’ve become
convinced that success lies in moderation between the two extremes.
I think it would make sense for big specs, but I want to be careful we
Crew, as discussed in the last team meeting, I have updated the API v1.1
spechttps://wiki.openstack.org/wiki/Marconi/specs/api/v1.1 to remove the
ability to get one or more messages by ID. This was done to remove unnecessary
complexity from the API, and to make it easier to support different
+1 to code names.
Technically, if a program contains multiple projects, it would be more
correct to use the program name, but at this point I think it is pretty
ingrained in our culture (including IRC, mailing list and summits) to
refer to things by their code/project names, so IMO using those
adding another ~10kB to each request, just to save a once-a-day call to
Keystone (ie uuid tokens) seems to be a really high price to pay for not
much benefit.
I have the same concern with respect to Marconi. I feel like KPI tokens
are fine for control plane APIs, but don’t work so well for
.
There is a lot of work to be done to ensure this type of change goes smoothly.
But this is absolutely on the list of things we would like to address.
Cheers,
Morgan
Sent via mobile
On Wednesday, May 21, 2014, Kurt Griffiths
kurt.griffi...@rackspace.commailto:kurt.griffi...@rackspace.com wrote
Hi folks, I took the major work items we discussed at the summit and placed
them into the three Juno milestones:
https://wiki.openstack.org/wiki/Roadmap_(Marconi)
Let me know what you think over the next few days. We will address any
remaining questions and concerns at our next team meeting
Hi folks, I’m pleased to announce you can now pip install python-marconiclient
and get support for the entire v1.0 API. Although the package will remain
classified as “beta” while we polish off any rough edges, please take it for a
spin and let us know what you think.
Kudos goes to Flavio
)
* Tues 17:30 - Scaling an Individual
Queuehttps://etherpad.openstack.org/p/juno-marconi-scale-single-queue — Kurt
Griffiths
Also, I’ve set up some pads for the unconference sessions (@ the Marconi table)
I know about:
* Signed
messageshttps://etherpad.openstack.org/p/juno-marconi-signed
and interns, and see
several more large deployments of Marconi in production.
---
Kurt Griffiths | @kgriffs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi folks, has there been any discussion on using oslo.cache within the
auth_token middleware to allow for using other cache backends besides
memcached? I didn’t find a Keystone blueprint for it, and was considering
registering one for Juno if the team thinks this feature makes sense. I’d be
Matt Asay wrote:
We want people using the world's most popular NoSQL database with the
world's most popular open source cloud (OpenStack). I think our track
record on this is 100% in the affirmative.
So, I think it is pretty clear that there are lots of people who would
like to use MongoDB and
P.S. - Any particular reason this script wasn’t written in Python? Seems
like that would avoid a lot of cross-platform gotchyas.
On 3/26/14, 11:48 PM, Sergey Lukjanov slukja...@mirantis.com wrote:
FWIW It's working on OS X, but gnu-getopt should be installed.
Ah, that is good to know. Is this documented somewhere?
On 3/26/14, 11:48 PM, Sergey Lukjanov slukja...@mirantis.com wrote:
FWIW It's working on OS X, but gnu-getopt should be installed.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Team, what do you think about doing this for Marconi? It looks like we
indeed have a sample checked in:
https://review.openstack.org/#/c/83006/1/etc/marconi.conf.sample
Personally, I think we should keep the sample until generate_sample.sh
works on OS X (we could even volunteer to fix it);
As a quick review, storage policies allow objects to be stored across a
particular subset of hardware...and with a particular storage algorithm
Having worked on backup software in the past, this sounds interesting. :D
What is the scope of these policies? Are they per-object, per-container,
+1 million. I’ve been super impressed by Malini’s work and thoughtful
comments on multiple occasions.
On 3/21/14, 10:35 AM, Amit Gandhi amit.gan...@rackspace.com wrote:
+1
On 3/21/14, 11:17 AM, Flavio Percoco fla...@redhat.com wrote:
Greetings,
I'd like to propose adding Malini Kamalambal to
The incorporation of AGPLv3 code Into OpenStack Project is a
significant decision
To be clear, Marconi does not incorporate any AGPL code itself; pymongo is
Apache2 licensed.
Concerns over AGPL were raised when Marconi was incubated, and I totally
respect that some folks are not comfortable
I'd also like to thank the team and the overall community. The team
for its hard work during the last cycle and the community for being there
and providing such important feedback in this process.
+1, thanks again everyone for participating in the discussions and
driving towards a constructive
Thierry Carrez wrote:
There was historically a lot of deviation, but as we add more projects
that deviation is becoming more costly.
I totally understand the benefits of reducing the variance between
projects, and to be sure, I am not suggesting we have 10 different
libraries to do X. However,
Only one project is using swob, and it is unlikely that will change.
That begs the question, *why* is that unlikely to change? Is it because
there are fundamental needs that are not met by Pecan? If I understand the
original charter for Oslo, it was to consolidate code already in use by
projects
+1
On 3/18/14, 12:13 AM, Adrian Otto adrian.o...@rackspace.com wrote:
Solum Cores,
I propose the following changes to the Solum core reviewer team:
+gokrokve
+julienvey
+devdatta-kulkarni
-kgriffs (inactivity)
-russelb (inactivity)
Please reply with your +1 votes to proceed with this change,
Kudos to Balaji for working so hard on this. I really appreciate his candid
feedback on both frameworks.
After reviewing his report, I would recommend that Marconi continue using
Falcon for the v1.1 API and then re-evaluate Pecan for v2.0. Pecan will
continue to improve over time. We should
I think we can agree that a data-plane API only makes sense if it is
useful to a large number of web and mobile developers deploying their apps
on OpenStack. Also, it only makes sense if it is cost-effective and
scalable for operators who wish to deploy such a service.
Marconi was born of
After reviewing the report below, I would recommend that Marconi continue using
Falcon for the v1.1 API and then re-evaluate Pecan for v2.0 or possibly look at
using swob.
I wanted to post my recommendation to the general list, because my request to
continue using Falcon speaks to a broader
Folks,
I’m sure that I’m not the first person to bring this up, but I’d like to get
everyone’s thoughts on what concrete actions we, as a community, can take to
improve the status quo.
There have been a variety of instances where community members have expressed
their ideas and concerns via
Team, we will be discussing Marconi graduation from incubation in a couple
weeks at the TC meeting, March 18th at 20:00
UTChttp://www.timeanddate.com/worldclock/fixedtime.html?iso=20140318T20p1=1440.
It would be great to have as many people there as possible to help answer
questions, etc.
The fact is though that Freenode has had significant service degradation
due to DDoS attacks for quite some time
Rather than jumping ship, is there anything we as a community can do to
help Freenode? This would obviously require a commitment of time/money,
but it could be worth it for something
The poll has closed. flwang has been promoted to Marconi core.
@kgriffs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi folks, I’d like to propose adding Fei Long Wang (flwang) as a core reviewer
on the Marconi team. He has been contributing regularly over the past couple of
months, and has proven to be a careful reviewer with good judgment.
All Marconi ATC’s, please respond with a +1 or –1.
Cheers,
Kurt G.
Here’s an interesting hack. People are getting creative in the way they use
Marconi (this patch uses Rackspace’s deployment of Marconi).
https://github.com/paulczar/logstash-contrib/commit/8bfe93caf1c66d94690e9d9c2ecf9ee6b458b1d9
@kgriffs
___
FWIW, I believe Nova is looking at using JSON Schema as well, since they
need to handle API extensions. This came up during a design session at the
HK summit.
On 1/12/14, 5:33 PM, Jamie Lennox jamielen...@redhat.com wrote:
I would prefer not to have keystone using yet another framework from the
Hi folks, I put together a tracking blueprint for us to refer to in our team
meetings:
https://blueprints.launchpad.net/marconi/+spec/graduation
Also, here is an outline of what I want to a accomplish for Icehouse:
https://wiki.openstack.org/wiki/Marconi/roadmaps/icehouse
Feedback is
On Tue, Jan 7, 2014 at 2:25 PM, Kurt Griffiths
kurt.griffi...@rackspace.commailto:kurt.griffi...@rackspace.com wrote:
You might also consider doing this in WSGI middleware:
Pros:
* Consolidates policy code in once place, making it easier to audit and
maintain
* Simple to turn policy on/off
You might also consider doing this in WSGI middleware:
Pros:
* Consolidates policy code in once place, making it easier to audit and
maintain
* Simple to turn policy on/off – just don’t insert the middleware when off!
* Does not preclude the use of oslo.policy for rule checking
*
The Marconi project team holds a weekly meeting in #openstack-meeting-alt on
Tuesdays, 1500
UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=15min=0sec=0.
The next meeting is Tomorrow, Dec. 10. Everyone is welcome, but please take a
minute to review the wiki before attending for
The Marconi project team holds a weekly meeting in #openstack-meeting-alt
on Tuesdays, 1500
UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=15min=0sec=0.
The next meeting is Tomorrow, Dec. 10. Everyone is welcome, but please
take a minute to review the wiki before attending for the
This list of features makes me very nervous from a security standpoint. Are we
talking about giving an agent an arbitrary shell command or file to install,
and it goes and does that, or are we simply triggering a preconfigured action
(at the time the agent itself was installed)?
From: Steven
I love the idea of treating usability as a first-class citizen; to do that, we
definitely need a core set of people who are passionate about the topic in
order to keep it alive in the OpenStack gestalt. Contributors tend to
prioritize work on new, concrete features over “non-functional”
at present.
I'm not saying that we should necessarily design notifications for the latter
cases, because it introduces potentially quite a lot of user-demanded load on
the Openstack components, I'm just asking for a statement of intent.
--
Ian.
On 4 December 2013 16:09, Kurt Griffiths
Thanks! We touched on this briefly during the chat yesterday, and I will
make sure it gets further attention.
On 12/3/13, 3:54 AM, Julien Danjou jul...@danjou.info wrote:
On Mon, Dec 02 2013, Kurt Griffiths wrote:
Following up on some conversations we had at the summit, I¹d like to get
folks
Sorry to change things up again, but it’s been requested that we move our
meeting to Tuesday at 1500 UTC instead of Monday, since a lot of people’s
Mondays are crazy busy as it is. Unless anyone objects, let’s plan on
doing that starting with our next meeting (Dec 10).
On 11/25/13, 6:22 PM, Kurt
Folks,
Want to surface events to end users?
Following up on some conversations we had at the summit, I’d like to get folks
together on IRC tomorrow to crystalize the design for a notifications project
under the Marconi program. The project’s goal is to create a service for
surfacing events to
Hi folks,
To make it easier on our friends joining the project from across the world, I’d
like to propose moving our weekly meeting time back one hour to 1500 UTC:
http://www.timeanddate.com/worldclock/fixedtime.html?hour=15min=0sec=0
Any objections or alternate suggestions?
---
@kgriffs
Kurt
OK, I¹ve changed the time. Starting next Monday (2 Dec.) we will be
meeting at 1500 UTC in #openstack-meeting-alt.
See also: https://wiki.openstack.org/wiki/Meetings/Marconi
On 11/25/13, 11:33 AM, Flavio Percoco fla...@redhat.com wrote:
On 25/11/13 17:05 +, Amit Gandhi wrote:
Works for me.
Hi folks,
We have been discussing doing at least a basic/poc TCP transport as a way to
keep ourselves honest wrt the API abstraction work that was recently started. I
would like to propose using websocketshttps://tools.ietf.org/html/rfc6455 for
this work, for a few reasons:
1. It saves us
Also does it place a requirement that all projects wanting to request
incubation to be placed in stackforge ? That sounds like a harsh
requirement if we were to reject them.
I think that anything that encourages projects to get used to the
OpenStack development process sooner, rather than later,
No meeting on Monday due to the summit.
Cheers,
---
@kgriffs
Kurt Griffiths
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
The Marconi project team holds a weekly meeting in #openstack-meeting-
alt on Mondays, 1600 UTC.
http://goo.gl/Li9V4o
The next meeting is Monday, Oct 28. Everyone is welcome, but please
take a minute to review the wiki before attending for the first time:
http://wiki.openstack.org/marconi
the design finalized.
See also: https://blueprints.launchpad.net/marconi/+spec/storage-sharding
Thanks!
---
@kgriffs
Kurt Griffiths
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
side-effect of opening up Marconi to vendors for
customization.
Summary: http://goo.gl/2jxevN
Log: http://goo.gl/QQYrPx
Please join the conversation in #openstack-marconi, and help define the future
of the OpenStack Queue Service.
---
@kgriffs
Kurt Griffiths
The Marconi project team holds a weekly meeting in #openstack-meeting-
alt on Mondays, 1600 UTC.
The next meeting is Monday, Oct 21. Everyone is welcome, but please
take a minute to review the wiki before attending for the first time:
http://wiki.openstack.org/marconi
Proposed Agenda:
*
Hi folks,
Sorry for the late notice. During today's regular team meeting we will be
reviewing and freezing the v1 API. I hope to see you there!
1600 UTC @ #openstack-meeting-alt
Cheers,
Kurt G. (kgriffs)
___
OpenStack-dev mailing list
The Marconi project team holds a weekly meeting in #openstack-meeting-alt
on Mondays, 1600 UTC.
The next meeting is today, Sept. 30. Everyone is welcome, but please take
a minute to review the wiki before attending for the first time:
http://wiki.openstack.org/marconi
Proposed Agenda:
*
Does anyone have a feel for what Project ID (AKA Tenant ID) looks like in
practice? Is it always a number, or do some deployments use UUIDs or
something else?
@kgriffs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
The Marconi project team holds a weekly meeting in #openstack-meeting-alt
on Mondays, 1600 UTC.
The next meeting is this coming Monday, Sept. 23. Everyone is welcome, but
please take a minute to review the wiki before attending for the first time:
http://wiki.openstack.org/marconi
Proposed
I would like to announce my candidacy for the Marconi PTL. At the Grizzly
summit I organized the Marconi project in an unconference session at the
Grizzly summit, with some gracious help from Mark Atwood, who then
connected me with Monty Taylor who got us set up on Gerrit and Launchpad.
I was also
- OpenStack
Phone: (905) 413-2851tel:%28905%29%20413-2851
E-Mail: steve...@ca.ibm.commailto:steve...@ca.ibm.com
[Inactive hide details for Kurt Griffiths ---09/20/2013 01:18:51 PM---Does
anyone have a feel for what Project ID (AKA Tenant ID]Kurt Griffiths
---09/20/2013 01:18:51 PM---Does anyone
Hi folks,
Today the Marconi team held its regular Monday meeting[1] in
#openstack-meeting-alt @ 1600 UTC. Among other things, we discussed
progress on marconi-proxy:
Minutes: http://goo.gl/kfBjF8
Log: http://goo.gl/GoUU4c
As always, you can catch us in #openstack-marconi in between the weekly
The Marconi project team holds a weekly meeting in #openstack-meeting-alt
on Mondays, 1600 UTC.
The next meeting is tomorrow, Sept. 16. Everyone is welcome. However,
please take a minute to review the wiki before attending for the first
time:
http://wiki.openstack.org/marconi
Proposed Agenda:
1 - 100 of 109 matches
Mail list logo
