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
Just a quick note that there is a new job active called
gate-heat-api-ref. Our API documentation has been pulled into our tree
[1] and you can run it locally with `tox -e api-ref`.
For now, it's a direct port of our existing API docs, but I'm planning
on taking a pass over them to double
Torchy's Tacos
1311 S 1st St
Austin, TX 78704
It's about a 20 minute walk from the Radisson (pretty much straight down
Congress Ave) and then over a block.
Meeting in the Radisson lobby at 7:10 to walk over. Apologies in advance
if we see another snake and I jump on someone's shoulders
[snip]
I need to be at both of those Heat ones anyway, so this doesn't really
help me. I'd rather have the DLM session in this slot instead. (The only
sessions I can really skip are the Release Model, Functional Tests and
DLM.) That would give us:
HeatTripleO
On 4/20/16 1:00 PM, Rico Lin wrote:
Hi team
Let plan for more informal meetup(relax) time! Let all heaters and any
other projects can have fun and chance for technical discussions together.
After discuss in meeting, we will have a pre-meetup-meetup on Friday
morning to have a cup of cafe or
This is the same issue I ran into a few months ago regarding the nested
parameter validation. Since it resolves to None at that time, there's no
hook in our current nested parameters implementation to show that it
will have a value passed in from the parent template.
Unfortunately, I don't
On 03/20/2016 02:32 PM, Dan Prince wrote:
I'd like to propose that we add John Trowbridge to the TripleO core
review team. John has become one of the goto guys in helping to chase
down upstream trunk chasing issues. He has contributed a lot to helping
keep general CI issues running and been
On 03/20/2016 02:22 PM, Dan Prince wrote:
I'd like to propose that we add Emilien Macchi to the TripleO core
review team. Emilien has been getting more involved with TripleO during
this last release. In addition to help with various Puppet things he
also has experience in building OpenStack
On 03/14/2016 10:38 AM, Dan Prince wrote:
http://russellbryant.net/openstack-stats/tripleo-reviewers-180.txt
Our top reviewer over the last half a year ejuaso (goes by Ozz for
Osorio or jaosorior on IRC). His reviews seem consistent, he
consistently attends the meetings and he chimes in on
On 03/11/2016 12:32 AM, Jason Rist wrote:
Hey everyone -
We've been working on a UI for TripleO for a few months now and we're
just about to beg to be a part of upstream... and we're in need of a
logo for the login page and header.
In my evenings, I've come up with a logo.
It's a
On 3/9/16 4:39 PM, Zane Bitter wrote:
On 09/03/16 05:42, Sergey Kraynev wrote:
Hi Gary,
First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's
+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
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
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
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
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:).
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
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
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
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
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
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
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
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"
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
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)
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
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
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
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
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).
://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
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
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
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
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
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
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
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
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
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
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
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
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,
+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
+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
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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
+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
+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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
: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
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
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
1 - 100 of 107 matches
Mail list logo
