Re: [openstack-dev] [TripleO] Core reviewer update proposal
On Tuesday 05 of May 2015 07:57:46 James Slagle wrote: > Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO > Core. > > Giulio has been an active member of our community for a while. He > worked on the HA implementation in the elements and recently has been > making a lot of valuable contributions and reviews related to puppet > in the manifests, heat templates, ceph, and HA. > > Steve Hardy has been instrumental in providing a lot of Heat domain > knowledge to TripleO and his reviews and guidance have been very > beneficial to a lot of the template refactoring. He's also been > reviewing and contributing in other TripleO projects besides just the > templates, and has shown a solid understanding of TripleO overall. > > 180 day stats: > | gfidente | 2080 42 166 0 079.8% | > > 16 ( 7.7%) | > > | shardy | 2060 27 179 0 086.9% | > > 16 ( 7.8%) | > > TripleO cores, please respond with +1/-1 votes and any > comments/objections within 1 week. > +1 > Giulio and Steve, also please do let me know if you'd like to serve on > the TripleO core team if there are no objections. > > I'd also like to give a heads-up to the following folks whose review > > activity is very low for the last 90 days: > | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) > | | > | > |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) > || > | > | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) > | | > | > | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) > | | > | jonpaul-sullivan **| > > Helping out with reviewing contributions is one of the best ways we > can make good forward progress in TripleO. All of the above folks are > valued reviewers and we'd love to see you review more submissions. If > you feel that your focus has shifted away from TripleO and you'd no > longer like to serve on the core team, please let me know. > > I also plan to remove Alexis Lee from core, who previously has > expressed that he'd be stepping away from TripleO for a while. Alexis, > thank you for reviews and contributions! Petr Blaho __ 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
Re: [openstack-dev] [TripleO] Change of meeting time
On Wed, Aug 20, 2014 at 05:30:25AM -0400, Dougal Matthews wrote: > - Original Message - > > From: "Derek Higgins" > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Sent: Wednesday, 20 August, 2014 10:15:51 AM > > Subject: Re: [openstack-dev] [TripleO] Change of meeting time > > > > On 24/05/14 01:21, James Polley wrote: > > > Following a lengthy discussion under the subject "Alternating meeting > > > tmie for more TZ friendliness", the TripleO meeting now alternates > > > between Tuesday 1900UTC (the former time) and Wednesday 0700UTC, for > > > better coverage across Australia, India, China, Japan, and the other > > > parts of the world that found it impossible to get to our previous > > > meeting time. > > > > Raising a point that came up on this morning's irc meeting > > > > A lot (most?) of the people at this morning's meeting were based in > > western Europe, getting up earlier then usual for the meeting (me > > included), When daylight saving kicks in it might push them passed the > > threshold, would an hour later (0800 UTC) work better for people or is > > the current time what fits best? > > > > I'll try to make the meeting regardless if its moved or not but an hour > > later would certainly make it a little more palatable. > > +1, I don't have a strong preference, but an hour later would make it a > bit easier, particularly when DST kicks in. > > Dougal > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I prefer later time for Wednesday too. -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Specs and approvals
On Tue, Aug 19, 2014 at 09:31:48PM +1200, Robert Collins wrote: > Hey everybody - https://wiki.openstack.org/wiki/TripleO/SpecReviews > seems pretty sane as we discussed at the last TripleO IRC meeting. > > I'd like to propose that we adopt it with the following tweak: > > 19:46:34 so I propose that +2 on a spec is a commitment to > review it over-and-above the core review responsibilities > 19:47:05 if its not important enough for a reviewer to do > that thats a pretty strong signal > 19:47:06 lifeless: +1, I thought we already agreed to that > at the meetup > 19:47:17 yea, sounds fine to me > 19:47:20 +1 > 19:47:30 dprince: it wasn't clear whether it was > part-of-responsibility, or additive, I'm proposing we make it clearly > additive > 19:47:52 and separately I think we need to make surfacing > reviews-for-themes a lot better > > That is - +1 on a spec review is 'sure, I like it', +2 is specifically > "I will review this *over and above* my core commitment" - the goal > here is to have some very gentle choke on concurrent WIP without > needing the transition to a managed pull workflow that Nova are > discussing - which we didn't have much support for during the meeting. > > Obviously, any core can -2 for any of the usual reasons - this motion > is about opening up +A to the whole Tripleo core team on specs. > > Reviewers, and other interested kibbitzers, please +1 / -1 as you feel fit :) > > -Rob > I like it, +1. > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO][Tuskar] REST API spec for Juno questions
Hi all, I am working on API endpoints for Tuskar according to https://github.com/openstack/tripleo-specs/blob/master/specs/juno/tripleo-juno-tuskar-rest-api.rst and I found some inconsistencies. On following lines I will present what I think are mistakes or I do not understand well. Please, correct me if I am wrong. Then I am ok to write patch for that spec. 1) UUID vs. id. I can see usage of UUIDs in urls (https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L107) and UUID is referenced in condition for 404 HTTP status (https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L125). On the other hand we have id in returned json for plan (https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L148). The same applies for roles and its UUIDs or ids. The problem I am pointing at is not in format of value but in its name. I am convinced that these should be consistent and we should use UUIDs. 2) Request Data when adding role to plan. According to https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L376 there should be name and version of the role but json example has only id value (https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L382-L384). I understand that that json code is just an example but I was confused by differences between words describing data and example. I can see from json representation of roles list (https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L508-L527) that role can be identified both by UUID/id and combination of name+version. >From spec for DELETE role from plan (https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L405) I can tell that we probably will be using name+version identifier to know which role I want to add to plan so example mentioned above is just missing name and version attributes. Am I correct with this? 3) /v2/clouds in href for plan This is probably remnant from previous versions of spec. We have /v2/clouds where we probably should have /v2/plans (https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L182). 4) Links to roles from plan json We have a link for each role in plan that points to url like /v2/roles/:role_uuid (https://github.com/openstack/tripleo-specs/blame/master/specs/juno/tripleo-juno-tuskar-rest-api.rst#L158). But we do not have an API endpoint returning single role. We should either remove these links to single role or add GET /v2/roles/:role_uuid endpoint and add this kind of links to list of roles too. I proposed solutions to points 1, 2 and 3 in https://review.openstack.org/#/c/109040/. Thanks for reading this. I am looking for your input. -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] rules for removal
On Fri, Jun 20, 2014 at 11:33:30AM -0700, Joe Gordon wrote: > > > > On Fri, Jun 20, 2014 at 11:07 AM, Sean Dague wrote: > > After seeing a bunch of code changes to enforce new hacking rules, I'd > like to propose dropping some of the rules we have. The overall patch > series is here - > https://review.openstack.org/#/q/status:open+project:openstack-dev/ > hacking+branch:master+topic:be_less_silly,n,z > > H402 - 1 line doc strings should end in punctuation. The real statement > is this should be a summary sentence. A sentence is not just a set of > words that end in a period. Squirel fast bob. It's something deeper. > This rule thus isn't really semantically useful, especially when you are > talking about at 69 character maximum (79 - 4 space indent - 6 quote > characters). > > > Thoughts on removing all pep257 (http://legacy.python.org/dev/peps/pep-0257/) > things from hacking? If projects would still like to enforce it there is a > flake8 extension for pep257 itself. > > +1 - why to invent wheel again? > > H803 - First line of a commit message must *not* end in a period. This > was mostly a response to an unreasonable core reviewer that was -1ing > people for not having periods. I think any core reviewer that -1s for > this either way should be thrown off the island, or at least made fun > of, a lot. Again, the clarity of a commit message is not made or lost by > the lack or existence of a period at the end of the first line. > > > ++ for removing this, in general the git based rules are funny to enforce. As > you can run 'tox -epep8' before a commit and everything will pass, then you > write your commit message and now it will fail. > +1 I have seen exactly this to happen. > > > H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty, > our tree. This biggest issue here is it's built in a world where there > was only 1 viable python version, 2.7. Python's stdlib is actually > pretty dynamic and grows over time. As we embrace more python 3, and as > distros start to make python3 be front and center, what does this even > mean? The current enforcement can't pass on both python2 and python3 at > the same time in many cases because of that. > > > ++ Oh Python 2 vs. 3 > > For this one I think we should leave the rule in HACKING.rst but explicitly > document it as a recommendation, and that python2 vs python3 makes this > unenforceable. > +1 I like the idea of these unnenforced recommendations. HACKING.rst as a guide and hacking tool as strict enforcer for guide's subset. > > > We have to remember we're all humans, and it's ok to have grey space. > Like in 305, you *should* group the libraries if you can, but stuff like > that should be labeled as 'nit' in the review, and only ask the author > to respin it if there are other more serious issues to be handled. > > Let's optimize a little more for fun, and stop throwing -1s for silly > things. :) > > -Sean > > -- > Sean Dague > http://dague.net > > > ___ > OpenStack-dev mailing 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.org/cgi-bin/mailman/listinfo/openstack-dev -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?
On Thu, May 29, 2014 at 12:25:02PM -0400, Anita Kuno wrote: > As I was reviewing this patch today: > https://review.openstack.org/#/c/96160/ > > It occurred to me that the tuskar project is part of the tripleo > program: > http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n247 > > I wondered if business, including bots posting to irc for #tuskar is > best conducted in the #tripleo channel. I spoke with Chris Jones in > #tripleo and he said the topic hadn't come up before. He asked me if I > wanted to kick off the email thread, so here we are. > > Should #tuskar business be conducted in the #tripleo channel? > > Thanks, > Anita. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi, we already have gerritbot posting to #tripleo channel w/r/t patches in tuskar (as for all tripleo repos). And I think that we should talk on one common channel, ie #tripleo. +1 for abandoning #tuskar channel. -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][design] review based conceptual design process
On Wed, Apr 16, 2014 at 06:44:28AM +1200, Robert Collins wrote: > I've been watching the nova process, and I think its working out well > - it certainly addresses: > - making design work visible > - being able to tell who has had input > - and providing clear feedback to the designers > > I'd like to do the same thing for TripleO this cycle.. > > I'm thinking we can just add docs to incubator, since thats already a > repository separate to our production code - what do folk think? > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1 for tripleo-spec repo I like the idea of dedicated repo for design review process. -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh
On Mon, Apr 14, 2014 at 07:24:57PM +0100, Chris Jones wrote: > Hi > > Apart from special cases like the ramdisk's /init, which is a script that > needs > to run in busybox's shell, everything should be using bash. There's no point > us > tying ourselves in knots trying to achieve POSIX compliance for the sake of > it, > when bashisms are super useful. +1, especially for "tying ourselves in knots trying to achieve POSIX compliance for the sake of it" > > Cheers, > > Chris > > > On 14 April 2014 17:26, Ben Nemec wrote: > > tldr: I propose we use bash explicitly for all diskimage-builder scripts > (at least for the short-term - see details below). > > This is something that was raised on my linting changes to enable set -o > pipefail. That is a bash-ism, so it could break in the diskimage-builder > scripts that are run using /bin/sh. Two possible fixes for that: switch > to > /bin/bash, or don't use -o pipefail > > But I think this raises a bigger question - does diskimage-builder require > bash? If so, I think we should just add a rule to enforce that /bin/bash > is the shell used for everything. I know we have a bunch of bash-isms in > the code already, so at least in the short-term I think this is probably > the way to go, so we can get the benefits of things like -o pipefail and > lose the ambiguity we have right now. For reference, a quick grep of the > diskimage-builder source shows we have 150 scripts using bash explicitly > and only 24 that are plain sh, so making the code truly shell-agnostic is > likely to be a significant amount of work. > > In the long run it might be nice to have cross-shell compatibility, but if > we're going to do that I think we need a couple of things: 1) Someone to > do > the work (I don't have a particular need to run dib in not-bash, so I'm > not > signing up for that :-) 2) Testing in other shells - obviously just > changing /bin/bash to /bin/sh doesn't mean we actually support anything > but > bash. We really need to be gating on other shells if we're going to make > a > significant effort to support them. It's not good to ask reviewers to try > to catch every bash-ism proposed in a change. This also relates to some > of > the unit testing work that is going on right now too - if we had better > unit test coverage of the scripts we would be able to do this more easily. > > Thoughts? > > Thanks. > > -Ben > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Cheers, > > Chris > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Default paths in os-*-config projects
On Mon, Apr 14, 2014 at 06:30:59PM -0700, Clint Byrum wrote: > Excerpts from Ben Nemec's message of 2014-04-14 15:41:23 -0700: > > Right now the os-*-config projects default to looking for their files in > > /opt/stack, with an override env var provided for other locations. For > > packaging purposes it would be nice if they defaulted to a more > > FHS-compliant location like /var/lib. For devtest we could either > > override the env var or simply install the appropriate files to /var/lib. > > > > This was discussed briefly in IRC and everyone seemed to be onboard with > > the change, but Robert wanted to run it by the list before we make any > > changes. If anyone objects to changing the default, please reply here. > > I'll take silence as agreement with the move. :-) > > > > +1 from me for doing FHS compliance. :) > > /var/lib is not actually FHS compliant as it is for "Variable state > information". os-collect-config does have such things, and does use > /var/lib. But os-refresh-config reads executables and os-apply-config > reads templates, neither of which will ever be "variable state > information". > > /usr/share would be the right place, as it is "Architecture independent > data". I suppose if somebody wants to compile a C program as an o-r-c > script we could rethink that, but I'd just suggest they drop it in a bin > dir and exec it from a one line shell script in the /usr/share. > > So anyway, I suggest: > > /usr/share/os-apply-config/templates > /usr/share/os-refresh-config/scripts +1 for /usr/share/ > > With the usual hierarchy underneath. > > We'll need to continue to support the non-FHS paths for at least a few > releases as well. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API
On Mon, Mar 03, 2014 at 09:19:34AM +0100, Radomir Dopieralski wrote: > On 27/02/14 11:52, Petr Blaho wrote: > > > I agree with you w/r/t to indirection when accessing data but I like the > > idea that when I look at json repsonse I see what type of resource it > > is. That wrapper element describes it. And I do not need to know what > > request (url, service, GET or POST...) triggered that output. > > That's data denormalization. What do you then do when the two sources of > information don't agree? Also, do you actually need the json at all > without knowing where it came from (not just from which api call, but > which system and at what time)? I can't imagine such a situation. Yeah, I agree with you that not wrapped json data is better solution. I just liked how wrapped data looks. > > Finally, when you need to save a whole lot of json outputs and need to > know where they come from, you traditionally put that information in the > file name, no? > > -- > Radomir Dopieralski > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev My concern is that it looks like OpenStack does not have a "proper" way how to format output json in APIs and it is on behalf of each project. -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API
On Wed, Feb 26, 2014 at 02:17:53PM -0500, Jay Dobies wrote:
> This is a new concept to me in JSON, I've never heard of a wrapper
> element like that being called a namespace.
I named it "namespace" in my email. It is not any kind of formal or
standard naming. "Wrapper element" is better name for this... wrapper
element :-)
>
> My first impression is that is looks like cruft. If there's nothing else
> at the root of the JSON document besides the namespace, all it means is
> that every time I go to access relevant data I have an extra layer of
> indirection. Something like:
>
> volume_wrapper = get_volume(url)
> volume = volume_wrapper['volume']
>
> or
>
> volume = get_volume(url)
> name = volume['volume']['name']
I agree with you w/r/t to indirection when accessing data but I like the
idea that when I look at json repsonse I see what type of resource it
is. That wrapper element describes it. And I do not need to know what
request (url, service, GET or POST...) triggered that output.
>
> If we ever forsee an aggregate API, I can see some value in it. For
> instance, a single call that aggregates a volume with some relevant
> metrics from ceilometer. In that case, I could see leaving both distinct
> data sets separate at the root with some form of namespace rather than
> attempting to merge the data.
>
> Even in that case, I think it'd be up to the aggregate API to introduce
> that.
>
> Looking at api.openstack.org, there doesn't appear to be any high level
> resource get that would aggregate the different subcollections.
>
> For instance, {tenant_id}/volumes stuffs everything inside of an element
> called "volumes". {tenant_id}/types stuffs everything inside of an
> element called volume_types. If a call to {tenant_id} aggregated both of
> those, then I can see leaving the namespace in on the single ID look ups
> for consistency (even if it's redundant). However, the API doesn't
> appear to support that, so just looking at the examples given it looks
> like an added layer of depth that carries no extra information and makes
> using the returned result a bit awkward IMO.
>
I did not think about aggregate APIs before... interesting idea...
>
> On 02/26/2014 01:38 PM, Petr Blaho wrote:
> > Hi,
> >
> > I am wondering what is the OpenStack way of returning json from
> > apiclient.
> >
> > I have got 2 different JSON response examples from
> > http://api.openstack.org/:
> >
> > json output with namespace:
> > {
> >"volume":
> >{
> > "status":"available",
> > "availability_zone":"nova",
> > "id":"5aa119a8-d25b-45a7-8d1b-88e127885635",
> > "name":"vol-002",
> > "volume_type":"None",
> > "metadata":{
> >"contents":"not junk"
> > }
> >}
> > }
> > (example for GET 'v2/{tenant_id}/volumes/{volume_id}' of Block Storage API
> > v2.0 taken from
> > http://api.openstack.org/api-ref-blockstorage.html [most values ommited])
> >
> > json output without namespace:
> > {
> >"alarm_actions": [
> >"http://site:8000/alarm";
> > ],
> > "alarm_id": null,
> > "combination_rule": null,
> > "description": "An alarm",
> > "enabled": true,
> > "type": "threshold",
> > "user_id": "c96c887c216949acbdfbd8b494863567"
> > }
> > (example for GET 'v2/alarms/{alarm_id}' of Telemetry API v2.0 taken from
> > http://api.openstack.org/api-ref-telemetry.html [most values ommited])
> >
> > Tuskar API now uses "without namespace" variant.
> >
> > By looking at API docs at http://api.openstack.org/ I can say that
> > projects use both ways, altought what I would describe as "nicer API"
> > uses namespaced variant.
> >
> > So, returning to my question, does OpenStack have some rules what
> > format of JSON (namespaced or not) should APIs return?
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Petr Blaho, pbl...@redhat.com
Software Engineer
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API
Hi,
I am wondering what is the OpenStack way of returning json from
apiclient.
I have got 2 different JSON response examples from http://api.openstack.org/:
json output with namespace:
{
"volume":
{
"status":"available",
"availability_zone":"nova",
"id":"5aa119a8-d25b-45a7-8d1b-88e127885635",
"name":"vol-002",
"volume_type":"None",
"metadata":{
"contents":"not junk"
}
}
}
(example for GET 'v2/{tenant_id}/volumes/{volume_id}' of Block Storage API v2.0
taken from
http://api.openstack.org/api-ref-blockstorage.html [most values ommited])
json output without namespace:
{
"alarm_actions": [
"http://site:8000/alarm";
],
"alarm_id": null,
"combination_rule": null,
"description": "An alarm",
"enabled": true,
"type": "threshold",
"user_id": "c96c887c216949acbdfbd8b494863567"
}
(example for GET 'v2/alarms/{alarm_id}' of Telemetry API v2.0 taken from
http://api.openstack.org/api-ref-telemetry.html [most values ommited])
Tuskar API now uses "without namespace" variant.
By looking at API docs at http://api.openstack.org/ I can say that
projects use both ways, altought what I would describe as "nicer API"
uses namespaced variant.
So, returning to my question, does OpenStack have some rules what
format of JSON (namespaced or not) should APIs return?
--
Petr Blaho, pbl...@redhat.com
Software Engineer
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API
On Fri, Feb 21, 2014 at 10:24:24AM +0100, Tomas Sedovic wrote: > On 20/02/14 16:24, Imre Farkas wrote: > > On 02/20/2014 03:57 PM, Tomas Sedovic wrote: > >> On 20/02/14 15:41, Radomir Dopieralski wrote: > >>> On 20/02/14 15:00, Tomas Sedovic wrote: > >>> > >>>> Are we even sure we need to store the passwords in the first place? All > >>>> this encryption talk seems very premature to me. > >>> > >>> How are you going to redeploy without them? > >>> > >> > >> What do you mean by redeploy? > >> > >> 1. Deploy a brand new overcloud, overwriting the old one > >> 2. Updating the services in the existing overcloud (i.e. image updates) > >> 3. Adding new machines to the existing overcloud > >> 4. Autoscaling > >> 5. Something else > >> 6. All of the above > >> > >> I'd guess each of these have different password workflow requirements. > > > > I am not sure if all these use cases have different password > > requirement. If you check devtest, no matter whether you are creating or > > just updating your overcloud, all the parameters have to be provided for > > the heat template: > > https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 > > > > > > I would rather not require the user to enter 5/10/15 different passwords > > every time Tuskar updates the stack. I think it's much better to > > autogenerate the passwords for the first time, provide an option to > > override them, then save and encrypt them in Tuskar. So +1 for designing > > a proper system for storing the passwords. > > Well if that is the case and we can't change the templates/heat to > change that, the secrets should be put in Keystone or at least go > through Keystone. Or use Barbican or whatever. > > We shouldn't be implementing crypto in Tuskar. +1 > > > > > Imre > > > > ___ > > OpenStack-dev mailing 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.org/cgi-bin/mailman/listinfo/openstack-dev -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] RFC: Freeze deps versions in requirements
On Fri, Oct 18, 2013 at 11:30:48AM -0400, Sean Dague wrote: > On 10/17/2013 08:12 AM, Petr Blaho wrote: > > Hi all, > > > > this is probably 3rd or 4th time in quite short time when we were bitten > > by new version of some out dependencies. > > > > Last one (https://review.openstack.org/#/c/52327/3) was about WSME > > released version 0.5b6 and our tests fail. > > > > I do not want to argue if problem is on tuskar side (probably tuskar is > > to blame according to what jistr found out) or WSME but I think > > we should discuss possibility of freezing versions in our dependencies > > definitions and once in a time check for new versions of deps and do > > update as a separate task. > > > > Current state of having open version constraints like WSME<=0.5b5 leads > > to occasional (or as I see quite frequent) jenkins job failures (as jenkins > > use clean venv for instalation - devs can have older one so they can > > miss failure with new version of dep) and these "sudden" failures force > > us to investigate and divert from planned tasks etc... > > > > I think that having regular "update deps" task can lead to better time > > management and having less "sudden" jenkins failures will be benefical > > to developers' health :-) > > > > Please, tell me if I am missing some obvious problem with freezing dep > > versions and/or regular update task and if I miss a good side of these > > "sudden version strikes" too. > > Most of this has already been addressed in the thread. There is a huge > trade of here, freezing requirements in the short term makes everything > work, in the long term, it causes huge pain. Just look at SQLA pin at <= > 0.7.99, which has gone far too long without getting resolved, and has > all the distros carrying patches to work around it (now why none of them > have contributed those back is another question). > > Getting to a single global requirements list this summer took 3 weeks of > cross team coordination, because of pinning. Having to unwind > coordinated patches like that is lots of fun, let me tell you. :) And > while the result isn't perfect, it's so much better than the random gate > wedges we were regularly getting that were actually unsolvable through > normal process fixes. > > If you are a project with tempest integration, then you actually get a > code voice in global requirements bumps, because a g-r change can't land > without passing tempest / devstack tests. So integrated projects take > note, there are lots of reasons you want to have good tempest tests, and > protecting yourself from requirements changes is one of those (wouldn't > help in the tuscar case, as that's only got unit tests). > > So, I think we largely need to just take our lumps realizing that we > don't have tight control over the python world, and it's better to react > quickly, then to hide behind a pin, and not realize that we're massively > broken with the latest versions of libraries out there. > > That being said, because WSME is in stackforge, I think we could > actually do better than just take our lumps. But I think that's for > discussing at the requirements session at summit. > > -Sean > > -- > Sean Dague > http://dague.net > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thank you all for responses as these helped me to understand this topic more. I am glad I now know about strugle with frozen deps w/r/t packaging to distros. -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] RFC: Freeze deps versions in requirements
Hi all, this is probably 3rd or 4th time in quite short time when we were bitten by new version of some out dependencies. Last one (https://review.openstack.org/#/c/52327/3) was about WSME released version 0.5b6 and our tests fail. I do not want to argue if problem is on tuskar side (probably tuskar is to blame according to what jistr found out) or WSME but I think we should discuss possibility of freezing versions in our dependencies definitions and once in a time check for new versions of deps and do update as a separate task. Current state of having open version constraints like WSME<=0.5b5 leads to occasional (or as I see quite frequent) jenkins job failures (as jenkins use clean venv for instalation - devs can have older one so they can miss failure with new version of dep) and these "sudden" failures force us to investigate and divert from planned tasks etc... I think that having regular "update deps" task can lead to better time management and having less "sudden" jenkins failures will be benefical to developers' health :-) Please, tell me if I am missing some obvious problem with freezing dep versions and/or regular update task and if I miss a good side of these "sudden version strikes" too. Thanks -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TRIPLEO] tripleo-core update october
On Tue, Oct 08, 2013 at 02:31:34PM +0200, Jaromir Coufal wrote: > Hi Chris, > > On 2013/08/10 13:13, Chris Jones wrote: > > Hi > > On 8 October 2013 11:59, Jaromir Coufal wrote: > > * Example: It doesn't make sense, that someone who is > core-reviewer > based on image-builder is able to give +2 on UI or CLI code and > vice-versa. > > > I'm not sure this is a technical problem as much as a social problem - if > someone isn't able to give a good review (be it -1/+1 or +2) on a > particular change, they should just not review it, regardless of which > part > of the project it relates to. > > I completely agree on this point. It depends on people's judgement. > > Question is if we will depend only on this judgment or we help that with > splitting reviewers based on projects. I believe that the split can help us. > Anyway, it is just proposal it depends what others think about that. > > > I'm a tripleo core reviewer, but I have been ignoring the tuskar reviews > until I have had some time to play with it and get a feel for the code. > You > can argue that I therefore shouldn't even have the power to give a +2 on > tuskar code, but I would note that before Robert added me to core he > wasn't > simply watching the quantity of my reviews, he was also giving me feedback > on areas I was going wrong. I would imagine that if I was wildly throwing > around inappropriate reviews on code I wasn't qualified to review, he > would > give me feedback on that too and ultimately remove me as a reviewer. > > Well it depends on the approach, if we think first or second way. I might > argue > that you shouldn't have the +2 power for Tuskar until you have bigger > contribution on Tuskar code (reviews or patches or ...). Just for me it sounds > logical, because you are not that close to it and you are not familiar with > all > the background there. > > If somebody will be contributing regularly there, he can become core-reviewer > on that project as well. > > If you did bad code reviews on Tuskar and you were removed the 'core-' status, > you still can do excellent job on other TripleO projects, so why to lose it at > all of them? > > Let me give one example: > There is tuskar-client which is very important project and there is not that > big activity as in other projects. There are people who actually wrote the > whole code and based on the amount of work (reviews), they doesn't have to get > between core-reviewers. In the future, if they need to move forward or quickly > fix something, they would need to ask some core-reviewer who is not familiar > with that code, just to approve it. > > You see where I am getting? > > > Perhaps this is something that won't scale well, but I have a great deal > of > faith in Robert's judgement on who is or isn't reviewing effectively. > > I have no experience with Rob's distribution of core-members and I believe > that > he does it based on his best faith. > > I am just suggesting more project based approach since the whole program > expanded into more projects. It doesn't have to be strict project based > metric, > it can be combined with 'across projects contribution', so we assure that > people are aware of the whole effort. But I believe that the project focus > should stay as primary metric. > > > > -- > Cheers, > > Chris > > > Thanks > -- Jarda > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I generally agree with Jarda w/r/t more project based approach. I am concerned with case when core reviewers can be overloaded with review demands. Of course if this happens we can "just" add another core reviewer to the group but I would suggest doing it other way - let's have broader core group at first and gradually lower number of core members (using metrics, discussion, need, common agreement from contributors...) by X every Y weeks or so. This way core reviewers group will shrink till its members feel that they have just enough reviews on their agenda that it does not hinder quality of their work. This will not eliminate any "competition" for core membership but it will eliminate immediate impact on projects' review process, on reviewers' workload and will help gradually decide if any project needs a core-member even if that person is not that active reviewer but can ensure that patches will not grow old for that project. That is my 2 cents. -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tuskar] pecan models vs. db models
Hi, during my work on getting tests to pass for https://review.openstack.org/#/c/46947/ I discovered that we are misusing pecan models for HTTP representation of Resources. In controllers pecan/wsme calls actions with pecan model prepopulated from HTTP request's params. For example, when creating new Rack, post method in Racks controller is called with rack object ( https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/rack.py#L26-L31 ). This object is instance of Rack from https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/types/rack.py . Next this object is used in pecan.request.dbapi.create_rack(rack) call (method defined here https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py#L385-L431 ) This method just assumes that new_rack object (passed from controller) has some attributes with getters defined (name, subnet, location, ...). This is fine if we have 1-1 relationship between how resource is stored in db and how it is represented via HTTP. In fact this assumes that both versions have the same set of atributes. Marios wrote a patch (mentioned above) which needs some internal attributes only, ie. present in table but not exposed via HTTP. In that moment I found that we use pecan models ( https://github.com/stackforge/tuskar/tree/master/tuskar/api/controllers/v1/types ) to transfer HTTP params _directly_ to our db layer ( https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py ). By _directly_ I mean that we assume 1-1 mapping between attributes in pecan models and db models. This is not to be true anymore. We can solve it by using conditionals like this https://review.openstack.org/#/c/46947/3/tuskar/db/sqlalchemy/api.py (lines 175 to 181) but I think this is not good solution b/c of repetion of code and generaly we are mixing up HTTP repr. with db repr. I propose to write a simple layer responsible for "translating" pecan models into db representation. This way we can keep all diffs in what attributes are exposed via HTTP and which not in one place - easy to see, easy to change, easy to review. To scatter it around dbapi code is not a good way IMHO. Another issue which comes with this coupling of pecan/db models is in tests. In db tests we use utility helpers for creating resources in memory, ie create_test_resource_class method ( https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/test_db_racks.py#L28 ). This kind of methods comes from "from tuskar.tests.db import utils" and they use pecan models ( https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/utils.py#L17-L23 ). We are now on the same page as mentioned above. These db tests uses Relation and Link pecan models which means that easy solution like importing db models instead of pecan models is not doable at the moment b/c db models do not contains direct counterparts for Relation and Link. I am pretty woried about this pecan-db models coupling b/c if (or when) we will need more different stuctures on HTTP side than on db side (no 1-1 relationship) we will have to change our code and tests more. I hope that we will find a solution for this sooner than tuskar code will grow more complex. I would like to see something like "service objects" in controller part but simple set of "translations" can be ok if we do not break 1-1 parity too much. Tests will require more attention b/c of that Relation and Link pecan objects. Thank you for your patience with reading this and looking for a feedback. Maybe I missed something or I see this bigger than it really is or I am totally out :-) -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar] [TripleO] The vision and looking ahead
On Thu, Sep 19, 2013 at 10:08:28AM +0200, Tomas Sedovic wrote: > Hi everyone, > > Some of us Tuskar developers have had the chance to meet the TripleO > developers face to face and discuss the visions and goals of our projects. > > Tuskar's ultimate goal is to have to a full OpenStack management > solution: letting the cloud operators try OpenStack, install it, keep it > running throughout the entire lifecycle (including bringing in new > hardware, burning it in, decommissioning), help to scale it, secure the > setup, monitor for failures, project the need for growth and so on. > > And to provide a good user interface and API to let the operators > control and script this easily. > > Now, the scope of the OpenStack Deployment program (TripleO) includes > not just installation, but the entire lifecycle management (from racking > it up to decommissioning). Among other things they're thinking of are > issue tracker integration and inventory management, but these could > potentially be split into a separate program. > > That means we do have a lot of goals in common and we've just been going > at them from different angles: TripleO building the fundamental > infrastructure while Tuskar focusing more on the end user experience. > > We've come to a conclusion that it would be a great opportunity for both > teams to join forces and build this thing together. > > The benefits for Tuskar would be huge: > > * being a part of an incubated project > * more eyballs (see Linus' Law (the ESR one)) > * better information flow between the current Tuskar and TripleO teams > * better chance at attracting early users and feedback > * chance to integrate earlier into an OpenStack release (we could make > it into the *I* one) > > TripleO would get a UI and more developers trying it out and helping > with setup and integration. > > This shouldn't even need to derail us much from the rough roadmap we > planned to follow in the upcoming months: > > 1. get things stable and robust enough to demo in Hong Kong on real hardware > 2. include metrics and monitoring > 3. security > > What do you think? +1 > > Tomas > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Petr Blaho, pbl...@redhat.com Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
