> 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'
s point. Which is why I lean towards
> > > > > > > using a
> > > > > > > generic workflow API to accomplis the same task.
> > > > > > >
> > > > > > > I actually think rather than shielding users we should be
> > >
> 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 bunch
- 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 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 was
- 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 Mistral for
- 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 Mistral
&
oblem we're
trying to solve and find the correct architecture. For these get/set
methods that the API needs, it's 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.
Tha
> 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
- 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 i
- 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
high-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
- 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
objection 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 Deve
t workflow.
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.o
- 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 - tha
- 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,
a their custom 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 Developme
> 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?
>
> 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
and can be run for Juno-3 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" 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
at it might possibly belong in the api code. So would we just take
2) and 3) and stick it in openstack_dashboard/common/flavors/tables.py
or something. . . ?
Thanks,
Tzu-Mainn Chen
- Original Message -
> I think this falls inline with other items we are working toward in
> Hori
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
ndependently 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 intend
. 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
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
___
OpenStac
> 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,
rg/wiki/TripleO/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 deployme
> 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
> h
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 Tantsu
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
> On 1 February 2014 10:03, Tzu-Mainn Chen 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
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 hardwa
- Original Message -
> On 30 January 2014 23:26, Tomas Sedovic 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 think
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
thin the UI?
>
> -J
>
> On 01/28/2014 03:04 AM, Tzu-Mainn Chen wrote:
> > 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
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 a
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 out
- Original Message -
> On 23 January 2014 21:39, Jaromir Coufal 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
cept then.
> And I would be a bit afraid of schizophrenia...
>
>
> 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.
&g
Thanks for the update!
One question - is it possible to move the "Deploying Status" bar from page 12
to page 14?
The reason is that the former looks like a "Deployment Creation" page, while
the latter is
a "Deployment Detail" page. For me, the former is about sending parameters to
the API to
> On Jan 22, 2014, at 4:02 AM, 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 Stac
> On Jan 22, 2014, at 7:09 AM, Jaromir Coufal 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 corre
> > 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 Ove
- 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
> >>
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
> On Jan 21, 2014, at 9:40 AM, Dougal Matthews 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 about th
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 (= Res
ains IndexView
|
+ free/urls.py - contains 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
&
ncement) -
would it be preferred that
we follow 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.openst
- 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
- 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/tusk
- 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 doe
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
> an
+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 g
> 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.
> On Wed, 2013-12-11 at 17:48 +0100, Jiří Stránský wrote:
>
> > >> When you say python- clients, is there a distinction between the CLI and
> > >> a bindings library that invokes the server-side APIs? In other words,
> > >> the CLI is packaged as CLI+bindings and the UI as GUI+bindings?
> >
> > p
> Thanks Mainn, comments inline :)
>
> On Fri, 2013-12-13 at 19:31 -0500, Tzu-Mainn Chen wrote:
> > 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:
> >
> &g
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 requi
ne.
I'm not sure how the items listed below are implementation details; they seem
like scoping the requirements to me.
> On 2013/13/12 12:04, Tzu-Mainn Chen wrote:
> >> *VERSION 0*
> >> ===
> >> Enable user to deploy OpenStack with the simpli
> 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
> 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
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 co
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 co
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.
>
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
> >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
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,
> 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 t
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 loo
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 n
asses | ?
node profiles | ?
Mainn
- Original Message -
> On 10 December 2013 09:55, Tzu-Mainn Chen wrote:
> >> >* created as part of undercloud install process
>
> >> By that note I meant, that Nodes are not resources, Resource instances
> >&g
> >* created as part of undercloud install process
> >* can create additional management nodes (F)
> > * Resource nodes
> >
> > ^ nodes is again confusing layers - nodes are
> > what things are deployed to, but they aren't the entry point
> >
> > Can you,
> > - 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 downti
t sure where the JS / Horizon tests fit precisely, but again -
> lets make sure that we have 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 wrote:
> On 7 December 2013 08:15, Jay Dobies wrote:
> > 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.
>
>
> NP :)
>
>
> >> * optional node profile for a resource class (M)
> >>
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) -
lanning documents - 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 wrote:
> >
> > > Hey all,
> > >
&
--
>
> On Dec 5, 2013, at 9:31 PM, Tzu-Mainn Chen 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.htm
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
> >> 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 re
el development of the UI and API 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 h
mments 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
> 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 abou
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 sm
- Original Message -
>
> On 2013/27/11 00:00, Robert Collins wrote:
>
>
>
> On 26 November 2013 07:41, Jaromir Coufal wrote:
>
>
>
> Hey Rob,
>
> can we add 'Slick Overcloud deployment through the UI' to the list? There
> was no session about that, but we discussed it afterwords
a
lot of time involved with horizon development and blueprints. This is done so
that horizon changes can be understood and utilized by tuskar-ui.
For that reason, I feel like a UI core reviewer split here might make sense. .
. ? tuskar-ui doesn't require as many updates as tripleo/tuskar api, but a
certain level of horizon and UI expertise is definitely helpful 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
> 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
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 budd
95 matches
Mail list logo
