one objects, I'll proceed and add him in a week
from now.
[1] http://stackalytics.com/report/contribution/zaqar-ui/90
+1, and thank you for your work on Zaqar's UI!
--
Ryan Brown / Senior Software Engineer, Openstack / Re
on to the team. If
no one objects, I'll proceed and add her in a week from now.
+1, cheers!
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Mailing List (not for usage
for projects at work and at play. If OpenStack pays your salary,
consider giving the tox/pytest team a slice.
Cheers,
Ryan
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Mailin
spacing etc) is something we can agree
API-WG both does and should care about.
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
.com/?project_type=all&release=all&module=poppy&metric=commits
I'd say no, Poppy is an open source project/product that makes it easier
to use the different vendors of commodity services, and that's not a
reason to boot it.
Sidebar: I recall a few years ago that Rac
On 02/05/2016 01:00 PM, Sean Dague wrote:
On 02/05/2016 12:16 PM, Ryan Brown wrote:
On 02/05/2016 09:08 AM, michael mccune wrote:
On 02/04/2016 12:57 PM, Hayes, Graham wrote:
On 04/02/2016 15:40, Ryan Brown wrote:
[snipped lots]
This isn't a perfect solution, but maybe inste
On 02/05/2016 09:08 AM, michael mccune wrote:
On 02/04/2016 12:57 PM, Hayes, Graham wrote:
On 04/02/2016 15:40, Ryan Brown wrote:
[snipped lots]
This isn't a perfect solution, but maybe instead of projects.yml there
could be a `registry.yml` project that would (of course) have al
stack product that requires you to pay a vendor is
as functional as an openstack product chock-full of syntax errors
** Shed Cat Enterprise Leopard is strictly fictional, and not based on
any company that currently or ever has existed.
--
Ryan Brown / Senior Software Engineer,
e of things , i don't have an objection but i am
very curious to hear Everett's and Chris' opinions.
regards,
mike
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@
On 01/27/2016 03:31 PM, Dean Troyer wrote:
On Wed, Jan 27, 2016 at 1:47 PM, michael mccune mailto:m...@redhat.com>> wrote:
i am not convinced that we would ever need to have a standard on how
these names are chosen for the header values, or if we would even
need to have header names
ributors also want openstack to be "good" but they also have
deadlines to meet internally. Having a freeze upstream for stabilization
is going to put downstream development into overdrive, no doubt. That
would be a poor precedent to have set given where the bulk of
contributions com
_
logic inside create_resource logic for this to work. Its a hack, but
complies with HTTP standard.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
ainers will
always be in bays (from what I understand of the Magnum architecture,
this is indeed true) then nesting them makes sense.
Of course, it's a big change and will have to be communicated to users &
client libraries, probabl
https://review.openstack.org/#/c/153771/
[3] https://review.openstack.org/#/c/221648/1
[4] http://jinja.pocoo.org/
--
Regards,
Sergey.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
ht
On 01/12/2016 10:50 AM, Jiri Tomasek wrote:
On 01/12/2016 04:22 PM, Ryan Brown wrote:
On 01/12/2016 06:52 AM, Jiri Tomasek wrote:
On 01/11/2016 04:51 PM, Dan Prince wrote:
Background info:
We've got a problem in TripleO at the moment where many of our
workflows can be driven by the co
, that's right) notification options.
I am about to implement your nodes workflow in the GUI to test how it
works.
Jirka
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Maili
.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Mailing List (not
___
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ryan Brown / Senior Software Engineer, Openstack / R
/lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/
s.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+1
+1
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Mailing List (not for
tions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenSt
x27;ll cut all the logfiles down to size when the total size of your
log directory exceeds 1 GB. I have it set to run every 3 hours on my vms.
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Develo
Regards,
Tan
1: http://jsonpatch.com/
2:
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Devel
't really scale, but
namespacing will because we *already* namespace projects.
Your thoughts?
Cheers,
Thomas Goirand (zigo)
P.S: It wasn't the point of this message, but do we have a fix for
designateclient? It'd be nice to have this fixed before Liberty is out.
--
Ryan Brown
xc
\- v1
|- client
|- resources
|- events
|- services
I think versioning the public API is the way to go, since it will make
it easier to maintain backwards compatibility while new needs/uses evolve.
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
ibrary like tooz will be useful for heat.
A lot of boiler plate needed for locking and running centralized tasks
(such as timeout) will not be needed in heat. Given that we are moving
towards distribution of tasks and horizontal scaling is preferred, it
will be advantageous to use them.
Please sha
e
not affected. The nova apis can then be deprecated in slow time.
Anybody else think this could be useful?
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Maili
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Mailin
On 08/27/2015 11:28 PM, Chen, Wei D wrote:
>
> I agree that return 400 is good idea, thus client user would know what
> happened.
>
+1, I think a 400 is the sensible choice here. It'd be much more likely
to help devs catch their errors .
--
Ryan Brown / Software Engineer, Op
d into
someone else's infrastructure? Or standalone templates for stuff like
"here, instant mongodb cluster"?
Also, the obvious question of the central repo is "how does reviewing
work?" are heat cores expect
is should be a 400. It would also be acceptable (though less
preferable) to ignore any body on GET requests and execute the request
as normal.
> Best,
> -jay
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
__
Op
believe the current behavior is correct. The idea is to be able to
> edit a template, and then validate it on all the clouds you want to push
> it to.
Maybe it would be valuable to distinguish (when failing a validation)
between "Resource Foo::Bar is no
est minimum, trove uses nova, glance uses swift, etc) which would
make darn near every service a module. It doesn't seem to be a valuable
distinction, and I know that within the heat team, we say "service".
Do operators, users, or developers find this distinction useful? Calling
everyt
format and provide feedback to
help it work for their use case as well.
[1]: https://review.openstack.org/#/c/186436/
[2]: https://review.openstack.org/#/c/186555/
[3]: https://review.openstack.org/#/c/185822/
> ...[snip]...
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
_
ging for OpenStack" as "messaging
service for OpenStack tenants" not "messaging for OpenStack internally".
Good catch Clint,
Ryan
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
__
OpenSta
Zaqar provides an option to use Redis as a backend, and Zaqar provides
pubsub messaging.
On 05/23/2015 03:09 PM, Todd Crane wrote:
> Does anybody know of a way (either current projects or future plans)
> to use Redis PubSub as the messaging system for OpenStack?
>
> -Todd
--
t, participated in
> sessions and that are committed on making this happen.
>
> Lets now make it happen,
> Flavio
Thanks for the mail Flavio,
Ryan
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
__
On 05/11/2015 04:18 PM, Everett Toews wrote:
> I would like to propose Michael McCune (elmiko) as an API Working Group core.
Not core, but +1 from me!
--
Ryan Brown / Software Engineer, Openstack / Red Hat,
or
> creating and maintaining our own special rules, we just use the
> rules that exist.
> So yeah, my argument basically comes down to: There's a spec, let's
> follow it as much as possible.
>
>> p.s. And, yes, Chris, I definitely do see your side of the coin on
>>
one cause, so they are specific.
>
> Yes, agreed.
>
> I think Sean makes an excellent point that if you have >1 condition that
> results in a 403 Forbidden, it actually does not make things more
> expressive. It actually just means both humans and clients need to now
> delve deepe
it is trying to be magical rather than logical. I imagine there are
> others who are also nervous about that.
I don't think it tries to be "magical", it tries to be developer
friendly by default, and lets your VCS handle versioning your
dependencies. It just so happens version contr
, with the topic tag "[tc]", instead?
>
> Doug
>
> [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
>
I'd much prefer it on openstack-dev with the [tc] tag, I wasn't aware
the agenda was emailed out at all.
--
Ryan Brown / Software Engi
d it's ok if there's some nominal level of
somewhat unhelpful reviews so long as, when possible, we try to teach
those reviewers how they can be more helpful.
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
_
x27;m guessing this would be around the 12:00-13:00 UTC
> range.
>
> we would still love to hear more thoughts from folks in Australia/Asia
> time zones to see if we can arrive at something that will accommodate
> the most number of interested parties.
>
> regards,
> mike
sers don't know a
>> service is available, its hard for them to use it. Even with the
>> most simple UI of Create/Delete/List queues, discovery is handled.
Absolutely agreed. Especially in a service like Zaqar where the vast
majority of usage isn't by humans in a web in
l cloud tenants. This enables great stuff like
cross-tenant messaging, better physical resource utilization in
sparse-tenant cases, etc.
As someone who wants to adopt Zaqar, I'd really like to see it continue
as a project because it provides things
#x27;re absolutely correct, here's a quick snippet to get the version as
a string:
import pkg_resources
pkg_resources.get_distribution('nova').version
Where, of course, s/nova/any-package-name/
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
__
t;>> >
>>> > $ time openstack -h
>>> >
>>> > real0m2.491s
>>> > user0m2.378s
>>> > sys 0m0.111s
>>>
>>>
>>> pbr should be snappy - taking 100ms to get the version is wrong.
>>
>>
quantifiable as metrics
(num-replaced-resources on an update action) and that should be
user-visible (update is complete, or autoscaling actions taken).
>> Is there a way for users as-is to view those raw notifications, not just
>> the indexed k/v pairs?
>
> In StackTach.v3 we shi
ected stack ID, meaning there's not much to slice on
in Ceilometer.
This could be extended to richer JSON events that include the stack,
resources affected in the update, stats like "num-deleted-resources" or
"num-replaced-resources", autoscaling actions, and info about stack
related note, I can’t make it to tomorrow’s meeting. Can someone
> else please #startmeeting?
>
> Thanks, Everett
+1 for moving to only 16:00UTC
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
__
Open
dependency, or at
>> least move it closer to where it is needed?
>
> pyyaml will use libyaml to c accelerate yaml parsing. It's not strictly
> required, but there may be performance implications.
Distutils stuff can be added later.
>
> Best regards,
> Pavlo Shchelokovskyy
If we only do 1 and 2, not 3 we get all the benefits (separate package,
streamlined publishing, etc) without having to deal with the submodule
disadvantages I (and you) mentioned earlier.
--
Ryan Brown / Software E
to merge
> and need manual rebasing.
>
> For companies with internal forks/patches - those will likely all have
> to be redone too..
Ooof, that's huge. If we can configure it to be less aggressive I love
the *idea* of having everything formatted semantically, but that's a
p
y to forget "submodule pull"
and end up missing tests. This is, of course, in addition to your (all
valid) reasons for avoiding submodules.
>
> What do you think about it? Please share your comments.
>
> Best regards,
>
> Pavlo Shchelokovskyy Software Engineer Mi
he API WG to identify places in our
> API implementations that are not following "the rules", yes.
>
> I think paraphrasing particular parts of RFCs would be my preference,
> along with examples of bad or incorrect usage.
>
> Best,
> -jay
+1 I think the way to go wou
;
>
>
> --
> Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com <http://www.mirantis.com/>
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
>
>
openstack-dev
>
>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinf
n statement to <= 140 chars at the outset, we’d be losing
> valuable information that’s vital in communicating our intent. And if we
> can’t fully communicate our intent in a mission statement then it
> doesn’
Oops, sent this to openstack@ not openstack-dev@.
On 02/10/2015 04:52 PM, Ryan Brown wrote:
> Heat team,
>
> After looking at Zane's prototype[1] and the ML threads on SyncPoint, I
> thought it'd be helpful to make a model of *just* the logic around
> resource locki
stions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
nifying
discussion around them.
I think a spec being merged/unmerged is a good enough distinction for
the draft status of a spec and wouldn't be improved by having a
draft/final repo split.
___
> O
nfusion, we could use BROKEN. ;)
> Tomas
>
> [1]:
> http://specs.openstack.org/openstack/heat-specs/specs/juno/stack-breakpoint.html
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.op
tatistic avg \
> ...
> --query metadata.user_metedata.my_server_group=foobar
>
> This approach is of course predicated on the there being some natural
> grouping relation between instances in your environment.
>
> Cheers,
> Eoghan
>
>
>>
penStack projects, so common patterns can be
reused as oslo libs
Of course, the Flask community seems larger (though the average flask
project seems pretty small).
I'm not sure what determines "production readiness", but it seems to me
like Fuel developers fall more in Pecan&#
se of singleton tasks
> like timeout checking, that might work out nicely.
+1
Using a hash ring is a great way to shard tasks. I think the most
sensible way to add this would be to make timeout polling a
responsibility of the Observer instead of the engine.
--
Ryan Brown / Software Enginee
On 11/12/2014 07:50 AM, Zane Bitter wrote:
> On 12/11/14 06:48, Angus Salkeld wrote:
>> (it's nice that there would be a consistent user experience
>> between these projects -mistral/heat/murano).
>
> It's actually potentially horrible, because you introduce potential
> quoting issues when you e
embed-ability for would be better served either by something like yaql,
or by making vendored HOT functions possible.
Vendored HOT would look something like "X-Vendor::YourNamespace" and
functions could be managed similarly to resource plugins (stevedore).
It's a very rough i
; Regards,
> Thomas
>
> [1]
> https://github.com/openstack/heat-templates/blob/master/hot/software-config/elements/README.rst
> [2]
> https://github.com/openstack/heat-templates/tree/master/hot/software-config/example-templates/cirros-example
>
&
On 09/16/2014 09:49 AM, Ryan Brown wrote:.
>
> (From Zane's other message)
>>
>> I think the first supported release is probably the right information
> to add.
>>
>
> I feel like for anything with nonzero upgrade effort (and upgrading your
> openstac
t;
>>> We do the same thing with HOT's internals, so why not also
>>> do the standard library this way?
>>
>> The current process for HOT is for every OpenStack development cycle
>> (Juno is the first to use this) to give i
gi-bin/mailman/listinfo/openstack-dev
>
Also if you don't feel existing dashboards scratch your project's
particular itch, there's always gerrit-dash-creator[1] to help you make
one that fits your needs.
[1]: https://github.com/stackforge/gerrit-dash-creator
--
Ryan Brown /
security work than
just storing code and test results.
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s are 100% public so
no privacy headaches. Many folks using OpenStack's ZNCaaS would be in
other channels (or at least would receive private messages) and
OpenStack probably shouldn't take responsibility for keeping all those safe.
Just my 0.02 USD.
--
Ryan Brown / Software Engineer, Open
On 08/27/2014 12:15 PM, Kurt Griffiths wrote:
> On 8/25/14, 9:50 AM, "Ryan Brown" 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 t
ing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack
formerly known as
marconi).
[1]:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lis
On 08/05/2014 09:27 AM, Sylvain Bauza wrote:
>
> Le 05/08/2014 13:06, Ryan Brown a écrit :
> -1 to this as git-review default behaviour. Ideally, branches should be
> identical in between Gerrit and local Git.
Probably not as default behaviour (people who don't want that
> uploaded to Gerrit as _one_ change request;
>
> master: M---N-O-...
> \\\E* <= uploaded
> feature: A-B-...-C-D-...-E
>
>
+1, this is definitely a feature I'd want to see.
Currently I run two branches "bug/LPBUG#-local" and &quo
x27;t see any benefit here.
Agreed
I'd actually be in favor of the change from rsrc->resource, I feel like
rsrc is a pretty opaque abbreviation.
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
___
OpenStack-dev mailing l
80 matches
Mail list logo
