on't attempt to do a
> piece-by-piece conversion in the meantime.
I agree with Daniel here. I'd rather have a single, ninja-approved patch
changing all matches than several small patches that introduce unrelated
changes to replace warn with warning. An additional benefit is that the
single-replacement patch may also be used as a reference for future
commits using `warn` instead of `warning`.
My $0.02,
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
do this? :-)
>>
>> +1 obviously.
>
> I did think it would be a good idea to wait a *little* while and make sure we
> weren’t going to scare him off. ;-)
>
> Seriously, Mike has been doing a great job collaborating with the existing
> team and helping us make oslo.db sane.
>
> +1
Big +1
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s that we will rename is:
>
> openstack/marconi -> openstack/zaqar
> openstack/python-marconiclient -> openstack/python-zaqarclient
> openstack/marconi-specs -> openstack/zaqar-specs
Thanks!
--
@flaper87
Flavio Percoco
__
change
>>> that shows the latest results in a table format. (You may need to
>>> force-reload in your browser to see the change.)
>>
>> Beautiful! Thank you so much to everyone involved.
>
> +1! Love this.
>
Yes, finally. One of the things I really wanted.
Thanks guys!
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
#x27;s the only project
> that graduated since Havana that I can, off hand, point at as clearly
> successful. Heat and Ceilometer both graduated prior to being in
> production; a few cycles later, they're still having adoption problems
> and looking at large architectural changes. I t
27;t
> ready for production. That doesn't mean we haven't made mistakes, but
> we're trying to learn and improve. We developed a set of *written*
> guidelines to stick to, and have been holding all projects up to them.
> Teams like Ceilometer have been very receptive to the process, have
> developed plans to fill gaps, and have been working hard on the issues.
>
> A hard rule for production deployments seems like a heavy rule. I'd
> rather just say that we should be confident that it's a production ready
> component, and known deployments are one such piece of input that would
> provide that confidence. It could also just be extraordinary testing
> that shows both scale and quality.
+1, we can't force people to deploy a non-integrated project and we
shouldn't hold all incubated projects on that.
Cheers,
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
this list,
we need to go through the "must have" requirements and see how many of
them are met by these projects and whether there are good established
plans to meet the ones left, if any.
Speaking for Zaqar (Marconi), we've been always honest about the project
maturity and a good exa
day.
>
> Thanks,
> Arnaud
>
>
> [1]https://wiki.openstack.org/wiki/Juno_Release_Schedule
> [2]https://etherpad.openstack.org/p/j3-glance-patches
>
>
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.o
rg/meetings/tc/2014/tc.2014-03-04-20.02.log.txt
>
>
>
> --
> Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
ince the incubator doesn't do "releases" anyway. However,
> it has to be renamed to "oslo-incubator" so that it doesn't conflict
> with the projectgroup namespace. Once it no longer contains graduated
> libs, that name makes much more sense anyway.
hat doesn't work (scaling/burnout).
>
+1
FWIW, this is how things have worked in Zaqar since the very beginning.
We've split our duties throughout the team, which helped clearing some
of the PTL duties. So far, we have people responsible for:
* Bugs for the server
* Bugs for th
he requirement to unpin
> the version of the library.
>
> So, please review, backport, and make sure it lands in project
> requirements files.
>
> /Ihar
>>
>> ___
>> OpenStack-dev mailing
e talk/think about PTLs.
Flavio
> I'm open to the alternative solution (which would be for programs which
> are not interested in having a PTL to just not have one). But then if
> things go badly wrong, you require the TC to step in with threats of
> removal of OpenStack and/or to force an election/vote in the middle of
> the crisis. I'm really failing to see how that would result, in those
> hypothetical crisis scenarios, in a better outcome.
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ng
> meetings and organizing meetups), design summit planning, roadmapping,
> user point of contact, or spokesperson -- as I expect the PTL to retain
> those roles anyway...
+1 for letting the PTL take care of this.
Flavio
--
@flaper87
Flavio Percoco
___
und of benchmarking.
> [5]: In a real app, messages will usually be requested in batches.
> [6]: In this test, the target client does not send a response message back
> to the sender. However, if it did, the test would still only require a
> single queue, since in Zaqar queues are du
Release a new version with the new name `glancestore`
- Switch glance over to `glancestore`
- Complete the rename process with support from infra
2. Let this patch land, complete Glance's switch-over using namespaces
and then do the rename all together.
Do you have any other suggestion that would help avoiding namespaces
without blocking glance.store?
Thanks,
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rom days 1 - 3 and expand the
> hallway time. Hallway track is always pretty interesting, and honestly
> at a lot of interesting ideas spring up. The 10 minute transitions often
> seem to feel like you are rushing between places too quickly some times.
+1
Last summit, it was basically impossible to do any hallway talking and
even meet some folks face-2-face.
Other than that, I think the proposal is great and makes sense to me.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 08/27/2014 05:52 PM, Doug Hellmann wrote:
>
> On Aug 27, 2014, at 11:14 AM, Flavio Percoco wrote:
>
>> On 08/27/2014 04:31 PM, Sean Dague wrote:
>>> So this change came in with adding glance.store -
>>> https://review.openstack.org/#/c/115265/5/lib/g
On 08/27/2014 09:18 PM, James E. Blair wrote:
> Sean Dague writes:
>
>> On 08/27/2014 11:14 AM, Flavio Percoco wrote:
>>> On 08/27/2014 04:31 PM, Sean Dague wrote:
>>> 1. Do a partial rename and then complete it after the glance migration
>>> is done. If
n the API, which would require
a major release. What we can do, though, is start working on a spec for
the V2 of the API.
API v2 sounds like a good topic for a design session, we've already done
a good cleanup of minor things in v1.1 and I believe we can make v2
happen in Kilo.
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.
https://etherpad.openstack.org/p/kilo-zaqar-summit-topics
Flavio
--
@flaper87
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.
https://etherpad.openstack.org/p/kilo-zaqar-summit-topics
Flavio
--
@flaper87
ip/xstatic/__init__.py
>>
> More on that at
> http://pythonhosted.org/setuptools/setuptools.html?namespace-packages#namespace-packages
>
This is not solved. In fact, we already declare the namespace in the
__init__ files. The problem, as Sean mentioned, is the way
stated in my last comment on
the driver's review, I think we should let this driver land and let
future patches improve it where/when needed.
I agreed on letting the driver land as-is based on the fact that there
are patches already submitted ready to enable the gates for this d
o quickly.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
sides the time
they're dedicating to other projects) to do that work.
One more thing, we need to add to the list of ports to do during Kilo
the backlog of ports that haven't happened yet. For example, I haven't
ported glance to oslo.utils yet. I expect to do it before the
ists.openstack.org/pipermail/openstack-dev/2013-September/015264.html
> Thanks!
> Alex
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/op
for Zaqar[0]. The list is not exhaustive and
it'll contain more information before the next meeting.
[0] https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases
Thanks to all of you who attended the meeting, I'm looking forward to
your feedback and obviously the next meeting
e one that I worry may not
> be served best by bending #1 onto it.
Push semantics are being developed. We've had enough discussions that
have helped preparing the ground for it. However, I believe both use
cases could be covered by Zaqar as-is.
Could you elaborate a bit more on #2? Especially on why you think Zaqar
as is can't serve this specific case?
Also, feel free to add use-cases to that etherpad if there's anything
missing. :D
Cheers,
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
estartable-image-download
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/04/2014 01:15 PM, Chris Dent wrote:
> On Thu, 4 Sep 2014, Flavio Percoco wrote:
>
> Thanks for writing this up, interesting read.
>
Thank you for your feedback :)
Some comments in-line.
>> 5. Ceilometer's recommended storage driver is still MongoDB, althoug
On 09/04/2014 02:14 PM, Sean Dague wrote:
> On 09/04/2014 03:08 AM, Flavio Percoco wrote:
>> Greetings,
>>
>> Last Tuesday the TC held the first graduation review for Zaqar. During
>> the meeting some concerns arose. I've listed those concerns below with
>>
t;optional"
services, we will have to re-evaluate all the integrated projects and
move those that fit into that category.
>
> I'm still hesitating on the best approach. I think they yield the same
> end result, but the -1 approach seems to be a bit more unfair, since it
> would
and complete this work now.
Thanks for sending the email,
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/04/2014 07:08 PM, Clint Byrum wrote:
> Excerpts from Flavio Percoco's message of 2014-09-04 06:01:45 -0700:
>> On 09/04/2014 02:14 PM, Sean Dague wrote:
>>> On 09/04/2014 03:08 AM, Flavio Percoco wrote:
>>>> Greetings,
>>>>
>>>> Las
Stack too if we get
> it right.
>
I think it is sexy - I don't describe ideas/software as sexy that often
but this one deserves it. I'm interested in helping out.
I'll clone it and give it a try - or at least take a look at it.
Flavio
> Monty
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/05/2014 05:20 PM, Thierry Carrez wrote:
> Flavio Percoco wrote:
>> Greetings,
>>
>> I'd like to request a FFE for 2 features I've been working on during
>> Juno which, unfortunately, haven been delayed for different reasons
>> during this time.
>
approve the patch.
I'm basically saying the same thing that has been proposed but based on
the current default + an exception to the rule. What changes is the way
people approach reviews. Leaving 2x+2 as the default but allowing
exceptions where people can 1x+2A is bette
u care about a
store that is not tested in the gate, please, do test it in your own
environment.
If anything comes up, do not hesitate to contact me or any other
glance_core.
[0] https://review.openstack.org/#/c/100636/
[1] http://git.openstack.org/cgit/openstack/glance_store
] "Queue service" is even the official OpenStack Program name, and
> the mission statement starts with "To produce an OpenStack message
> queueing API and service."
>
> http://git.openstack.org/cgit/openstack/governance/tree/refer
can integrate with Zaqar to surface events
to end users and to communicate with guest agents that run in the
"over-cloud" layer. Cloud operators can leverage Zaqar to provide
equivalents of SQS and SNS to their customers."
To be fair, w
be a reasonable short term
> solution which would allow less pressured reviewing of 120300?
>
Why do you think landing 120300 will take long? If both patches are
already on gerrit, I'd rather review the real fix.
Is there a reason you think landing 120143
[3]: One might argue that the only thing these performance tests show
> is that *OnMetal* is fast. However, as I have pointed out, there was plenty
> of headroom left on these servers during the tests, so similar results
> should be achievable using more modest hardware.
> [4]: In a real app, messages will usually be requested in batches.
> [5]: In this test, the target client does not send a response message back
> to the sender. However, if it did, the test would still only require a
> single queue, since in Zaqar queues are duplex (although this can be
> disabled by setting echo=True in the query string when listing messages).
> [6]: Chosen somewhat arbitrarily.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t; it might take a while to go through the review cycle. However, the
> consensus seems to be to go directly with 120300 -- that it shouldn't
> take too long to get through. (And its on-demand schema behaviour is
> a nice bonus too!)
>
+1 lets go with that!
>
>> Flavio
>
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/10/2014 03:18 PM, Gordon Sim wrote:
> On 09/10/2014 09:58 AM, Flavio Percoco wrote:
>> To clarify the doubts of what Zaqar is or it's not, let me quote what's
>> written in the project's overview section[0]:
>>
>> "Zaqar is a multi-te
for other messaging related services. One
of the ideas that has come up quite a few times is having a service that
provisions message brokers (or other messaging technologies). However, I
believe that's a complete different service and it's out of the scope of
what Zaqar wants to do.
T
;field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on
>
>
>
Awesome,
Thanks for organizing this, Cindy.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
nother way to access messages. It makes it easier for users to
stream messages out of Zaqar if that's what works best for them. I
understand that what I'm describing is precisely what a queue does but
in Zaqar it's a way for users to follow-their-nose and keep consuming
messages.
I'm not saying it couldn't be revisited, though. I'm trying to explain
that it adds support for a common way to access messages.
> The fact that sessions are a part of AMQP makes it complicated to
> emulate over HTTP when messages need to be ACK'd. However, it seems
> pretty straight forward to me to have session ID as part of the API, and
> to have an RPC bus like we do now for our usual OpenStack services that
> has a topic per session. Then have the API frontends speaking over that
> bus, pushing ACK's down that topic to a backend engine that maintains
> the session. This is double-messaging for everything, which I wish I
> could think of a better solution for, but it is still lighter weight
> than putting all of the messages into a database.
I'm not sure I follow what you suggested here so I'll wait before I
comment. What I didn't understand is whether you were thinking to have
that solution as part of Zaqar or as a way to achieve browsability
without Zaqar.
> Finally, two of the main sections in that article state "Store and
> Forward" and "Message access by ID" are important to Zaqar. Those two
> concepts are SMTP and IMAP in a nutshell. It still kind of boggles
> my mind that these weren't considered as backends, given that their
> protocols even match reasonably well to the parts of Zaqar's API that
> pertain to messages. They may not be sexy, but I'd be quite surprised
> if there wasn't an SMTP+IMAP combination out there that can scale at
> least as cost effectively as Redis.
FWIW, the article doesn't say "Message access by ID" is important. It
says that it's there now and we can't simply remove it because there are
people already using it.
In this analysis, we had to choose between having half-backed APIs -
because the storage driver wouldn't support all the features that have
been exposed - and preserving clouds interoperability. One of the
discussions we had about "Reconsidering the Unified API" brought up some
good points. In particular, the feedback Devananda provided in this
email[0] was very useful to make a final decision. We obviously decided
to preserve cloud interoperability.
In the other hand, store-and-forward is indeed, as of now, a key and
important point in Zaqar's architecture. The choices the team has made
for the storage drivers have been questioned a lot since its inception.
At the incubation meeting the feedback was that mongodb's AGPL license
was not good, hence sqlalchemy was added. At the first graduation
attempt the sqlalchemy driver didn't turn out to be as good as we hoped,
hence redis was added. And now IMAP. Don't get me wrong, I'm not trying
to be mean/jerk, really. What I'm trying to get at is that behind the
choices the team has made there were technical aspects that were taken
under consideration. I know you're not saying there weren't but I think
it's worth highlighting this.
That said, I haven't experimented enough with SMTP+IMAP to be able to
provide a good feedback for it but I believe no one is opposed to have
an IMAP+SMTP driver. However, I don't think the team, as it is now, has
the resources, time and energy to maintain a fourth driver. That driver
will have to live in an external repository until it proves itself to be
good and worth maintaining. Really, the building blocks to do so are
there, it's easy to have drivers built in external repositories and
anyone can play with that.
[0] http://lists.openstack.org/pipermail/openstack-dev/2014-June/037377.html
Thanks for providing very useful feedback, Clint.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
che Kafka. Unfortunately
> it is a massive Java application with Zookeeper dependencies, and we all
> know how Monty feels about those ;) (FWIW, I agree with him.) Given
> that's a non-starter as the _default_ back-end, the current design of
> allowing multiple pluggable storage
large-scale tests.
Lets talk about it :)
Would it be possible to get an update from you at the summit (or mailing
list)? I'm interested to know where you guys are with this, what is
missing and most importantly, how we can help.
Thanks Boris,
Flavio
--
@flaper87
Flavio Percoco
_
totypes for at least nova to talk to neutron
>> and cinder which i'm waiting for Kilo to push. From there it should be
>> easier to do this for other services.
>>
>> For service to service communication there are two types.
>> 1) using the user's token like nova->cinder. If this token expires there is
>> really nothing that nova can do except raise 401 and make the client do it
>> again.
>
> In this case it would be really good to do at least 1 retry, because
> it's completely silly for us to fail an action based on a token timeout.
> The solution ops are doing is changing their token expiration back to
> some really large number.
>
>> 2) using a service user like nova->neutron. This should allow automatic
>> reauthentication and will be fixed/standardied by sessions.
>
> Ok, glanceclient should be a high target here, because that's often
> involved in long running things (snapshot manip is slow).
Agreed. I started looking at this a couple of weeks ago but I'm still
not sure what the best way to do this is. The failure is common when
uploading huge images and I also agree that at least 1 retry should be
attempted.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/12/2014 11:36 AM, Thierry Carrez wrote:
> Flavio Percoco wrote:
>> On 09/12/2014 12:14 AM, Zane Bitter wrote:
>>> The final question is the one of arbitrary access to messages in the
>>> queue (or "queue" if you prefer). Flavio indicated that this eff
On 09/12/2014 01:56 PM, Flavio Percoco wrote:
> On 09/12/2014 11:36 AM, Thierry Carrez wrote:
>> Flavio Percoco wrote:
>>> On 09/12/2014 12:14 AM, Zane Bitter wrote:
>>>> The final question is the one of arbitrary access to messages in the
>>>> queue (o
mmand to tox to remove the files would be less intrusive than
> disabling their creation.
>
> We have had bad experiences mixing features to produce unusual dev
> environments that are different from the way the software really runs. All of
> the issues we had with namespace packages were caused by a bug in that
> implementation exposed because we were doing something unusual in devstack,
> for example.
>
> Adding some variation of “find $(python setup.py --name) --name ‘*.pyc’ |
> xargs rm -f” to tox.ini before running testr solves the problem you have
> identified without introducing any side-effects.
>
This sounds saner to me so, I'd definitely go for this one.
(FWIW, I'm use to clean up `pyc` files by myself)
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e user the choice of where they want
their messages to be stored. This certainly requires the deployer to
have installed stores that are good for each job. For example, based on
the current existing drivers, a deployer could have configured a
high-throughput flavor on top of a redis node that ha
a stateless
> HTTP protocol, we need something to maintain that specific AMQP session
> until the HTTP protocol receives an ACK from the client after the client
> has consumed or somehow stored the message. So, these queues have to be
> auto-ACK, or we have to figure out a way to
>>> Please provide feedback to help us resolve this dispute if you feel you can!
>>
>> My feeling is this is an INFO level. There is really nothing the admin
>> should care about here.
>
> Agree with Sean. INFO are useful for investigations. WARN and ERROR are
&
g/p/cinder-meetup-summer-2014
>>> [3]
>>> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html
>>> [4] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
>>>
>>> Regards,
>>> Ivan Kolodyazhny.
>>>
>>
isited constantly to make sure they are both going towards the agreed
goal during the incubation meeting.
Ok, I think the email is long enough. I'd love to discuss the points
aforementioned further and work on a way to make this process smoother
and easier for everyone.
Cheers,
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e project is where it is also
because of your contributions and support. You played a key role in the
project's growth and we all thank you a lot for that.
I'm sad to see you go and I wish you luck on your new adventures :)
Cheers,
Flavio
bility problems
> if you try to mis requests.packages.urllib3 and urllib3 in one codebase
> and if you’re using requests at all it’s going to be expecting to use
> the embedded copy of urllib3.
After having gone through the whole thread
gt; setup overhead for every sent message. This may also bring further
>> performance benefits due to underlying messaging batching in ZMQ.
>
> This sounds like it would be a good thing to do, but making what we have work
> correctly and testing it feels more important for now.
>
e split the above into milestones w/ due dates?
Thanks,
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ns. I'm sure we had this documented way better but I can't find
the link. :(
[0]
https://wiki.openstack.org/wiki/Zaqar/Frequently_asked_questions#How_does_Zaqar_compare_to_AWS_.28SQS.2FSNS.29.3F
Hope the above helps,
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
;> Correct validation history is
>>
>> Essex: "use anything you want!"
>> Folsom: "strict asci!"
>> [..]
>> Juno: "strict asci!"
>>
>> So I don't think we should make the input validation loose right no
On 09/18/2014 04:09 PM, Gordon Sim wrote:
> On 09/18/2014 12:31 PM, Flavio Percoco wrote:
>> On 09/17/2014 10:36 PM, Joe Gordon wrote:
>>> My understanding of Zaqar is that it's like SQS. SQS uses distributed
>>> queues, which have a few unusual properties [0]
ouldn't find anything.
>>
>>
>>
>>
>>
>> [0]
>> http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/DistributedQueues.html
>> [1] https://wiki.openstack.org/wiki/Zaqar
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/18/2014 04:16 PM, Kapil Thangavelu wrote:
>
>
> On Thu, Sep 18, 2014 at 4:18 AM, Flavio Percoco <mailto:fla...@redhat.com>> wrote:
>
> On 09/17/2014 04:34 PM, Doug Hellmann wrote:
> > This thread [1] has turned more “future focused", so I’m mov
On 09/18/2014 05:42 PM, Steve Lewis wrote:
> On September 18, 2014 7:45 AM, Flavio Percoco wrote:
>
>> On 09/18/2014 04:09 PM, Gordon Sim wrote:
>>
>>> However, as far as consuming messages is concerned, it can
>>> guarantee once-and-only-once and/or at-leas
On 09/18/2014 09:25 PM, Gordon Sim wrote:
> On 09/18/2014 03:45 PM, Flavio Percoco wrote:
>> On 09/18/2014 04:09 PM, Gordon Sim wrote:
>>> Is the replication synchronous or asynchronous with respect to client
>>> calls? E.g. will the response to a post of messages be
On 09/18/2014 07:19 PM, Joe Gordon wrote:
>
>
> On Thu, Sep 18, 2014 at 7:45 AM, Flavio Percoco <mailto:fla...@redhat.com>> wrote:
>
> On 09/18/2014 04:09 PM, Gordon Sim wrote:
> > On 09/18/2014 12:31 PM, Flavio Percoco wrote:
> >> O
On 09/18/2014 07:16 PM, Devananda van der Veen wrote:
> On Thu, Sep 18, 2014 at 8:54 AM, Devananda van der Veen
> wrote:
>> On Thu, Sep 18, 2014 at 7:45 AM, Flavio Percoco wrote:
>>> On 09/18/2014 04:09 PM, Gordon Sim wrote:
>>>> On 09/18/2014 12:31 PM,
cale out the storage layer and
balance the load across them.
There's always space for improvement and I definitely wouldn't go that
far to say there's a need to start over.
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/18/2014 11:51 AM, Angus Salkeld wrote:
>
> On 18/09/2014 7:11 PM, "Flavio Percoco" <mailto:fla...@redhat.com>> wrote:
>>
>> Greetings,
>>
>> If I recall correctly, Heat was planning to adopt Zaqar regardless of
>> the result of
ghtstreams.io/combined/marconi-progress-and-updates/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
@flaper87
Flavio Percoco
quot;contribute" a design session to focus on improving UX across
the community, and I would certainly attend!
We also discussed about having a cross-project session at the summit.
I think this is becoming more and more important.
Cheers,
FF
--
@flaper87
Flavio Percoco
case: https://review.openstack.org/#/c/57132/
Cheers,
FF
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 21/11/13 18:44 +0100, Flavio Percoco wrote:
Greetings,
There are some patches that add support for building wheels. The patch
adds a `[wheel]` section with `universal = True`
`universal=True` means the applications supports py2/py3 which is not
the case for most (all?) openstack projects
alse seen it being done by others. In most of the
cases, using the commit message title is enough. However, if the sync
is intended to fix a bug or introduces more relevant changes, it is
definitely useful to have that expressed in the commit message.
FF
--
@flaper87
Flavio Percoco
pgpLu2NRP0IX
houghts?
Cheers,
FF
--
@flaper87
Flavio Percoco
pgpCmV9OwmxXq.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ges
are immutable.
Thanks for raising this.
Cheers,
FF
--
@flaper87
Flavio Percoco
pgpjHQZsAZBI_.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e for this, I'm curious to know why - if so - you
created your own spec, what are the benefits and if it's documented
somewhere.
Cheers,
FF
[0] http://tools.ietf.org/html/draft-nottingham-json-home-02
--
@flaper87
Flavio Percoco
pgpSSZY2EwSLO.pgp
Description: PGP signature
___
@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
@flaper87
Flavio Percoco
pgpxpMTb75cQH.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+spec/improve-update-script
--
@flaper87
Flavio Percoco
pgp610yEgnGwn.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
(although some of our docs use
the terms interchangeably).
And, FWIW, Marconi uses project as well.
FF
--
@flaper87
Flavio Percoco
pgpn4defnwUMD.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://list
On 25/11/13 17:05 +, Amit Gandhi wrote:
Works for me.
Works for me!
--
@flaper87
Flavio Percoco
pgpkFlvVx8sKs.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
ported. As for now, we
disable keystone auth when running under Py3K.
Cheers,
FF
--
@flaper87
Flavio Percoco
pgp3VWRo_myJf.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-
On 25/11/13 16:50 -0600, Dolph Mathews wrote:
On Mon, Nov 25, 2013 at 2:41 AM, Flavio Percoco wrote:
On 25/11/13 09:28 +1000, Jamie Lennox wrote:
So the way we have this in keystone at least is that querying GET /
will
return all available API versions and querying
;t able
to find anyone on IRC who was able to look into this.
This seems to be the issue you're talking about, is it?
http://logs.openstack.org/49/57049/2/gate/gate-swift-python26/c1aedf1/console.html
Thanks for the heads up!
FF
--
@flaper87
Flavio Percoco
pgpkReKS5IQwB.pgp
Description
parts you think should be addressed first.
Thanks again,
FF
--
@flaper87
Flavio Percoco
pgpwMjgjSiy0i.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
te mark
those bugs as critical.
Would a combination of High + tag - elastic-recheck - make sense?
With the above it would be easier to triage them, to know where they
came from and to prioritise them correctly.
Cheers,
FF
--
@flaper87
Flavio Percoco
pgpd
On 26/11/13 22:54 +, Mark McLoughlin wrote:
On Fri, 2013-11-22 at 12:39 -0500, Doug Hellmann wrote:
On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco wrote:
>1) Store the commit sha from which the module was copied from.
>Every project using oslo, currently keeps the list of m
On 27/11/13 10:59 +, Mark McLoughlin wrote:
On Wed, 2013-11-27 at 11:50 +0100, Flavio Percoco wrote:
On 26/11/13 22:54 +, Mark McLoughlin wrote:
>On Fri, 2013-11-22 at 12:39 -0500, Doug Hellmann wrote:
>> On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco wrote:
>> &g
On 26/11/13 10:57 -0600, Dolph Mathews wrote:
On Tue, Nov 26, 2013 at 2:47 AM, Flavio Percoco wrote:
As crazy as it sounds, have you guys considered migrating to
Nottingham's approach?
It only sounds crazy because I have no idea how to "migrate" an unversioned
endpo
ow we have been responding to
patches and blueprints offerings improvements and feature requests for
oslo.messaging.
+1
FF
--
@flaper87
Flavio Percoco
pgpq0wWsoLCQL.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
ving obsolete packages there may make sense. I'd also
update the module - or package - and make it print a deprecation
warning.
FF
--
@flaper87
Flavio Percoco
pgpNqMKh1PkJM.pgp
Description: PGP signature
___
OpenStack-dev mailing list
O
On 02/12/13 09:40 -0500, Doug Hellmann wrote:
On Mon, Dec 2, 2013 at 9:25 AM, Flavio Percoco wrote:
On 02/12/13 09:06 -0500, Russell Bryant wrote:
On 12/02/2013 08:53 AM, Doug Hellmann wrote:
So, to clarify, possible flows would be:
1) An API moving to a library as
I think doing it by Icehouse seems reasonable. I think
that is what you and Monty are asking for?
I have added the task to our list on
https://wiki.openstack.org/wiki/Barbican/Incubation.
Thanks a lot for this, really!
Cheers,
FF
--
@flaper87
F
get some feedback there.
Thanks!
FF
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e end of the day.
Cheers,
FF
--
@flaper87
Flavio Percoco
pgpJB2reqvj7y.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
1 - 100 of 1147 matches
Mail list logo
