Re: [openstack-dev] [TripleO][Nova] Specs and approvals

2014-08-25 Thread Jay Dobies
I was on vacation last week and am late to the discussion, but I'm +1 for the idea. On 08/19/2014 02:08 PM, Joe Gordon wrote: On Tue, Aug 19, 2014 at 8:23 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 08/19/2014 05:31 AM, Robert Collins wrote: Hey

Re: [openstack-dev] [TripleO] Review metrics - what do we want to measure?

2014-09-04 Thread Jay Dobies
It can, by running your own... but again it seems far better for core reviewers to decide if a change has potential or needs to be abandoned--that way there's an accountable human making that deliberate choice rather than the review team hiding behind an automated process so that no one is to

Re: [openstack-dev] [TripleO] Propose adding StevenK to core reviewers

2014-09-10 Thread Jay Dobies
+1 On 09/09/2014 02:32 PM, Gregory Haynes wrote: Hello everyone! I have been working on a meta-review of StevenK's reviews and I would like to propose him as a new member of our core team. As I'm sure many have noticed, he has been above our stats requirements for several months now. More

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

2014-09-18 Thread Jay Dobies
How many of the reviews that we WIP-1 will actually be revisited? I'm sure there will be cases where a current developer forgetting they had started on something, seeing the e-mail about the WIP-1, and then abandoning the change. But what about developers who have moved off the project

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

2014-09-19 Thread Jay Dobies
On 2014-09-18 15:21:20 -0400 (-0400), Jay Dobies wrote: How many of the reviews that we WIP-1 will actually be revisited? I'm sure there will be cases where a current developer forgetting they had started on something, seeing the e-mail about the WIP-1, and then abandoning the change. But what

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-09 Thread Jay Dobies
On 12/06/2013 09:39 PM, Tzu-Mainn Chen wrote: Thanks for the comments and questions! I fully expect that this list of requirements will need to be fleshed out, refined, and heavily modified, so the more the merrier. Comments inline: *** Requirements are assumed to be targeted for

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-09 Thread Jay Dobies
So the question is are we looking at /nodes/ that have a /current role/, or are we looking at /roles/ that have some /current nodes/. My contention is that the role is the interesting thing, and the nodes is the incidental thing. That is, as a sysadmin, my hierarchy of concerns is something

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-10 Thread Jay Dobies
Thanks for the explanation! I'm going to claim that the thread revolves around two main areas of disagreement. Then I'm going to propose a way through: a) Manual Node Assignment I think that everyone is agreed that automated node assignment through nova-scheduler is by far the most ideal

Re: [openstack-dev] [TripleO] Tuskar CLI after architecture changes

2013-12-11 Thread Jay Dobies
Disclaimer: I swear I'll stop posting this sort of thing soon, but I'm new to the project. I only mention it again because it's relevant in that I missed any of the discussion on why proxying from tuskar API to other APIs is looked down upon. Jiri and I had been talking yesterday and he

Re: [openstack-dev] [TripleO] Tuskar CLI after architecture changes

2013-12-11 Thread Jay Dobies
:32 PM, Jay Dobies wrote: Disclaimer: I swear I'll stop posting this sort of thing soon, but I'm new to the project. I only mention it again because it's relevant in that I missed any of the discussion on why proxying from tuskar API to other APIs is looked down upon. Jiri and I had been talking

Re: [openstack-dev] [TripleO][Tuskar] Terminology

2013-12-11 Thread Jay Dobies
So glad we're hashing this out now. This will save a bunch of headaches in the future. Good call pushing this forward. On 12/11/2013 02:15 PM, Tzu-Mainn Chen wrote: Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-12 Thread Jay Dobies
On 12/12/2013 04:25 PM, Keith Basil wrote: On Dec 12, 2013, at 4:05 PM, Jay Dobies wrote: Maybe this is a valid use case? Cloud operator has several core service nodes of differing configuration types. [node1] -- balanced mix of disk/cpu/ram for general core services [node2] -- lots

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-13 Thread Jay Dobies
* ability to 'preview' changes going to the scheduler What does this give you? How detailed a preview do you need? What information is critical there? Have you seen the proposed designs for a heat template preview feature - would that be sufficient? Will will probably have a better answer to

Re: [openstack-dev] [TripleO] UI Wireframes for Resource Management - ready for implementation

2013-12-16 Thread Jay Dobies
On 12/13/2013 01:53 PM, Tzu-Mainn Chen wrote: On 2013/13/12 11:20, Tzu-Mainn Chen wrote: These look good! Quick question - can you explain the purpose of Node Tags? Are they an additional way to filter nodes through nova-scheduler (is that even possible?), or are they there solely for

Re: [openstack-dev] [TripleO] Tuskar CLI after architecture changes

2013-12-20 Thread Jay Dobies
On 12/20/2013 08:40 AM, Ladislav Smola wrote: On 12/20/2013 02:06 PM, Radomir Dopieralski wrote: On 20/12/13 13:04, Radomir Dopieralski wrote: [snip] I have just learned that tuskar-api stays, so my whole ranting is just a waste of all our time. Sorry about that. Hehe. :-) Ok after the

Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

2014-01-08 Thread Jay Dobies
There were so many places in this thread that I wanted to jump in on as I caught up, it makes sense to just summarize things in once place instead of a half dozen quoted replies. I agree with the sentiments about flexibility. Regardless of my personal preference on source v. packages, it's

[openstack-dev] [TripleO][Tuskar] Domain Model Locations

2014-01-09 Thread Jay Dobies
I'm trying to hash out where data will live for Tuskar (both long term and for its Icehouse deliverables). Based on the expectations for Icehouse (a combination of the wireframes and what's in Tuskar client's api.py), we have the following concepts: = Nodes = A node is a baremetal machine on

Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations

2014-01-09 Thread Jay Dobies
The UI will also need to be able to look at the Heat resources running within the overcloud stack and classify them according to a resource category. How do you envision that working? There's a way in a Heat template to specify arbitrary metadata on a resource. We can add flags in there and

Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations

2014-01-10 Thread Jay Dobies
Thanks for the feedback :) = Stack = There is a single stack in Tuskar, the overcloud. A small nit here: in the long term Tuskar will support multiple overclouds. Yes, absolutely. I should have added For Icehouse like I did in other places. Good catch. There's few pieces of concepts

Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations

2014-01-10 Thread Jay Dobies
As much as the Tuskar Chassis model is lacking compared to the Tuskar Rack model, the opposite problem exists for each project's model of Node. In Tuskar, the Node model is pretty bare and useless, whereas Ironic's Node model is much richer. Thanks for looking that deeply into it :) So, it's

Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

2014-01-10 Thread Jay Dobies
Thanks for recording this. A few questions: - I'm guessing the capacity metrics will come from Ceilometer. Will Ceilometer provide the averages for the role or is that calculated by Tuskar? - When on the change deployments screen, after making a change but not yet applying it, how are the

Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

2014-01-10 Thread Jay Dobies
Another question: - A Role (sounds like we're moving away from that so I'll call it Resource Category) can have multiple Node Profiles defined (assuming I'm interpretting the + and the tabs in the Create a Role wireframe correctly). But I don't see anywhere where a profile is selected when

Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations

2014-01-13 Thread Jay Dobies
Excellent write up Jay. I don't actually know the answer. I'm not 100% bought into the idea that Tuskar isn't going to store any information about the deployment and will rely entirely on Heat/Ironic as the data store there. Losing this extra physical information may be a a strong reason why

Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

2014-01-13 Thread Jay Dobies
On 01/13/2014 05:43 AM, Jaromir Coufal wrote: On 2014/10/01 21:17, Jay Dobies wrote: Another question: - A Role (sounds like we're moving away from that so I'll call it Resource Category) can have multiple Node Profiles defined (assuming I'm interpretting the + and the tabs in the Create

[openstack-dev] [TripleO][Tuskar] Editing Nodes

2014-01-13 Thread Jay Dobies
I'm pulling this particular discussion point out of the Wireframes thread so it doesn't get lost in the replies. = Background = It started with my first bulletpoint: - When a role is edited, if it has existing nodes deployed with the old version, are the automatically/immediately updated? If

Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

2014-01-15 Thread Jay Dobies
I don't necessarily disagree with this assertion, but what this could lead to is a proliferation of a bunch of very similar images. Templatizing some of the attributes (e.g., this package is enabled, that one isn't) can reduce the potential explosion of images stored in glance. If that's a

Re: [openstack-dev] [TripleO][Tuskar] Editing Nodes

2014-01-15 Thread Jay Dobies
that frame of reference, I'll reply inline: On Mon, Jan 13, 2014 at 11:18 AM, Jay Dobies jason.dob...@redhat.com wrote: I'm pulling this particular discussion point out of the Wireframes thread so it doesn't get lost in the replies. = Background = It started with my first bulletpoint: - When

Re: [openstack-dev] [TripleO][Tuskar] Editing Nodes

2014-01-17 Thread Jay Dobies
reply inline: On Mon, Jan 13, 2014 at 11:18 AM, Jay Dobies jason.dob...@redhat.com wrote: I'm pulling this particular discussion point out of the Wireframes thread so it doesn't get lost in the replies. = Background = It started with my first bulletpoint: - When a role is edited, if it has

Re: [openstack-dev] [Ceilometer] [TripleO] adding process/service monitoring

2014-01-28 Thread Jay Dobies
On 01/27/2014 09:32 PM, Robert Collins wrote: On 28 January 2014 14:59, Richard Su r...@redhat.com wrote: Hi, I have been looking into how to add process/service monitoring to tripleo. Here I want to be able to detect when an openstack dependent component that is deployed on an instance has

Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles

2014-01-28 Thread Jay Dobies
On 01/28/2014 11:42 AM, Jay Pipes wrote: On Tue, 2014-01-28 at 10:02 -0500, Tzu-Mainn Chen wrote: Yep, although the reason why - that no end-user will know what these terms mean - has never been entirely convincing to me. Well, tenants would never see any of the Tuskar UI, so I don't think

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

2014-01-30 Thread Jay Dobies
Wouldn't lying about the hardware specs when registering nodes be problematic for upgrades? Users would have to re-register their nodes. This was my first impression too, the line basically lie about the hardware specs when enrolling them. It feels more wrong to have the user provide false

Re: [openstack-dev] [Heat] [TripleO] Rolling updates spec re-written. RFC

2014-02-05 Thread Jay Dobies
First, I don't think RollingUpdatePattern and CanaryUpdatePattern should be 2 different entities. The second just looks like a parametrization of the first (growth_factor=1?). Perhaps they can just be one. Until I find parameters which would need to mean something different, I'll just use

Re: [openstack-dev] [TripleO] consistency vs packages in TripleO

2014-02-14 Thread Jay Dobies
On Fri, Feb 14, 2014 at 10:27:20AM +1300, Robert Collins wrote: So progressing with the 'and folk that want to use packages can' arc, we're running into some friction. I've copied -operators in on this because its very relevant IMO to operators :) So far: - some packages use different

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

2014-02-20 Thread Jay Dobies
Just to throw this out there, is this something we need for Icehouse? Yes, I fully acknowledge that it's an ugly security hole. But what's our story for how stable/clean Tuskar will be for Icehouse? I don't believe the intention is for people to use this in a production environment yet, so it

Re: [openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API

2014-02-26 Thread Jay Dobies
This is a new concept to me in JSON, I've never heard of a wrapper element like that being called a namespace. 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

Re: [openstack-dev] [TripleO] Tuskar CLI UX

2014-02-26 Thread Jay Dobies
Hello, i went through the CLI way of deploying overcloud, so if you're interested what's the workflow, here it is: https://gist.github.com/jistr/9228638 This is excellent to see it all laid out like this, thanks for writing it up. I'd say it's still an open question whether we'll want to

Re: [openstack-dev] [TripleO] Tuskar CLI UX

2014-02-27 Thread Jay Dobies
Yeah. This is a double bladed axe but i'm leaning towards naming flavors consistently a bit more too. Here's an attempt at +/- summary: node profile + a bit more descriptive for a newcomer imho - CLI renaming/reimplementing mentioned before - inconsistency dangers lurking in the deep - e.g.

Re: [openstack-dev] [TripleO][Reviewers] Please add openstack/os-cloud-config to your tripleo-repositories-to-review

2014-03-03 Thread Jay Dobies
I updated https://wiki.openstack.org/wiki/TripleO and the link at the All TripleO Reviews at the bottom to include it. On 03/02/2014 12:07 AM, Robert Collins wrote: This is a new repository to provide common code for tuskar and the seed initialisation logic - the post heat completion initial

Re: [openstack-dev] [TripleO] [Horizon] Searching for a new name for Tuskar UI

2014-03-27 Thread Jay Dobies
It might be good to do a similar thing as Keystone does. We could keep python-tuskarclient focused only on Python bindings for Tuskar (but keep whatever CLI we already implemented there, for backwards compatibility), and implement CLI as a plugin to OpenStackClient. E.g. when you want to access

Re: [openstack-dev] [TripleO] capturing build details in images

2013-12-05 Thread Jay Dobies
On 12/05/2013 08:38 AM, James Slagle wrote: On Wed, Dec 4, 2013 at 5:19 PM, Robert Collins robe...@robertcollins.net wrote: This is a follow up to https://review.openstack.org/59621 to get broader discussion.. So at the moment we capture a bunch of details in the image - what parameters the

Re: [openstack-dev] [Nova][TripleO] Nested resources

2013-12-06 Thread Jay Dobies
Along the same lines and while we're talking crazy ideas, one use case where a user might want to allocate entire nodes would be if TripleO were used to manage an ARM rack. The use cases aren't identical between cloud and ARM, but they are similar. So for a rack of 1000 nodes, there is

Re: [openstack-dev] [TripleO][Tuskar] Questions around Development Process

2013-12-06 Thread Jay Dobies
a) Because we're essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar will simply disappear), it's difficult to do small incremental patches that support existing functionality. Is it okay to have patches that break functionality? Are there good

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

2013-12-06 Thread Jay Dobies
On 12/06/2013 12:26 PM, Clint Byrum wrote: Excerpts from Robert Collins's message of 2013-12-03 23:12:39 -0800: Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-06 Thread Jay Dobies
Disclaimer: I'm very new to the project, so apologies if some of my questions have been already answered or flat out don't make sense. As I proofread, some of my comments may drift a bit past basic requirements, so feel free to tell me to take certain questions out of this thread into

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-09 Thread Jay Dobies
I believe we are still 'fighting' here with two approaches and I believe we need both. We can't only provide a way 'give us resources we will do a magic'. Yes this is preferred way - especially for large deployments, but we also need a fallback so that user can say - no, this node doesn't belong

[openstack-dev] [TripleO] dib-utils Release Question

2014-06-23 Thread Jay Dobies
I finished the releases for all of our existing projects and after poking around tarballs.openstack.org and pypi, it looks like they built successfully. Yay me \o/ However, it doesn't look like dib-utils build worked. I don't see it listed on tarballs.openstack.org. It was the first release

Re: [openstack-dev] [TripleO] dib-utils Release Question

2014-06-24 Thread Jay Dobies
Ahh, ok. I had just assumed it was a Python library, but I admittedly didn't look too closely at it. Thanks :) On 06/23/2014 09:32 PM, Steve Kowalik wrote: On 24/06/14 06:31, Jay Dobies wrote: I finished the releases for all of our existing projects and after poking around

Re: [openstack-dev] [TripleO] Proposal to add Jon Paul Sullivan and Alexis Lee to core review team

2014-07-10 Thread Jay Dobies
FWIW, I'm a firm believer in progress over perfection and although I comment on the form, I try to score on the function. I really like this phrase, comment on the form, score on the function. Lately I've been trying to be very specific about things I'm pointing out that are potentially a

[openstack-dev] [TripleO] Spec Minimum Review Proposal

2014-07-22 Thread Jay Dobies
At the meetup today, the topic of our spec process came up. The general sentiment is that the process is still young and the hiccups are expected, but we do need to get better about making sure we're staying on top of them. As a first step, it was proposed to add 1 spec review a week to the

Re: [openstack-dev] [TripleO] config options, defaults, oh my!

2014-04-08 Thread Jay Dobies
I'm very wary of trying to make the decision in TripleO of what should and shouldn't be configurable in some other project.For sure the number of config options in Nova is a problem, and one that's been discussed many times at summits. However I think you could also make the

Re: [openstack-dev] [Heat] heat is not present in keystone service-list

2014-04-08 Thread Jay Dobies
For what it's worth, I have a fresh devstack installation from about a week ago and I have two Heat services registered without any extra steps. On 04/08/2014 11:44 AM, Steven Dake wrote: On 04/08/2014 07:00 AM, Peeyush Gupta wrote: Hi all, I have been trying to install heat with devstack.

Re: [openstack-dev] [TripleO] reviewer update march [additional cores]

2014-04-08 Thread Jay Dobies
On 04/07/2014 07:50 PM, Robert Collins wrote: tl;dr: 3 more core members to propose: bnemec greghaynes jdon I'm comfortable with committing to at least 3 reviews a day and promise to wield the awesome power of +2 responsibly. I appreciate being nominated :) On 4 April 2014 08:55, Chris

Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo

2014-04-10 Thread Jay Dobies
On 04/10/2014 01:40 PM, Nachi Ueno wrote: Hi Jarda Congratulations This release and the demo is super awesome!! Do you have any instruction to install this one? I'd like to see this too. I asked a few times and never got an answer on whether or not there was a documented way of demoing this

Re: [openstack-dev] [tripleo] Default paths in os-*-config projects

2014-04-15 Thread Jay Dobies
On 04/14/2014 09:30 PM, 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

Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh

2014-04-15 Thread Jay Dobies
+1 to using bash, the argument about not keeping POSIX compliance for the sake of it makes sense to me. On 04/15/2014 07:31 AM, Ghe Rivero wrote: +1 to use bash as the default shell. So far, all major distros use bash as the default one (except Debian which uses dash). An about rewriting the

Re: [openstack-dev] [TripleO][design] review based conceptual design process

2014-04-15 Thread Jay Dobies
+1, I think it's a better medium for conversations than blueprints or wikis. I'm also +1 to a tripleo-specs repo, but that's less me having a problem with using incubator and more my OCD. On 04/15/2014 03:43 PM, Monty Taylor wrote: On 04/15/2014 11:44 AM, Robert Collins wrote: I've been

Re: [openstack-dev] [TripleO] HAProxy and Keystone setup (in Overcloud)

2014-04-28 Thread Jay Dobies
We may want to consider making use of Heat outputs for this. This was my first thought as well. stack-show returns a JSON document that would be easy enough to parse through instead of having it in two places. Rather than assuming hard coding, create an output on the overcloud template

[openstack-dev] [TripleO] Spec Template Change Proposal

2014-05-21 Thread Jay Dobies
Currently, there is the following in the template: Proposed change === [snip] Alternatives [snip] Security impact --- The unit tests assert the top and second level sections are standard, so if I add a section at the same level as Alternatives under

Re: [openstack-dev] [TripleO] Spec Template Change Proposal

2014-05-22 Thread Jay Dobies
Merging a few of the replies into a single response: I like all of this plan, except for the name Overview. To me, Overview suggests a high-level summary rather than being one of the beefier sections of a spec. Something like Detail or Detailed overview (because the low-level detail will

Re: [openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs

2014-06-02 Thread Jay Dobies
Very nicely done, seeing this stuff laid out is really useful. A few comments: = Page 3 = * Nit: The rocker switch for power is a bit odd to me since it looks like it can be toggled. * Can you show an example of a non-healthy node? Is it just an X instead of a check or are there different

Re: [openstack-dev] [TripleO] Strategy for testing and merging the merge.py-free templates

2014-10-14 Thread Jay Dobies
On 10/14/2014 04:55 AM, Tomas Sedovic wrote: Hi everyone, As outlined in the Remove merge.py[1] spec, Peter Belanyi and I have built the templates for controller, nova compute, swift and cinder nodes that can be deploying directly to Heat (i.e. no merge.py pass is necessary). The patches:

Re: [openstack-dev] [tuskar][tripleo] Tuskar/TripleO on Devstack

2014-10-28 Thread Jay Dobies
5. API: You can't create or modify roles via the API, or even view the content of the role after creating it None of that is in place yet, mostly due to time. The tuskar-load-roles was a short-term solution to getting a base set of roles in. Conceptually you're on target with I want to see in

Re: [openstack-dev] [tuskar] Puppet module

2014-10-29 Thread Jay Dobies
Nope, there isn't a puppet module for deploying Tuskar, but starting one makes sense. On 10/28/2014 06:04 PM, Emilien Macchi wrote: Hi, I was looking at deploying Tuskar API with Puppet and I was wondering if you guys have already worked on a Puppet module. If not, I think we could start

Re: [openstack-dev] [TripleO] Do we want to remove Nova-bm support?

2014-12-04 Thread Jay Dobies
+1, FWIW. Alexis +1 This is similar to the no merge.py discussion. If something isn't covered by CI, it's going to grow stale pretty quickly. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [TripleO] Meeting purpose

2014-12-04 Thread Jay Dobies
As an example of something that I think doesn't add much value in the meeting - DerekH has already been giving semi-regular CI/CD status reports via email. I'd like to make these weekly update emails regular, and take the update off the meeting agenda. I'm offering to share the load with him to

Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

2015-01-14 Thread Jay Dobies
+1 On 01/14/2015 02:26 PM, Gregory Haynes wrote: Excerpts from Clint Byrum's message of 2015-01-14 18:14:45 +: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has

Re: [openstack-dev] [TripleO] Core reviewer update proposal

2015-05-05 Thread Jay Dobies
On 05/05/2015 07:57 AM, 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

Re: [openstack-dev] [TripleO] puppet pacemaker thoughts... and an idea

2015-05-07 Thread Jay Dobies
On 05/07/2015 06:01 AM, Giulio Fidente wrote: On 05/07/2015 11:15 AM, marios wrote: On 07/05/15 05:32, Dan Prince wrote: [..] Something like this: https://review.openstack.org/#/c/180833/ +1 I like this as an idea. Given we've already got quite a few reviews in flight making changes to

Re: [openstack-dev] [TripleO] puppet pacemaker thoughts... and an idea

2015-05-07 Thread Jay Dobies
Something like this: https://review.openstack.org/#/c/180833/ I'm not convinced this is a good user experience though. You have configuration effectively in two places. If you want to enable Galera, or enable ceph storage, it's a parameter. But not pacemaker. To enable that, you have to

Re: [openstack-dev] [tripleo] Building images separation and moving images into right place at right time

2015-04-17 Thread Jay Dobies
Have you seen Dan's first steps towards splitting the overcloud image building out of devtest_overcloud? It's not the same thing that you're talking about, but it might be a step in that direction. https://review.openstack.org/#/c/173645/ On 04/17/2015 09:50 AM, Jaromir Coufal wrote: Hi All,

Re: [openstack-dev] [heat][tripleo]Recursive validation for easier composability

2015-06-22 Thread Jay Dobies
On 06/22/2015 12:19 PM, Steven Hardy wrote: Hi all, Lately I've been giving some thought to how we might enable easier composability, and in particular how we can make it easier for folks to plug in deeply nested optional extra logic, then pass data in via parameter_defaults to that nested

[openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities

2015-06-23 Thread Jay Dobies
I didn't want to hijack Steve Hardy's thread about the recursive validation, but I wanted to summarize the needs that Tuskar and the UI have been trying to answer and some of the problems we ran into. I think it's fairly common knowledge now that Tuskar and the THT templates diverged over the

Re: [openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities

2015-06-29 Thread Jay Dobies
FWIW, I liked what you were proposing in the other thread. In thinking about the deployment flow in the Tuskar-UI, I think it would enable exposing and setting the nested stack parameters easily (you choose various resources as displayed in a widget, click a reload/refresh button, and new

Re: [openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities

2015-06-29 Thread Jay Dobies
We could do likewise in the environment: resource_registry: OS::TripleO::ControllerConfig: puppet/controller-config.yaml ... constraints: OS::TripleO::ControllerConfig: - allowed_values: - puppet/controller-config.yaml, - foo/other-config.yaml] These constraints

Re: [openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities

2015-06-29 Thread Jay Dobies
I had originally been thinking of it like slagle describes, from the child up to the parent as well. What I like about that approach is that it achieves a more pluggable model when you think about extensions that aren't accepted or applicable in TripleO upstream. If someone comes along and adds

[openstack-dev] [heat] Shared code between server and client

2015-10-22 Thread Jay Dobies
I'm working on moving the functionality for merging environments from the client into the server [1]. I've only superficially looked at template_utils.py (in heatclient) but I'm guessing there is stuff in there I will want to use server-side. The server has a requirement on heatclient, but

[openstack-dev] [heat] resource_registry base_url

2015-10-22 Thread Jay Dobies
In looking through the environment file loading code, I keep seeing a check for base_url in the resource registry. It looks like a way to have the registry entries only be the filenames (I suppose relative filenames work as well) instead of having to enter the full path every time. The

Re: [openstack-dev] [heat] Shared code between server and client

2015-10-27 Thread Jay Dobies
ack, but I wanted to explicitly ask anyway. Thanks :) -Rob On 23 October 2015 at 08:49, Jay Dobies <jason.dob...@redhat.com> wrote: I'm working on moving the functionality for merging environments from the client into the server [1]. I've only superficially looked at template_utils.p

Re: [openstack-dev] [heat] Shared code between server and client

2015-10-27 Thread Jay Dobies
On 10/27/2015 11:09 AM, Jay Dobies wrote: On 23/10/15 05:35, Robert Collins wrote: My 2c - if its a stable API in the client, and can be kept stable, there's no problem. +1 Ok, forgive me for sounding dumb here (and changing the topic of the thread somewhat), but what do we consider

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

2015-11-16 Thread Jay Dobies
Hi all, I wanted to start some discussion re $subject, because it's been apparrent that we have a lack of clarity on this issue (and have done ever since we started using parameter_defaults). Some context: - Historically TripleO has provided a fairly comprehensive "top level" parameters

Re: [openstack-dev] [tripleo] Location of TripleO REST API

2015-11-16 Thread Jay Dobies
On 11/10/2015 10:08 AM, Tzu-Mainn Chen wrote: Hi all, At the last IRC meeting it was agreed that the new TripleO REST API should forgo the Tuskar name, and simply be called... the TripleO API. There's one more point of discussion: where should the API live? There are two possibilities: a)

[openstack-dev] [Heat] mox to mock migration

2015-10-09 Thread Jay Dobies
I forget where we left things at the last meeting with regard to whether or not there should be a blueprint on this. I was going to work on some during some downtime but I wanted to make sure I wasn't overlapping with what others may be converting (it's more time consuming than I anticipated).

Re: [openstack-dev] [Heat] mox to mock migration

2015-10-09 Thread Jay Dobies
://etherpad.openstack.org/p/heat-mox-to-mock Thanks for the guidance :) On 10/09/2015 12:42 PM, Steven Hardy wrote: On Fri, Oct 09, 2015 at 09:06:57AM -0400, Jay Dobies wrote: I forget where we left things at the last meeting with regard to whether or not there should be a blueprint on this. I was going

Re: [openstack-dev] [tripleo] Plugin integration and environment file naming

2015-09-08 Thread Jay Dobies
I like where this is going. I've been asked a number of times where to put things and we never had a solid convention. I like the idea of having that docced somewhere. I like either of the proposed solutions. My biggest concern is that they don't capture how you actually use them. I know that

Re: [openstack-dev] [TripleO] Encapsulating logic and state in the client

2015-08-25 Thread Jay Dobies
Thinking about this further, the interesting question to me is how much logic we aim to encapsulate behind an API. For example, one of the simpler CLI commands we have in RDO-Manager (which is moving upstream[1]) is to run introspection on all of the Ironic nodes. This involves a series of

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

2015-09-10 Thread Jay Dobies
On 09/10/2015 10:06 AM, James Slagle wrote: TripleO has added a few new repositories, one of which is python-tripleoclient[1], the former python-rdomanager-oscplugin. With the additional repositories, there is an additional review burden on our core reviewers. There is also the fact that folks

[openstack-dev] [heat] Client checking of server version

2016-01-04 Thread Jay Dobies
I ran into an issue in a review about moving environment resolution from client to server [1]. It revolves around clients being able to access older versions of servers (that's a pretty simplistic description; see [2] for the spec). Before the holiday, Steve Hardy and I were talking about the

Re: [openstack-dev] [heat] Client checking of server version

2016-01-06 Thread Jay Dobies
I ran into an issue in a review about moving environment resolution from client to server [1]. It revolves around clients being able to access older versions of servers (that's a pretty simplistic description; see [2] for the spec). Before the holiday, Steve Hardy and I were talking about the

Re: [openstack-dev] [heat] Client checking of server version

2016-01-06 Thread Jay Dobies
On 01/05/2016 04:37 PM, Steven Hardy wrote: On Mon, Jan 04, 2016 at 03:53:07PM -0500, Jay Dobies wrote: I ran into an issue in a review about moving environment resolution from client to server [1]. It revolves around clients being able to access older versions of servers (that's a pretty

Re: [openstack-dev] [heat] Client checking of server version

2016-01-06 Thread Jay Dobies
On 01/06/2016 12:05 PM, Zane Bitter wrote: On 05/01/16 16:37, Steven Hardy wrote: On Mon, Jan 04, 2016 at 03:53:07PM -0500, Jay Dobies wrote: I ran into an issue in a review about moving environment resolution from client to server [1]. It revolves around clients being able to access older

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

2015-11-25 Thread Jay Dobies
I think at the same time we add a mechanism to distinguish between internal and external parameters, we need to add something to indicate required v. optional. With a nested stack, anything that's not part of the top-level parameter contract is defaulted. The problem is that it loses information

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

2015-11-19 Thread Jay Dobies
My personal preference is to say: 1. Any templates which are included in the default environment (e.g overcloud-resource-registry-puppet.yaml), must expose their parameters via overcloud-without-mergepy.yaml 2. Any templates which are included in the default environment, but via a "noop"

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

2015-11-23 Thread Jay Dobies
On 11/20/2015 07:05 PM, Ben Nemec wrote: Thinking about this some more makes me wonder if we need a sample config generator like oslo.config. It would work off something similar to the capabilities map, where you would say SSL: templates: -puppet/extraconfig/tls/tls-cert-inject.yaml

Re: [openstack-dev] [heat][TripleO] Adding interfaces to environment files?

2016-06-07 Thread Jay Dobies
All, We've got some requirements around adding some interfaces to the heat environment file format, for example: 1. Now that we support passing un-merged environment files to heat, it'd be good to support an optional description key for environments, I've never understood why the environment

Re: [openstack-dev] [heat] Questions on template-validate

2016-02-24 Thread Jay Dobies
On 02/24/2016 02:18 AM, Anant Patil wrote: On 23-Feb-16 20:34, Jay Dobies wrote: I am going to bring this up in the team meeting tomorrow, but I figured I'd send it out here as well. Rather than retype the issue, please look at: https://bugs.launchpad.net/heat/+bug/1548856 My question

Re: [openstack-dev] [heat] Questions on template-validate

2016-02-24 Thread Jay Dobies
On 02/24/2016 02:18 AM, Anant Patil wrote: On 23-Feb-16 20:34, Jay Dobies wrote: I am going to bring this up in the team meeting tomorrow, but I figured I'd send it out here as well. Rather than retype the issue, please look at: https://bugs.launchpad.net/heat/+bug/1548856 My question

Re: [openstack-dev] [TripleO] core members for tripleo-ui

2016-02-29 Thread Jay Dobies
+1 On 02/29/2016 10:27 AM, Dan Prince wrote: There is a new projects for the ui called tripleo-ui. As most of the existing TripleO core members aren't going to be reviewing UI specific patches is seems reasonable that we might add a few review candidates who can focus specifically on UI

[openstack-dev] [heat] Questions on template-validate

2016-02-23 Thread Jay Dobies
I am going to bring this up in the team meeting tomorrow, but I figured I'd send it out here as well. Rather than retype the issue, please look at: https://bugs.launchpad.net/heat/+bug/1548856 My question is what the desired behavior of template-validate should be, at least from a historical

Re: [openstack-dev] [heat] spec-lite for simple feature requests

2016-01-22 Thread Jay Dobies
On 01/20/2016 10:21 AM, Rabi Mishra wrote: Hi All, As discussed in the team meeting, below is the proposed spec-lite process for simple feature requests. This is already being used in Glance project. Feedback/comments/concerns are welcome, before we update the contributor docs with this:).

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

2016-01-22 Thread Jay Dobies
I fall very much in the same mentality as Ben. I'm +1 to all of his points, with a few comments inline. On 01/22/2016 12:24 PM, Ben Nemec wrote: So I haven't weighed in on this yet, in part because I was on vacation when it was first proposed and missed a lot of the initial discussion, and

  1   2   >