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 **| no activity 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 der...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org 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 lifeless so I propose that +2 on a spec is a commitment to review it over-and-above the core review responsibilities 19:47:05 lifeless if its not important enough for a reviewer to do that thats a pretty strong signal 19:47:06 dprince lifeless: +1, I thought we already agreed to that at the meetup 19:47:17 slagle yea, sounds fine to me 19:47:20 bnemec +1 19:47:30 lifeless dprince: it wasn't clear whether it was part-of-responsibility, or additive, I'm proposing we make it clearly additive 19:47:52 lifeless 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 rbtcoll...@hp.com 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] [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 rbtcoll...@hp.com 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] 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] /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 openst...@nemebean.com 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][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 jcou...@redhat.com 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
