Re: [openstack-dev] [tripleo] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core

2017-12-14 Thread Ana Krivokapic
Gaël has been added to the validations core team. Welcome!

On Fri, Dec 8, 2017 at 6:56 PM, Alex Schultz <aschu...@redhat.com> wrote:

> +1
>
> On Thu, Dec 7, 2017 at 7:34 AM, Ana Krivokapic <akriv...@redhat.com>
> wrote:
> > Hey TripleO devs,
> >
> > Gaël has consistently been contributing high quality reviews and patches
> to
> > the tripleo-validations project. The project would highly benefit from
> his
> > addition to the core reviewer team.
> >
> > Assuming that there are no objections, we will add Gaël to the core team
> > next week.
> >
> > Thanks!
> >
> > --
> > Regards,
> > Ana Krivokapic
> > Senior Software Engineer
> > OpenStack team
> > Red Hat Inc.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tripleo] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core

2017-12-07 Thread Ana Krivokapic
Hey TripleO devs,

Gaël has consistently been contributing high quality reviews and patches to
the tripleo-validations project. The project would highly benefit from his
addition to the core reviewer team.

Assuming that there are no objections, we will add Gaël to the core team
next week.

Thanks!

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tripleo] Facilitating automation testing in TripleO UI

2017-08-03 Thread Ana Krivokapic
Hi TripleO devs,

In our effort to make the TripleO UI code friendlier to automation
testing[1], there is an open review[2] for which we seem to have some
difficulty reaching the consensus on how best to proceed. There is already
a discussion happening on the review itself, and I'd like to move it here,
rather than having it in a Gerrit review.

The tricky part is around adding HTML element ids to the Nodes page. This
page is generated by looping through the list of registered nodes and
displaying complete information about each of them. Because of this, many
of the elements are repeating on the page (CPU info, BIOS, power state,
etc, for each node). We need to figure out how to make these elements easy
for the automation testing code to access, both in terms of locating a
single group within the page, as well as distinguishing the individual
elements of a group from each other. There are several approaches that
we've come up so far:

1) Add unique IDs to all the elements. Generate unique `id` html attributes
by including the node UUID in the value of the `id` attribute. Do this for
both the higher level elements (divs that hold all the information about a
single node), as well as the lower level (the ones that hold info about
BIOS, CPU, etc). The disadvantage of this approach is cluttering the UI
codebase with many `id` attributes that would otherwise not be needed.

2) Add CSS classes instead of IDs. Pros for this approach: no need to
generate the clumsy ids containing the node UUID, since the CSS classes
don't need to be unique. Cons: we would be adding even more classes to HTML
elements, many of which are already cluttered with many classes. Also,
these classes would not exist anywhere in CSS or serve any other purpose.

3) Add custom HTML attributes. These usually start with the 'data-' prefix,
and would not need to be unique either. Pros: avoids the problems described
with both approaches above. Cons: AFAIU, the React framework could have
problems with custom attributes (Jirka can probably explain this better).
Also, casual readers of the code could be confused about the purpose of
these attributes, since no other code present in the UI codebase is using
them in any way.


It seems that a perfectly optimal solution does not exist here and we will
have to compromise on some level. Let's try and figure out what the best
course of action here is.

[1] https://blueprints.launchpad.net/tripleo/+spec/testing-ids
[2] https://review.openstack.org/#/c/483039/

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] Plan description in the create/update plan form

2017-06-29 Thread Ana Krivokapic
Resending with the [tripleo] tag, sorry...

On Thu, Jun 29, 2017 at 2:22 PM, Ana Krivokapic <akriv...@redhat.com> wrote:

> Hi TripleO devs,
>
> I am working on adding a description field to the "Crate Plan" form in the
> TripleO UI [1]. The goal is to make it possible for the user to specify a
> plan description using a form field when creating a plan. As the plan
> description lives in the plan-environment.yaml file[2], the idea is to
> retrieve this value from plan-environment.yaml when the user uploads the
> plan, populate the form field with it, let the user change it, and then
> save it back to the file.
>
> I have a WIP patch up [3] which solves the issue in the case of uploading
> the plan as a folder. However, I am having a hard time solving the case of
> uploading the plan as a tarball. The issue is obviously with accessing the
> contents of the tarball. Here are some possible approaches that come to
> mind:
>
> 1) Use one of the existing third-party JS libraries that can extract a
> tarball in the browser. Pros: front-end only solution, no need for
> additional API calls, no need for back-end changes. Cons: adding a new
> dependency, these libraries don't seem much maintained.
>
> 2) Use swift to upload and extract the tarball. Pros: no need for back-end
> changes, we can just call the swift API. Cons: splitting the tarball upload
> from plan creation, which should really be one atomic operation.
>
> 3) Modify the plan create workflow to accept a plan description as a
> parameter. Pros: keeps plan creation atomic. Cons: changes to the plan
> create workflow interface needed. Also this way there is no way to send
> back the information about the description to the UI, we would have to just
> accept the value of the form field, and overwrite whatever was in the
> plan-environment.yaml file.
>
> Of course there is also a fourth option:
>
> 4) This is not worth the effort to implement and we should just drop it. :)
>
> My personal opinion is that the cons of 1) and 2) make these approaches
> unacceptable. The cons of 3) make it kind of not worth it - seems like a
> lot of work for a partial solution. So I'm leaning towards 4) at the moment.
>
> I'd like to hear your opinions on this, is there a another/better approach
> that I'm missing? Jirka, you mentioned we could postpone this work to the
> next cycle and there are improvements that we can work on in the meantime
> which would make implementation of this feature easier?
>
> Any and all thoughts, comments, opinions are welcome.
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1698818
> [2] https://github.com/openstack/tripleo-heat-templates/blob/master/plan-
> environment.yaml#L4-L5
> [3] https://review.openstack.org/#/c/477536/
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>



-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Plan description in the create/update plan form

2017-06-29 Thread Ana Krivokapic
Hi TripleO devs,

I am working on adding a description field to the "Crate Plan" form in the
TripleO UI [1]. The goal is to make it possible for the user to specify a
plan description using a form field when creating a plan. As the plan
description lives in the plan-environment.yaml file[2], the idea is to
retrieve this value from plan-environment.yaml when the user uploads the
plan, populate the form field with it, let the user change it, and then
save it back to the file.

I have a WIP patch up [3] which solves the issue in the case of uploading
the plan as a folder. However, I am having a hard time solving the case of
uploading the plan as a tarball. The issue is obviously with accessing the
contents of the tarball. Here are some possible approaches that come to
mind:

1) Use one of the existing third-party JS libraries that can extract a
tarball in the browser. Pros: front-end only solution, no need for
additional API calls, no need for back-end changes. Cons: adding a new
dependency, these libraries don't seem much maintained.

2) Use swift to upload and extract the tarball. Pros: no need for back-end
changes, we can just call the swift API. Cons: splitting the tarball upload
from plan creation, which should really be one atomic operation.

3) Modify the plan create workflow to accept a plan description as a
parameter. Pros: keeps plan creation atomic. Cons: changes to the plan
create workflow interface needed. Also this way there is no way to send
back the information about the description to the UI, we would have to just
accept the value of the form field, and overwrite whatever was in the
plan-environment.yaml file.

Of course there is also a fourth option:

4) This is not worth the effort to implement and we should just drop it. :)

My personal opinion is that the cons of 1) and 2) make these approaches
unacceptable. The cons of 3) make it kind of not worth it - seems like a
lot of work for a partial solution. So I'm leaning towards 4) at the moment.

I'd like to hear your opinions on this, is there a another/better approach
that I'm missing? Jirka, you mentioned we could postpone this work to the
next cycle and there are improvements that we can work on in the meantime
which would make implementation of this feature easier?

Any and all thoughts, comments, opinions are welcome.

[1] https://bugs.launchpad.net/tripleo/+bug/1698818
[2]
https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml#L4-L5
[3] https://review.openstack.org/#/c/477536/

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tripleo] How to review the deployment plan import/export feature

2017-03-14 Thread Ana Krivokapic
Hi TripleO devs,

The patches ([1], [2], [3], [4]) implementing the deployment plan
import/export feature have been up for review for some time. (The
corresponding spec is at [5].) In this email, I'd like to explain how to
review this feature.

Patch [1] adds the import functionality to the create and update plan
actions in tripleo-common. Make sure your copy of the
tripleo-heat-templates includes the plan-environment.yaml[6] file. On your
undercloud, clone a local copy of the tripleo-common repo [7] and
cherry-pick the patch [1] on top of it. Then run the steps outlined at [8]
in order to install the newly cloned copy of tripleo-common. This will make
the updated actions available to Mistral. Then you can use the plan create
and plan update commands, then make sure that the contents of the
plan-environment.yaml file get correctly imported into the Mistral
environment. E.g:

  $ openstack overcloud plan create --templates
/usr/share/openstack-tripleo-heat-templates/ new_plan
  $ mistral environment-get new_plan

And similarly for plan update.

Patch [2] adds an action and a workflow for exporting deployment plans and
patch [3] adds a CLI command that triggers the workflow. You can test these
two patches together, or if you want to test only [2] you can manually
execute the Mistral workflow. For patch [2] the same instructions from
above regarding installing a new copy of tripleo-common apply. You will
also need to manually update the plan management workbook:

  $ mistral workbook-update tripleo-common/workbooks/plan_management.yaml

Please note that patch [2] depends on patch [1] - you'll need both of them
applied on your local copy of tripleo-common. As far as
python-tripleoclient goes, it is enough to simply clone a fresh copy to
your undercloud, apply patch [3] and run `python setup.py install`. This
will make the new plan export command available to you:

  $ openstack overcloud plan export new_plan

If all goes well, that should create a plan export tarball
(new_plan.tar.gz) in the directory you ran the command from. You should
check that the tarball contains all the relevant plan files, as well as the
plan-environment.yaml file whose contents should be imported from the
Mistral environment.

Finally, patch [4] integrates the plan export functionality into the
TripleO UI. You will need [1] and [2] applied on your undercloud. Then you
can cherry pick [4] on top of your tripleo-ui checkout. Access the UI,
navigate to Select Deployment -> Manage Deployments. Next to every plan,
there should now be a new Export button which you can use to test the plan
export functionality.

Hope all of this makes sense - if it does not, or you have any other
questions regarding this feature, please feel free to respond here or ping
me on IRC.

Thanks for your patience and I'll look forward to the reviews!


[1] https://review.openstack.org/#/c/414169/
[2] https://review.openstack.org/#/c/422789/
[3] https://review.openstack.org/#/c/425858/
[4] https://review.openstack.org/#/c/437676/
[5]
https://specs.openstack.org/openstack/tripleo-specs/specs/ocata/gui-plan-import-export.html
[6]
https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml
[7] https://github.com/openstack/tripleo-common
[8]
https://docs.openstack.org/developer/tripleo-common/readme.html#action-development

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] Deployment plan management efforts sync up

2017-02-02 Thread Ana Krivokapic
://specs.openstack.org/openstack/tripleo-specs/specs/
> ocata/gui-plan-import-export.html#problem-description
> > [5]
> > https://blueprints.launchpad.net/tripleo/+spec/enhance-
> plan-creation-with-plan-environment-json
> >
> >
> > -- Jirka
>
> Sounds good to me! Thanks for sharing it.
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] Deep dive session about the UI - January 12

2017-01-13 Thread Ana Krivokapic
Hi everyone,

For those who missed the deep dive, I am posting the recording [1] of the
session. Unfortunately I had screen sharing problems which prevented me to
properly cover the part about setting up the development environment during
the deep dive. To make up for this, I made a short video that walks through
this part [2].

Hope you find it useful!


[1] https://bluejeans.com/s/D6TIf/
[2] https://www.youtube.com/watch?v=1puSvUqTKzw


On Thu, Dec 15, 2016 at 11:56 AM, Ana Krivokapic <akriv...@redhat.com>
wrote:

>
>
> On Tue, Dec 13, 2016 at 5:05 PM, Emilien Macchi <emil...@redhat.com>
> wrote:
>
>> On Mon, Dec 12, 2016 at 1:30 PM, Ana Krivokapic <akriv...@redhat.com>
>> wrote:
>> > Hi Everyone,
>> >
>> > On the 12th of January 2017, I'll lead a TripleO deep dive[1] session
>> on how
>> > to contribute to the TripleO UI. Hope to see many of you there!
>>
>> That's awesome! Thanks for this work.
>> Is there some requirements that we should prepare? (e.g. having an
>> undercloud ready, etc).
>>
>
> Good question. Yes, I will start with an installed undercloud and go from
> there. A virt setup with all the default options is perfectly fine.
> Basically, one would need to follow the TripleO docs [1] up to and
> including "Undercloud Installation". l also recommend looking at Trown's
> excellent deep dive[2] on how to set up a development environment.
>
>
>> Is it a presentation or/and Hands-On?
>>
>
> My idea was to have a short intro segment where I would do a quick
> high-level overview on the TripleO UI. Then I would dive into the specifics
> about setting a up a dev environment for the UI development, and maybe even
> submit a simple patch for review as part of this. I suppose the audience
> could follow along, although I think it would be easier to just watch me do
> it and then replicate the steps later (with the help of the video and/or
> developer docs). At the end, we will have a special guest Liz Blanchard
> talk about how to contribute designs to the UI.
>
> I started an etherpad[3] with the agenda for the deep dive (still very
> much WIP).
>
> If anyone has any ideas about other things that they would like to see
> included, please by all means let me know. The outline above is just my
> idea of what could be included. We have plenty of time to add other things
> to the list, if people would find them useful. One point though, I did want
> to keep it more about how to contribute, as opposed to how to *use* the UI
> (developer perspective vs user perspective). The latter is a subject that
> would IMO deserve a whole separate session.
>
>
>>
>> Also, I propose that we record it as we did for the previous sessions,
>> so anyone can watch it again.
>>
>
> Absolutely, great idea.
>
>
>>
>> Thanks again.
>>
>> >
>> > [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
>> >
>> > --
>> > Regards,
>> > Ana Krivokapic
>> > Senior Software Engineer
>> > OpenStack team
>> > Red Hat Inc.
>> >
>> --
>> Emilien Macchi
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> [1] http://docs.openstack.org/developer/tripleo-docs/index.html
> [2] https://www.youtube.com/watch?v=E1d_RmysnA8
> [3] https://etherpad.openstack.org/p/tripleo-deep-dive-ui
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>



-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tripleo] Reminder: TripleO deep dive "how to contribute to the tripleo ui" starts in 2 hours

2017-01-12 Thread Ana Krivokapic
Hope to see many of you there!

https://etherpad.openstack.org/p/tripleo-deep-dive-ui


-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] Deep dive session about the UI - January 12

2016-12-15 Thread Ana Krivokapic
On Tue, Dec 13, 2016 at 5:05 PM, Emilien Macchi <emil...@redhat.com> wrote:

> On Mon, Dec 12, 2016 at 1:30 PM, Ana Krivokapic <akriv...@redhat.com>
> wrote:
> > Hi Everyone,
> >
> > On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on
> how
> > to contribute to the TripleO UI. Hope to see many of you there!
>
> That's awesome! Thanks for this work.
> Is there some requirements that we should prepare? (e.g. having an
> undercloud ready, etc).
>

Good question. Yes, I will start with an installed undercloud and go from
there. A virt setup with all the default options is perfectly fine.
Basically, one would need to follow the TripleO docs [1] up to and
including "Undercloud Installation". l also recommend looking at Trown's
excellent deep dive[2] on how to set up a development environment.


> Is it a presentation or/and Hands-On?
>

My idea was to have a short intro segment where I would do a quick
high-level overview on the TripleO UI. Then I would dive into the specifics
about setting a up a dev environment for the UI development, and maybe even
submit a simple patch for review as part of this. I suppose the audience
could follow along, although I think it would be easier to just watch me do
it and then replicate the steps later (with the help of the video and/or
developer docs). At the end, we will have a special guest Liz Blanchard
talk about how to contribute designs to the UI.

I started an etherpad[3] with the agenda for the deep dive (still very much
WIP).

If anyone has any ideas about other things that they would like to see
included, please by all means let me know. The outline above is just my
idea of what could be included. We have plenty of time to add other things
to the list, if people would find them useful. One point though, I did want
to keep it more about how to contribute, as opposed to how to *use* the UI
(developer perspective vs user perspective). The latter is a subject that
would IMO deserve a whole separate session.


>
> Also, I propose that we record it as we did for the previous sessions,
> so anyone can watch it again.
>

Absolutely, great idea.


>
> Thanks again.
>
> >
> > [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
> >
> > --
> > Regards,
> > Ana Krivokapic
> > Senior Software Engineer
> > OpenStack team
> > Red Hat Inc.
> >
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

[1] http://docs.openstack.org/developer/tripleo-docs/index.html
[2] https://www.youtube.com/watch?v=E1d_RmysnA8
[3] https://etherpad.openstack.org/p/tripleo-deep-dive-ui

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] Deep dive session about the UI - January 12

2016-12-13 Thread Ana Krivokapic
On Mon, Dec 12, 2016 at 7:30 PM, Ana Krivokapic <akriv...@redhat.com> wrote:

> Hi Everyone,
>
> On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on
> how to contribute to the TripleO UI. Hope to see many of you there!
>
>
> [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>

If you'd like a calendar invite for this deep dive, email me and I'll add
you to the meeting invite.


-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tripleo] Deep dive session about the UI - January 12

2016-12-12 Thread Ana Krivokapic
Hi Everyone,

On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on
how to contribute to the TripleO UI. Hope to see many of you there!


[1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] Your draft logo & a sneak peek

2016-10-25 Thread Ana Krivokapic
On Tue, Oct 25, 2016 at 2:28 PM, Ryan Brady <rbr...@redhat.com> wrote:

>
>
> On Tue, Oct 25, 2016 at 5:55 AM, Steven Hardy <sha...@redhat.com> wrote:
>
>> Hi team,
>>
>> I recently received a draft version of our project logo, using the mascot
>> we selected together. A final version (and some cool swag) will be ready
>> for us before the Project Team Gathering in February. Before they make our
>> logo final, they want to be sure we're happy with our mascot.
>>
>> We can discuss any concerns in Barcelona and you can also provide direct
>> feedback to the designers: http://tinyurl.com/OSmascot . Logo feedback is
>> due Friday, Nov. 11.
>
>
> I feel the logo draft is missing a lot of the detail and fidelity of our
> current logo.
> The draft logo has lines that are much too thick especially in the face
> area.  It's
> recognizable from a shorter distance than our current logo.
>
> Our current logo has more of a cartoon / angry birds type feel to it -
> something
> with personality.  To me, the draft logo is devoid of personality. I
> understand why
> the foundation wants to have more consistency between logos, but I'm hoping
> this isn't the final design approach.
>
> - Ryan
>

Can't help but agree with Ryan here. This is definite step down from our
current logo. :\



>
>
>
>
>> To get a sense of how ours stacks up to others, check out this sneak
>> preview of several dozen draft logos from our community:
>> https://youtu.be/JmMTCWyY8Y4.
>>
>> The only comment I have made is this logo does lose some of the OoO
>> imagery
>> we had with the previous owl version - please feel free to provide
>> feedback
>> of your own via the url above, thanks!
>>
>> Thanks!
>>
>> Steve
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tripleo] Demo: Deploying OpenStack using TripleO UI

2016-10-21 Thread Ana Krivokapic
I'd like to share a demo video of the current state of TripleO UI:

https://www.youtube.com/watch?v=01yta_1FKaQ

P.S. Please note that some of the validations are failing due to physical
limitations (low disk space, etc) of the virtual test setup I used to make
this video.

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [TripleO] Announcing TripleO UI

2016-03-23 Thread Ana Krivokapic
Hi All,

I am very pleased to inform you that, as of yesterday, TripleO UI is
part of upstream OpenStack, under the TripleO program.

If you'd like to learn more about TripleO UI, please read the spec
[1]. The code repo [2], bug tracker [3], and review queue [4] are in
usual places.

TripleO UI devs are hanging out in #tripleo on Freenode, with the rest
of the TripleO team.

We are looking forward to growing a community around this exciting new project!



[1] 
https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka/tripleo-ui.html
[2] https://git.openstack.org/cgit/openstack/tripleo-ui/
[3] https://launchpad.net/tripleo-ui
[4] https://review.openstack.org/#/q/project:openstack/tripleo-ui+status:open

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2016-02-29 Thread Ana Krivokapic
On Mon, Feb 29, 2016 at 4:27 PM, Dan Prince <dpri...@redhat.com> 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 specific patches.

Thanks, I think this makes perfect sense!

>
> I'd like to proposed we add Jiri Tomasek and Ana Krivokapic as core
> candidates that will focus primarily on the UI. They would be added to
> tripleo core but would agree to only +2 patches within the UI for now,
> or at least until they are re-nominated for more general TripleO core,
> etc.

I'd like to suggest Florian Fuchs instead of myself, as he has far
more contributions (both commits and reviews) to the UI project (such
as it is so far, [1]) then I do.

>
> Core members if you could please vote on this so we can add these
> members at the close of this week. Thanks,
>
> Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[1] https://github.com/rdo-management/rdo-director-ui/graphs/contributors

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [TripleO] TripleO UI

2015-12-08 Thread Ana Krivokapic
Hi All,

In this email[1], Tzu-Mainn summarized recent developments in TripleO
regarding the workflow library and the REST API. I'd like to complement
that email with some information about the future TripleO UI.

The new REST API aims to unify the deployment workflow and has the tripleo
client[2] as the only current (CLI) consumer. I wrote a spec[3] to propose
adding TripleoO UI, as another (GUI) consumer of the TripleO REST API. The
idea is that TripleO UI should provide an alternative way of deploying an
overcloud via TripleO, while offering the same capabilities that the CLI
does. The spec contains all the information about introducing a new GUI,
including the rationale behind shifting the focus from Tuskar-UI to this
new GUI.

The current location of the TripleO UI code repo is [4]. Note that it is
still WIP and not fully capable of doing a deployment just yet.


[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081327.html
[2] https://github.com/openstack/python-tripleoclient
[3] https://review.openstack.org/#/c/239056
[4] https://github.com/rdo-management/rdo-director-ui

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon]

2014-11-25 Thread Ana Krivokapic

On 25/11/14 00:09, David Lyle wrote:
 I am pleased to nominate Thai Tran and Cindy Lu to horizon-core. 

 Both Thai and Cindy have been contributing significant numbers of high
 quality reviews during Juno and Kilo cycles. They are consistently
 among the top non-core reviewers. They are also responsible for a
 significant number of patches to Horizon. Both have a strong
 understanding of the Horizon code base and the direction of the project.

 Horizon core team members please vote +1 or -1 to the
 nominations either in reply or by private communication. Voting will
 close on Friday unless I hear from everyone before that.

 Thanks,
 David



+1 for both.

Cindy and Thai, thanks for your hard work!

-- 
Regards,

Ana Krivokapic
Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Horizon] Template Blueprint

2014-10-17 Thread Ana Krivokapic

Hello Horizoners,

I would like to draw your attention to the excellent Template 
Blueprint[1] which David created. The aim of this is to create a 
template which will be used for all future blueprints. This way we can 
try to ensure that enough information/detail is provided in blueprints, 
as we have had problems with blueprints lacking in details in the past.


Please take a minute to review [1] and add your comments to the 
whiteboard. We are hoping to finalize this and starting using this 
template ASAP.


Thanks!


[1] https://blueprints.launchpad.net/horizon/+spec/template

--
Regards,

Ana Krivokapic
Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] Specs repo

2014-06-16 Thread Ana Krivokapic

On 06/11/2014 05:22 PM, Jason Rist wrote:
 On Wed 11 Jun 2014 06:54:53 AM MDT, Ana Krivokapic wrote:
 Hi Horizoners,

 A lot of other projects have already adopted and started using a specs
 repo. Do we want to have one for Horizon?

 I'm still not quite clear how this works, but I'm open to it if it 
 makes things a little nicer.


Basically, specs repos are meant to hold specs - design documents of
sorts. They are used to describe and discuss the implementation design
of a particular feature. In other words, we would use the existing
Gerrit infrastructure to review blueprints. For more detailed
information, please see past mailing list threads [1], [2], and e.g.
nova-specs repo description [3].

Here are a few pros and cons with regard to having a specs repo. These
are just the ones that were the most obvious to me; feel free to add
your own.

Pros:
* This process makes sure implementation design for a feature happens
_before_ the actual implementation. This is very important as it
potentially saves developers from wasting a lot of time implementing a
feature in a suboptimal way.
* By making reviewers explicitly focus on the more essential aspects of
a feature design, we make sure that the feature gets a better/more
efficient implementation.
* We will have a feature design recorded for posterity. I don't think I
need to explain how useful this can be.

Cons:
* Shifting effort to talking about doing the work from actually doing
the work. I guess we need to make sure reviews are useful and
constructive and keep the process from becoming endless bike shedding.
* Obviously, it will take more time and effort to get features/patches
merged.

Personally, I am *for* adding a specs repo for Horizon, as long as we
put extra effort to minimize the cons listed above.

Thoughts, comments welcome!


[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030851.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030102.html
[3] https://github.com/openstack/nova-specs

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Horizon] Specs repo

2014-06-11 Thread Ana Krivokapic
Hi Horizoners,

A lot of other projects have already adopted and started using a specs
repo. Do we want to have one for Horizon?

-- 
Regards,

Ana Krivokapic
Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon] Help debugging js files

2014-06-06 Thread Ana Krivokapic

On 06/06/2014 05:39 PM, Abishek Subramanian (absubram) wrote:
 Hi,

 I need to make some changes to the horizon.instances.js file and I was
 wondering what the best method would be to help debug issues in this
 file? Is there a debugger or something available to debug this file
 separately?

 Thanks!
 Abishek

Hi Abishek,

A couple of debugging tips with regard to Horizon frond-end development:

* Use Chrome's Developer Tools or Firefox's Firebug plugin. They include
very powerful tools including a debugger, a console, the ability to edit
static files on the fly, etc.

* Put COMPRESS_ENABLED = False into your local_settings.py to disable
automatic compression of static files. This will help you see which
files the errors are actually occurring in.

* If you are using devstack or similar for your development environment,
use Django's built-in web server, rather than a full fledged web server
like Apache. It will make your life much easier - you will not have to
run collectstatic after changing static files, you will have the log
output in the console instead of having to dig through log files, etc.

HTH

-- 
Regards,

Ana Krivokapic
Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon] mocking policy

2014-06-04 Thread Ana Krivokapic

On 06/04/2014 02:41 PM, Radomir Dopieralski wrote:
 Hello,

 I'd like to start a discussion about the use of mocking libraries in
 Horizon's tests, in particular, mox and mock.

 As you may know, Mox is the library that has been used so far, and we
 have a lot of tests written using it. It is based on a similar Java
 library and does very strict checking, although its error reporting may
 leave something more to be desired.

 Mock is a more pythonic library, insluded in the stdlib of recent Python
 versions, but also available as a separate library for older pythons. It
 has a much more relaxed approach, allowing you to only test the things
 that you actually care about and to write tests that don't have to be
 rewritten after each and every refactoring.

 Some OpenStack projects, such as Nova, seem to have adopted an approach
 that favors Mock in newly written tests, but allows use of Mox for older
 tests, or when it's more suitable for the job.

 In Horizon we only use Mox, and Mock is not even in requirements.txt. I
 would like to propose to add Mock to requirements.txt and start using it
 in new tests where it makes more sense than Mox -- in particular, when
 we are writing unit tests only testing small part of the code.

 Thoughts?

Makes sense to me.

+1 for adding Mock to the requirements (test-requirements.txt rather
than requirements.txt, right?) and using it in newly written tests.

-- 
Regards,

Ana Krivokapic
Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

2014-05-28 Thread Ana Krivokapic

On 05/28/2014 02:54 PM, Radomir Dopieralski wrote:

Hello,

we plan to finally do the split in this cycle, and I started some
preparations for that. I also started to prepare a detailed plan for the
whole operation, as it seems to be a rather big endeavor.

You can view and amend the plan at the etherpad at:
https://etherpad.openstack.org/p/horizon-split-plan

It's still a little vague, but I plan to gradually get it more detailed.
All the points are up for discussion, if anybody has any good ideas or
suggestions, or can help in any way, please don't hesitate to add to
this document.

We still don't have any dates or anything -- I suppose we will work that
out soonish.

Oh, and great thanks to all the people who have helped me so far with
it, I wouldn't even dream about trying such a thing without you. Also
thanks in advance to anybody who plans to help!



This high level overview looks quite reasonable to me.

Count me in on helping out with this effort.

Thanks for driving this, Radomir!

--
Regards,

Ana Krivokapic
Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

2014-04-02 Thread Ana Krivokapic

On 04/02/2014 07:36 PM, Dougal Matthews wrote:



On my phone so I can't follow this up more now, but it looks like 
JSHint is already used.


https://review.openstack.org/#/c/41087/



That commit has since been reverted and JSHint removed from Horizon 
codebase:

https://bugs.launchpad.net/horizon/+bug/1270764
https://review.openstack.org/#/c/68268/

Seems like there's some controversy around whether the licenses are 
actually incompatible or not. How do we go about clearing that up? :)


--
Regards,

Ana Krivokapic
Associate Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core

2014-03-06 Thread Ana Krivokapic

On 03/06/2014 04:47 AM, Jason Rist wrote:
 On Wed 05 Mar 2014 03:36:22 PM MST, Lyle, David wrote:
 I'd like to nominate Radomir Dopieralski to Horizon Core.  I find his 
 reviews very insightful and more importantly have come to rely on their 
 quality. He has contributed to several areas in Horizon and he understands 
 the code base well.  Radomir is also very active in tuskar-ui both 
 contributing and reviewing.

 David

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 As someone who benefits from his insightful reviews, I second the 
 nomination.
+1

 --
 Jason E. Rist
 Senior Software Engineer
 OpenStack Management UI
 Red Hat, Inc.
 +1.720.256.3933
 Freenode: jrist
 github/identi.ca: knowncitizen

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-02-27 Thread Ana Krivokapic


On 02/27/2014 04:41 PM, Tzu-Mainn Chen wrote:

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 be done very good.

E.g calling 'openstack-client net-create' fails.
Where do you find error log?
Are you using nova-networking or Neutron?
..

Calli 'neutron net-create' and you just know.

Btw. who would actually hire a sysadmin that will start to use CLI and
have no
idea what is he doing? They need to know what each service do, how to
correctly
use them and how do debug it when something is wrong.


For flavors just use flavors, we call them flavors in code too. It has
just nicer face in UI.

Actually, don't we called them node_profiles in the UI code?


We do: 
https://github.com/openstack/tuskar-ui/tree/master/tuskar_ui/infrastructure/node_profiles

  Personally,
I'd much prefer that we call them flavors in the code.
I agree, keeping the name flavor makes perfect sense here, IMO. The 
only benefit of using node profile seems to be that it is more 
descriptive. However, as already mentioned, admins are well used to the 
name flavor. It seems to me that this change introduces more confusion 
than it serves to clear things up. In other words, it brings more harm 
than good.




Mainn

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Regards,

Ana Krivokapic
Associate Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon]

2014-01-27 Thread Ana Krivokapic


On 01/27/2014 09:10 AM, Jaromir Coufal wrote:

Awesome, thanks a lot for setting this up, David!
-- Jarda

On 2014/26/01 02:10, Lyle, David wrote:
With meeting logging now available in #openstack-meeting-3, the 
official Horizon meeting time is now Tuesdays at 1600 UTC in 
#openstack-meeting-3.


Looking forward to seeing all Horizon folks there.

David

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Thanks, David! This will make life easier for a lot of people.

--
Regards,

Ana Krivokapic
Associate Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Horizon and Tuskar-UI codebase merge

2013-12-19 Thread Ana Krivokapic
On 12/19/2013 05:32 PM, Jordan O'Mara wrote:

 - Original Message -
 So basically this is our first proposal what we send out:
 http://lists.openstack.org/pipermail/openstack-dev/2013-December/022196.html

 After Horizon meetings, several e-mails and also couple of other
 discussions of people who are for/against codebase merge, it looks that
 in the end upstream leans towards 'umbrella' solution.

 After all, +1 for umbrella solution from my side too. Tuskar UI will get
 closer to the nature of the project (based on Horizon, UI related
 audience). And in the same time, we will not rush things up before the
 project graduates. In Icehouse we can easier reach goals of both -
 Horizon as well as Tuskar UI - and after Icehouse release we can review
 back and get to the codebase merge in the end.

 Do you all agree?

 -- Jarda
 +1, I think this is the most sensible approach.

+1 from me, this approach makes perfect sense.


 On 2013/18/12 22:33, Gabriel Hurley wrote:
  From my experience, directly adding incubated projects to the main Horizon
  codebase prior to graduation has been fraught with peril. That said, the
  closer they can be together prior to the graduation merge, the better.

 I like the idea of these types of projects being under the OpenStack
 Dashboard Program umbrella. Ideally I think it would be a jointly-managed
 resource in Gerrit. The Horizon Core folks would have +2 power, but the
 Tuskar core folks would also have +2 power. (I'm 90% certain that can be
 done in the Gerrit admin...)

 That way development speed isn't bottlenecked by Horizon Core, but there's
 a closer tie-in with the people who may ultimately be maintaining it. It
 becomes easier to keep track of, and can be more easily guided in the
 right directions. With a little work incubated dashboard components like
 this could even be made to be a non-gating part of the testing
 infrastructure to indicate when things change or break.

 Adding developers to Horizon Core just for the purpose of reviewing an
 incubated umbrella project is not the right way to do things at all.  If
 my proposal of two separate groups having the +2 power in Gerrit isn't
 technically feasible then a new group should be created for management of
 umbrella projects.

 All the best,

   - Gabriel
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards,

Ana Krivokapic
Associate Software Engineer
OpenStack team
Red Hat Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev