> On 27 January 2016 at 08:10, Tzu-Mainn Chen < tzuma...@redhat.com > wrote:
> > > Okay, so I initially thought we weren't making much progress on this
>
> > > discussion, but after some more thought and reading of the existing PoC,
>
> > > we're (maybe
> Okay, so I initially thought we weren't making much progress on this
> discussion, but after some more thought and reading of the existing PoC,
> we're (maybe?) less far apart than I initially thought.
>
> I think there are kind of three different designs being discussed.
>
> 1) Rewrite a
t; > more
> > > > > > > transparent about the actual workflows that are driving
> > > > > > > deployment.
> > > > > > > Smaller more focused workflows that we string together to
> > > > > > > drive the
> > > >
- Original Message -
> On Mon, Jan 25, 2016 at 05:45:30PM -0600, Ben Nemec wrote:
> > On 01/25/2016 03:56 PM, Steven Hardy wrote:
> > > On Fri, Jan 22, 2016 at 11:24:20AM -0600, Ben Nemec wrote:
> > >> So I haven't weighed in on this yet, in part because I was on vacation
> > >> when it
- Original Message -
> On Tue, Jan 26, 2016 at 09:23:00AM -0500, Tzu-Mainn Chen wrote:
> > - Original Message -
> > > On Mon, Jan 25, 2016 at 05:45:30PM -0600, Ben Nemec wrote:
> > > > On 01/25/2016 03:56 PM, Steven Hardy wrote:
> > > >
- Original Message -
> On 21 January 2016 at 14:46, Dougal Matthews < dou...@redhat.com > wrote:
> > On 20 January 2016 at 20:05, Tzu-Mainn Chen < tzuma...@redhat.com > wrote:
>
> > > - Original Message -
> >
>
> &
- Original Message -
> On 18.1.2016 19:49, Tzu-Mainn Chen wrote:
> > - Original Message -
> >> On Thu, 2016-01-14 at 16:04 -0500, Tzu-Mainn Chen wrote:
> >>>
> >>> - Original Message -
> >>>> On Wed, Jan 13, 2016 a
- Original Message -
> On Thu, 2016-01-14 at 16:04 -0500, Tzu-Mainn Chen wrote:
> >
> > - Original Message -
> > > On Wed, Jan 13, 2016 at 04:41:28AM -0500, Tzu-Mainn Chen wrote:
> > > > Hey all,
> > > >
> > > > I re
- Original Message -
> On Wed, Jan 13, 2016 at 04:41:28AM -0500, Tzu-Mainn Chen wrote:
> > Hey all,
> >
> > I realize now from the title of the other TripleO/Mistral thread [1] that
> > the discussion there may have gotten confused. I think using Mistra
pretty simple: storage -> some logic ->
a REST API. Adding a workflow engine on top of that is unneeded, and I
believe that means it's an incorrect solution.
Thanks,
Tzu-Mainn Chen
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083757.html
[2]
https://github.com/ope
- Original Message -
> On Wed, 2016-01-13 at 04:41 -0500, Tzu-Mainn Chen wrote:
> > Hey all,
> >
> > I realize now from the title of the other TripleO/Mistral thread [1]
> > that
> > the discussion there may have gotten confused. I think using Mist
> On 01/11/2016 11:09 PM, Tzu-Mainn Chen wrote:
> > - Original Message -
> >> Background info:
> >>
> >> We've got a problem in TripleO at the moment where many of our
> >> workflows can be driven by the command line only. This causes some
- Original Message -
> Background info:
>
> We've got a problem in TripleO at the moment where many of our
> workflows can be driven by the command line only. This causes some
> problems for those trying to build a UI around the workflows in that
> they have to duplicate deployment logic
- Original Message -
> On 12/07/2015 04:33 AM, Tzu-Mainn Chen wrote:
> >
> >
> > On 04/12/15 23:04, Dmitry Tantsur wrote:
> >
> > On 12/03/20
- Original Message -
> On 04/12/15 23:04, Dmitry Tantsur wrote:
> > On 12/03/2015 08:45 PM, Tzu-Mainn Chen wrote:
>
> > > Hey all,
> >
>
> > > Over the past few months, there's been a lot of discussion and work
> > > around
> &g
-level overview
of what's been going on. Hopefully it'll provide some useful perspective for
those that are curious!
Thanks,
Tzu-Mainn Chen
--
1. Explanation for Deployment Workflow Change
TripleO uses Heat to deploy
- Original Message -
> On 10 November 2015 at 15:08, Tzu-Mainn Chen < tzuma...@redhat.com > 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 Tri
is that renaming is not trivial; however
it was mentioned that renaming might not be *too* bad... as long as
it's done sooner rather than later.
What do people think?
Thanks,
Tzu-Mainn Chen
__
OpenStack Development Mailing
.
What do people think?
Thanks,
Tzu-Mainn Chen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin
- Original Message -
It occurs to me that there has never been a detailed exposition of the
purpose of the tripleo-common library here, and that this might be a
good time to rectify that.
Basically, there are two things that it sucks to have in the client:
First, logic - that is,
- Original Message -
On Thu, Apr 02, 2015 at 10:34:29AM -0400, Dan Prince wrote:
On Wed, 2015-04-01 at 21:31 -0400, Tzu-Mainn Chen wrote:
Hey all,
I've run into a requirement where it'd be useful if, as an end user, I
could inject
a personal ssh key onto all
manifest (rather than overriding
the default post-deployment customization manifest).
Do either of these solutions seem acceptable to others? Would one be preferred?
Thanks,
Tzu-Mainn Chen
__
OpenStack Development Mailing List
On Thu, Oct 30, 2014 at 01:13:48PM +0100, Matthias Runge wrote:
Hi,
tl;dr: how to progreed in separating horizon and openstack_dashboard
About a year ago now we agreed, it makes sense to separate horizon and
openstack_dashboard.
At the past summit, we discussed this again.
On 10/11/14 14:20, Tzu-Mainn Chen wrote:
How about 'horizon_dashboard'? I think pairing that with 'horizon_lib'
would make the purpose of each very clear.
Wouldn't that imply, there exists an openstack_dashboard as well?
Matthias
Well, the original renaming idea
and future milestones.
Hope this is helpful!
Thanks,
Tzu-Mainn Chen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 6/20/14, 6:24 AM, Radomir Dopieralski openst...@sheep.art.pl wrote:
On 20/06/14 13:56, Jaromir Coufal wrote:
On 2014/19/06 09:58, Matthias Runge wrote:
On Wed, Jun 18, 2014 at 10:55:59AM +0200, Jaromir Coufal wrote:
My quick questions are:
* Who would be interested (and able) to get
. Is there a separate place where such code might live? Something
similar in concept
to https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage ?
Thanks,
Tzu-Mainn Chen
___
OpenStack-dev mailing list
OpenStack-dev
of either dashboard?
Thanks,
Tzu-Mainn Chen
- Original Message -
Hey Tzu-Mainn,
I've actually discouraged people from doing this sort of thing when
customizing Horizon. IMO it's risky to extend those panels because they
really aren't intended as extension points. We intend Horizon
Hi Jarda,
These look pretty good! However, I'm having trouble evaluating from a purely
functional point of view, as I'm not entirely sure what the requirements
driving these design. Would it be possible to list those out. . . ?
Thanks,
Tzu-Mainn Chen
- Original Message -
Hi All
Hey all,
Here's a link to the etherpad for the summit session on Tuskar:
https://etherpad.openstack.org/p/juno-summit-tripleo-tuskar-planning
Please feel free to discuss or add suggestions or make changes!
Thanks,
Tzu-Mainn Chen
___
OpenStack-dev
I have a question about adding new panels with respect to tests.
I have a new panel (for the Sahara project, data processing) that lives (for
now at least) under the projects folder. The plan is to have it activated
only by using the new enabled mechanism to define a new panel group, data
/TuskarJunoPlanning
Please feel free to take a look and question, comment, or criticize!
Thanks,
Tzu-Mainn Chen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi OpenStackers,
User interface which is managing the OpenStack Infrastructure is
currently named Tuskar-UI because of historical reasons. Tuskar itself
is a small service, which is giving logic into generating and managing
Heat templates and helps user to model and manage his deployment.
Hello,
I think if we will use Openstack CLI, it has to be something like this
https://github.com/dtroyer/python-oscplugin.
Otherwise we are not Openstack on Openstack.
Btw. abstracting it all to one big CLI will be just more confusing when
people will debug issues. So it would
have to
Multiple flavors, but a single flavor per role, correct?
Mainn
- Original Message -
I think we still are going to multiple flavors for I, e.g.:
https://review.openstack.org/#/c/74762/
On Thu, 2014-02-20 at 08:50 -0500, Jay Dobies wrote:
On 02/20/2014 06:40 AM, Dmitry Tantsur
Hi,
In parallel to Jarda's updated wireframes, and based on various discussions
over the past
weeks, here are the updated Tuskar requirements for Icehouse:
https://wiki.openstack.org/wiki/TripleO/TuskarIcehouseRequirements
Any feedback is appreciated. Thanks!
Tzu-Mainn Chen
On 1 February 2014 10:03, Tzu-Mainn Chen tzuma...@redhat.com wrote:
So after reading the replies on this thread, it seems like I (and others
advocating
a custom scheduler) may have overthought things a bit. The reason this
route was
suggested was because of conflicting goals
So after reading the replies on this thread, it seems like I (and others
advocating
a custom scheduler) may have overthought things a bit. The reason this route
was
suggested was because of conflicting goals for Icehouse:
a) homogeneous nodes (to simplify requirements)
b) support diverse
Wouldn't lying about the hardware specs when registering nodes be problematic
for upgrades? Users would have
to re-register their nodes.
One reason why a custom filter feels attractive is that it provides us with a
clear upgrade path:
Icehouse
* nodes are registered with correct attributes
- Original Message -
On 30 January 2014 23:26, Tomas Sedovic tsedo...@redhat.com wrote:
Hi all,
I've seen some confusion regarding the homogenous hardware support as the
first step for the tripleo UI. I think it's time to make sure we're all on
the same page.
Here's what I
I've spent some time thinking about this, and I have a clarification.
I don't like the use of the word 'deployment', because it's not exact
enough for me. Future plans for the tuskar-ui include management of the
undercloud as well, and at that point, 'deployment role' becomes vague, as
it could
were modeling.
Part of the difficulty here is the perception that developers and end-users
have different needs when it comes to terminology.
Mainn
- Original Message -
I thought we were avoiding using overcloud and undercloud within the UI?
-J
On 01/28/2014 03:04 AM, Tzu-Mainn Chen
I'd argue that we should call it 'overcloud role' - at least from the modeling
point of view - since the tuskar-api calls a deployment an overcloud.
But I like the general direction of the term-renaming!
Mainn
- Original Message -
Based on this thread which didn't seem to get clear
- Original Message -
On 23 January 2014 21:39, Jaromir Coufal jcou...@redhat.com wrote:
On 2014/22/01 19:46, Tzu-Mainn Chen wrote:
So... For now, the attributes are:
- Name
- Description
- Image (Image was discussed on the level of a Role, not Node Profile)
- Node
That's a fair question; I'd argue that it *should* be resources. When we
update an overcloud deployment, it'll create additional resources.
Mainn
- Original Message -
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
- Original Message -
On 2014/22/01 10:00, Jaromir Coufal wrote:
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e., if we specify that we want an Overcloud
with 1
On 2014/22/01 10:00, Jaromir Coufal wrote:
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e., if we specify that we want an Overcloud
with 1 Controller
and 3
On Jan 22, 2014, at 7:09 AM, Jaromir Coufal jcou...@redhat.com wrote:
On 2014/22/01 10:00, Jaromir Coufal wrote:
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e
On Jan 22, 2014, at 4:02 AM, Jaromir Coufal jcou...@redhat.com wrote:
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1
...
On 2014/22/01 15:10, Tzu-Mainn Chen wrote:
That's a fair question; I'd argue that it *should* be resources. When we
update an overcloud deployment, it'll create additional resources.
Honestly it would get super confusing for me, if somebody tells me - you
have 5 compute resources
Thanks for starting this! Comments in-line:
Hi folks,
when I was getting feedback on wireframes and we talked about Roles,
there were various objections and not much suggestions. I would love to
call for action and think a bit about the term for concept currently
known as Role (= Resource
On Jan 21, 2014, at 9:40 AM, Dougal Matthews dou...@redhat.com wrote:
On 21/01/14 14:19, Jaromir Coufal wrote:
when I was getting feedback on wireframes and we talked about Roles,
there were various objections and not much suggestions. I would love to
call for action and think a bit
FreeNodesView
|
+ resource/urls.py - contains ResourcesNodesView
. . . purely for the sake of navigation - seems a bit - ugly? - to me, but if
it's
acceptable by Horizon standards, then we're fine with it as well :)
Mainn
David
-Original Message-
From: Tzu-Mainn Chen [mailto:tzuma
Horizon precedent until that navigation system is ready, rather
than use our own workarounds?
Thanks in advance for any opinions!
Tzu-Mainn Chen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
Thanks! This is very informative. From a high-level perspective, this
maps well with my understanding of how Tuskar will interact with various
OpenStack services. A question or two inline:
- Original Message -
I'm trying to hash out where data will live for Tuskar (both long term
and
- Original Message -
I'm glad we are hashing this out as I think there is still some debate
around if Tuskar will need a database at all.
One thing to bear in mind, I think we need to make sure the terminology
matches that described in the previous thread. I think it mostly does
- Original Message -
On Thu, 2014-01-09 at 16:02 -0500, Tzu-Mainn Chen wrote: There are a
number of other models in the tuskar code[1], do we need to
consider these now too?
[1]:
https://github.com/openstack/tuskar/blob/master/tuskar/db/sqlalchemy/models.py
Nope
- Original Message -
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
+1 to this!
- Original Message -
So after a lot of consideration, my opinion is the two code bases should stay
in separate repos under the Horizon Program, for a few reasons:
-Adding a large chunk of code for an incubated project is likely going to
cause the Horizon delivery some
On 2013/13/12 23:11, Jordan OMara wrote:
On 13/12/13 16:20 +1300, Robert Collins wrote:
However, on instance - 'instance' is a very well defined term in Nova
and thus OpenStack: Nova boot gets you an instance, nova delete gets
rid of an instance, nova rebuild recreates it, etc. Instances
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 display in the UI?
Mainn
- Original Message -
Thanks everybody for your feedback.
Nice list! Questions and comments in-line:
- Original Message -
Hey folks,
after a bit longer but very useful discussion about requirements (almost
60 e-mails so far) I think we need to get to some conclusion what to
deliver in Icehouse, what are the steps and what we should
Nice list! Questions and comments in-line:
- Original Message -
Hey folks,
after a bit longer but very useful discussion about requirements (almost
60 e-mails so far) I think we need to get to some conclusion what to
deliver in Icehouse, what are the steps and what we should
On 12.12.2013 17:10, Mark McLoughlin wrote:
On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned
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 display in the UI?
Mainn
We start easy
Thanks for the reply! Let me try and address one particular section for now,
since it seems to be the part causing the most confusion:
* SERVICE CLASS - a further categorization within a service role for a
particular deployment.
* NODE PROFILE - a set of requirements
Thanks for all the replies so far! Let me try and distill the thread down to
the points of
interest and contention:
1) NODE vs INSTANCE
This is a distinction that Robert brings up, and I think it's a good one that
people agree
with. The various ROLES can apply to either.
What isn't clear to
Thanks for writing this all out!
- Original Message -
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
On 2013/10/12 19:39, Tzu-Mainn Chen wrote:
Ideally, we don't. But with this approach we would take out the
possibility to change something or decide something from the user.
The 'easiest' way is to support bigger companies with huge deployments,
tailored infrastructure, everything
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 talking about the same thing :) I'm copying responses from the
requirements thread
and combining them with current requirements to try and create a unified view.
Hopefully,
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 talking about the same thing :) I'm copying responses from
the requirements thread
and combining them with current requirements to try and create a unified
view.
Thanks for the reply! Comments in-line:
The disagreement comes from whether we need manual node assignment or not.
I would argue that we
need to step back and take a look at the real use case: heterogeneous
nodes. If there are literally
no characteristics that differentiate nodes A
- As an infrastructure administrator, Anna wants to be able to unallocate a
node from a deployment.
Why? Whats her motivation. One plausible one for me is 'a machine
needs to be serviced so Anna wants to remove it from the deployment to
avoid causing user visible downtime.' So
-
On 10 December 2013 09:55, Tzu-Mainn Chen tzuma...@redhat.com wrote:
* created as part of undercloud install process
By that note I meant, that Nodes are not resources, Resource instances
run on Nodes. Nodes are the generic pool of hardware we can deploy
things onto.
I
functional tests in Tempest as quickly as
possible: this is crucial for when we start 'Integration'.
Cheers,
Rob
On 7 December 2013 04:37, Tzu-Mainn Chen tzuma...@redhat.com wrote:
Hey all,
We're starting to work on the UI for tuskar based on Jarda's wireframes,
and as we're doing
by having
well-documented expectations of what the API
would provide. We would then mock those calls in the UI, replacing them with
real API calls as they became available. Is
this acceptable?
If there are precedents for this kind of stuff, we'd be more than happy to
follow them!
Thanks,
Tzu-Mainn
b) In the past, we allowed parallel development of the UI and API by
having well-documented expectations of what the API
Are these expectations documented yet? I'm new to the project and still
finding my way around. I've seen the wireframes and am going through
Chen's icehouse
Thanks for the comments! Responses inline:
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
5, 2013, at 9:31 PM, Tzu-Mainn Chen tzuma...@redhat.com wrote:
Hey all,
I've attempted to spin out the requirements behind Jarda's excellent
wireframes
(http://lists.openstack.org/pipermail/openstack-dev/2013-December/020944.html).
Hopefully this can add some perspective on both
- requirements, user stories, wireframes, etc - so it's
easier to see the whole planning picture.
Mainn
- Original Message -
On Dec 5, 2013, at 9:31 PM, Tzu-Mainn Chen tzuma...@redhat.com wrote:
Hey all,
I've attempted to spin out the requirements behind Jarda's excellent
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 Icehouse, unless marked
otherwise:
(M) - Maybe
are welcome!
Thanks,
Tzu-Mainn Chen
*** Requirements are assumed to be targeted for Icehouse, unless marked
otherwise:
(M) - Maybe Icehouse, dependency on other in-development features
(F) - Future requirement, after Icehouse
* NODES
* Creation
* Manual
Hey folks,
I opened 2 issues on UX discussion forum with TripleO UI topics:
Resource Management:
http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/
- this section was already reviewed before, there is not much surprises, just
smaller updates
- we are about to
I think we may all be approaching the planning of this project in the wrong
way, because of confusions such as:
Well, I think there is one small misunderstanding. I've never said that
manual way should be primary workflow for us. I agree that we should lean
toward as much automation and
in reviewing
the UI patches.
Thanks,
Tzu-Mainn Chen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hey all,
To assist with the naming and revoting, Matt and I put together a glossary and
a diagram with our understanding of the terms:
https://wiki.openstack.org/wiki/Tuskar/Glossary
http://ma.ttwagner.com/tuskar-diagram-draft/
Thanks,
Tzu-Mainn Chen
- Original Message -
Hey buddies
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,
87 matches
Mail list logo
