Re: [openstack-dev] [tripleo][ui][tempest][oooq] Refreshing plugins from git

[Honza Pokorny]

Here is an etherpad with all of the open patches that Chandan and I have
been working on.

https://etherpad.openstack.org/p/selenium-testing-ci

On 2018-10-22 18:25, Chandan kumar wrote:
> Hello Honza,
> 
> On Thu, Oct 18, 2018 at 6:15 PM Bogdan Dobrelya  wrote:
> >
> > On 10/18/18 2:17 AM, Honza Pokorny wrote:
> > > Hello folks,
> > >
> > > I'm working on the automated ui testing blueprint[1], and I think we
> > > need to change the way we ship our tempest tests.
> > >
> > > Here is where things stand at the moment:
> > >
> > > * We have a kolla image for tempest
> > > * This image contains the tempest rpm, and the openstack-tempest-all rpm
> > > * The openstack-tempest-all package in turn contains all of the
> > >openstack tempest plugins
> > > * Each of the plugins is shipped as an rpm
> > >
> > > So, in order for a new test in tempest-tripleo-ui to appear in CI we
> > > have to go through at least the following tests:
> > >
> > > * New tempest-tripleo-ui rpm
> > > * New openstack-tempest-all rpm
> > > * New tempest kolla image
> > >
> > > This could easily take a week, if not more.
> > >
> > > What I would like to build is something like the following:
> > >
> > > * Add an option to the tempest-setup.sh script in tripleo-quickstart to
> > >refresh all tempest plugins from git before running any tests
> > > * Optionally specify a zuul change for any of the plugins being
> > >refreshed
> > > * Hook up the test job to patches in tripleo-ui (which tests in
> > >tempest-tripleo-ui are testing) so that I can run a fix and its test
> > >in a single CI job
> 
> I have added a patch in TripleO Quickstart extras Validate-tempest
> role: https://review.openstack.org/#/c/612377/ to install any tempest
> plugin from git and zuul will pick
> the specific change in the gates.
> Here is the patch on how to test it with FS: 
> https://review.openstack.org/612386
> Basically in any FS, we can add following lines
> tempest_format: venv
> tempest_plugins_git:
>- 'https://git.openstack.org/openstack/tempest-tripleo-ui.git'
> the respective FS related job will install the tempest plugin and we
> can also use test_white_regex:  to
> trigger the tempest tests.
> 
> I think it will solve the problem.
> 
> Thanks
> 
> Chandan Kumar
> 
> __
> 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

[openstack-dev] [tripleo][ui][tempest][oooq] Refreshing plugins from git

[Honza Pokorny]

Hello folks,

I'm working on the automated ui testing blueprint[1], and I think we
need to change the way we ship our tempest tests.

Here is where things stand at the moment:

* We have a kolla image for tempest
* This image contains the tempest rpm, and the openstack-tempest-all rpm
* The openstack-tempest-all package in turn contains all of the
  openstack tempest plugins
* Each of the plugins is shipped as an rpm

So, in order for a new test in tempest-tripleo-ui to appear in CI we
have to go through at least the following tests:

* New tempest-tripleo-ui rpm
* New openstack-tempest-all rpm
* New tempest kolla image

This could easily take a week, if not more.

What I would like to build is something like the following:

* Add an option to the tempest-setup.sh script in tripleo-quickstart to
  refresh all tempest plugins from git before running any tests
* Optionally specify a zuul change for any of the plugins being
  refreshed
* Hook up the test job to patches in tripleo-ui (which tests in
  tempest-tripleo-ui are testing) so that I can run a fix and its test
  in a single CI job

This would allow the tripleo-ui team to develop code and tests at the
same time, and prevent breakage before a patch is even merged.

Here are a few questions:

* Do you think this is a good idea?
* Could we accomplish this by some other, simple mechanism?

Any helpful suggestions, corrections, and feedback are much appreciated.

Thanks

Honza Pokorny

[1]: https://blueprints.launchpad.net/tripleo/+spec/automated-ui-testing 

__
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] quickstart for humans

[Honza Pokorny]

On 2018-08-31 13:17, Dougal Matthews wrote:
> On 31 August 2018 at 12:11, Steven Hardy  wrote:
> 
> > On Thu, Aug 30, 2018 at 3:28 PM, Honza Pokorny  wrote:
> > > Hello!
> > >
> > > Over the last few months, it seems that tripleo-quickstart has evolved
> > > into a CI tool.  It's primarily used by computers, and not humans.
> > > tripleo-quickstart is a helpful set of ansible playbooks, and a
> > > collection of feature sets.  However, it's become less useful for
> > > setting up development environments by humans.  For example, devmode.sh
> > > was recently deprecated without a user-friendly replacement. Moreover,
> > > during some informal irc conversations in #oooq, some developers even
> > > mentioned the plan to merge tripleo-quickstart and tripleo-ci.
> >
> > I was recently directed to the reproducer-quickstart.sh script that's
> > written in the logs directory for all oooq CI jobs - does that help as
> > a replacement for the previous devmode interface?
> >
> > Not that familiar with it myself but it seems to target many of the
> > use-cases you mention e.g uniform reproducer for issues, potentially
> > quicker way to replicate CI results?
> >
> 
> It is very good for that. However, the problem I have with reproducer
> scripts is that they are tied to the CI output. If I am working on a patch,
> the only way I know to get a reproducer is to submit the patch and then
> wait for CI to finish and then run the script again myself.
> 
> It would be very useful if I there was a tool where I could run a specific
> CI job, with a gerrit patch included (or even a local change would be more
> amazing!). Perhaps even a reproducer script generator would do the job.
> 

Yes, the reproducer seems to work quite well.  It's just not very
user-friendly.  The issue is that you need to find the right CI job, go
to the logs, download the file, etc. Instead of simply cloning a repo,
installing the tool, and running it when needed.

As such, we already have a couple of patches to introduce a reproducer
script generator.  One by me, and one by Gabriele.

https://review.openstack.org/#/c/586843/
https://review.openstack.org/#/c/548005/

> 
> 
> 
> >
> > Steve
> >
> > __
> > 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


__
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] quickstart for humans

[Honza Pokorny]

Hello!

Over the last few months, it seems that tripleo-quickstart has evolved
into a CI tool.  It's primarily used by computers, and not humans.
tripleo-quickstart is a helpful set of ansible playbooks, and a
collection of feature sets.  However, it's become less useful for
setting up development environments by humans.  For example, devmode.sh
was recently deprecated without a user-friendly replacement. Moreover,
during some informal irc conversations in #oooq, some developers even
mentioned the plan to merge tripleo-quickstart and tripleo-ci.

I think it would be beneficial to create a set of defaults for
tripleo-quickstart that can be used to spin up new environments; a set
of defaults for humans.  This can either be a well-maintained script in
tripleo-quickstart itself, or a brand new project, e.g.
tripleo-quickstart-humans.  The number of settings, knobs, and flags
should be kept to a minimum.

This would accomplish two goals:

1.  It would bring uniformity to the team.  Each environment is
installed the same way.  When something goes wrong, we can
eliminate differences in setup when debugging.  This should save a
lot of time.

2.  Quicker and more reliable environment setup.  If the set of defaults
is used by many people, it should container fewer bugs because more
people using something should translate into more bug reports, and
more bug fixes.

These thoughts are coming from the context of tripleo-ui development.  I
need an environment in order to develop, but I don't necessarily always
care about how it's installed.  I want something that works for most
scenarios.

What do you think?  Does this make sense?  Does something like this
already exist?

Thanks for listening!

Honza

__
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][ui] Dependency management

[Honza Pokorny]

We've recently discovered an issue with the way we handle dependencies for
tripleo-ui.  This is an explanation of the problem, and a proposed solution.
I'm looking for feedback.

Before the upgrade to zuul v3 in TripleO CI, we had two types of jobs for
tripleo-ui:

* Native npm jobs
* Undercloud integration jobs

After the upgrade, the integration jobs went away.  Our goal is to add them
back.

There is a difference in how these two types of jobs handle dependencies.
Native npm jobs use the "npm install" command to acquire packages, and
undercloud jobs use RPMs.  The tripleo-ui project uses a separate RPM for
dependencies called openstack-tripleo-ui-deps.

Because of the requirement to use a separate RPM for dependencies, there is some
extra work needed when a new dependency is introduced, or an existing one is
upgraded.  Once the patch that introduces the dependency is merged, we have to
increment the version of the -deps package, and rebuild it.  It then shows up in
the yum repos used by the undercloud.

To make matters worse, we recently upgraded our infrastructure to nodejs 8.9.4
and npm 5.6.0 (latest stable).  This makes it so we can't write "purist" patches
that simply introduce a new dependency to package.json, and nothing more.  The
code that uses the new dependency must be included.  I tend to think that each
commit should work on its own so this can be seen as a plus.

This presents a problem: you can't get a patch that introduces a new dependency
merged because it's not included in the RPM needed by the undercloud ci job.

So, here is a proposal on how that might work:

1. Submit a patch for review that introduces the dependency, along with code
   changes to support it and validate its inclusion
2. Native npm jobs will pass
3. Undercloud gate job will fail because the dependency isn't in -deps RPM 
4. We ask RDO to review for licensing
5. Once reviewed, new -deps package is built
6. Recheck
7. All jobs pass

There is the obvious issue with building an RPM based on an unmerged patch.

What do you think?  Is that possible?  Any other solutions?

Honza Pokorny

__
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] [Release-job-failures] Release of openstack/tripleo-ui failed

[Honza Pokorny]

I'm investigating on behalf of the tripleo-ui team.  It looks like the
definition for the jobs changed under us, and we'll need to update our
configuration.  I'll track it down.

For the time being, though, we can safely ignore this issue.  As
indicated, the publish-openstack-javascript-tarball job succeeded.  I
checked the tarballs listing, and the file is in fact present.  Our
project doesn't produce any other release artifacts upstream.

Please direct any future failures to me (in addition to the mailing list
of course)

Thanks

Honza Pokorny

On 2017-11-21 21:34, Emilien Macchi wrote:
> Indeed, adding Jason in copy.
> 
> Do we actually need release-openstack-javascript job?
> 
> On Tue, Nov 21, 2017 at 8:27 PM, Tony Breeds <t...@bakeyournoodle.com> wrote:
> > On Wed, Nov 22, 2017 at 03:07:33AM +, z...@openstack.org wrote:
> >> Build failed.
> >>
> >> - publish-openstack-javascript-tarball 
> >> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/publish-openstack-javascript-tarball/9908482/
> >>  : SUCCESS in 4m 58s
> >> - release-openstack-javascript 
> >> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/
> >>  : POST_FAILURE in 6m 37s
> >> - announce-release announce-release : SKIPPED
> >
> > I'm not certain what went wrong here but [1] looks problematic
> >
> > Yours Tony.
> >
> > [1] 
> > http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/job-output.txt.gz#_2017-11-22_03_01_48_750499
> >
> > ___
> > Release-job-failures mailing list
> > release-job-failu...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
> 
> 
> 
> -- 
> 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

__
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 akrivoka for tripleo-validations core

[Honza Pokorny]

Hello people,

I would like to nominate Ana Krivokapić (akrivoka) for the core team for
tripleo-validations.  She has really stepped up her game on that project
in terms of helpful reviews, and great patches.

With Ana's help as a core, we can get more done, and innovate faster.

If there are no objections within a week, we'll proceed with adding Ana
to the team.

Thanks

Honza Pokorny

__
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] TripleO UI and CLI feature parity

[Honza Pokorny]

On 2017-09-13 12:45, Dan Prince wrote:
> On Tue, Sep 12, 2017 at 9:58 PM, Jiri Tomasek  wrote:
> 
> > Hello all,
> >
> > As we are in the planning phase for Queens cycle, I'd like to open the
> > discussion on the topic of CLI (tripleoclient) and GUI (tripleo-ui) feature
> > parity.
> >
> > Two years ago, when TripleO UI was started, it was agreed that in order to
> > provide API for GUI and to achieve compatibility between GUI and CLI, the
> > TripleO business logic gets extracted from tripleoclient into
> > tripleo-common library and it will be provided through Mistral actions and
> > workflows so GUI and other potential clients can use it.
> >
> > The problem:
> >
> > Currently we are facing a recurring problem that when a new feature is
> > added to TripleO it often gets a correctly implemented business logic in
> > form of utility functions in tripleo-common but those are then used
> > directly by tripleoclient. At this point the feature is considered complete
> > as it is integrated in CLI and passes CI tests. The consequences of this
> > approach are:
> >
> > - there is no API for the new feature, so the feature is only usable by CLI
> > - part of the business logic still lives in tripleoclient
> > - GUI can not support the feature and gets behind CLI capabilities
> > - GUI contributors need to identify the new feature, raise bugs [1],
> > feature then gets API support in tripleo-common
> > - API implementation is not tested in CI
> > - GUI and CLI diverges in how that feature is operated as business logic
> > is implemented twice, which has number of negative effects on TripleO
> > functionality (backwards compatibility, upgrades...)
> >
> 
> Nice summary here. I think we do need to be more careful in how we add
> features to python-tripleoclient so that we guard against breaking some of
> the UI use cases. We have guarded some features on this front in the past
> during the review process. When TripleO validations was added for instance
> we were extra careful in how we execute Ansible (via Mistral) so that both
> the UI and CLI could run it.
> 
> 
> >
> > The biggest point of divergence between GUI and CLI is that CLI tends to
> > generate a set of local files which are then put together when deploy
> > command is run whereas GUI operates on Deployment plan which is stored in
> > Swift and accessed through API provided by tripleo-common.
> >
> > The described problem currently affects all of the features which CLI uses
> > to generate files which are used in deploy command (e.g. Roles management,
> > Container images preparation, Networks management etc.) There is no API for
> > those features and therefore GUI can't support them until Mistral actions
> > and workflows are implemented for it.
> >
> > Proposed solution:
> >
> > We should stop considering TripleO as a set of utility scripts used to
> > construct 'deploy' command, we should rather consider TripleO as a
> > deployment application which has its internal state (Deployment plan in
> > Swift) which is accessed and modified via API.
> > TripleO feature should be considered complete when API for it is created.
> > CLI should solely use TripleO business logic through Mistral actions and
> > workflows provided by tripleo-common - same as any other client has to.
> >
> > Results of this change are:
> > - tripleoclient is extremely lightweight, containing no tripleo business
> > logic
> >
> 
> The python-client may be "lightweight" but the downstream packages that
> typically install this are extremely heavy. This is largely due to the
> instack-undercloud requirements that could arguably be split out into a
> separate subpackage. Just a minor nit, that we might consider making the
> package lighter for RPMs as well.
> 
> 
> > - tripleo-common API is tested in CI as it is used by CLI
> > - tripleoclient and tripleo-ui are perfectly compatible, interoperable and
> > its features and capabilities match
> > - TripleO business logic lives solely in tripleo-common and is operated
> > the same way by any client
> > - no new backward compatibility problems caused by releasing features
> > which are not supported by API are not introduced
> > - new features related to Ansible or containers are available to all
> > clients
> > - upgrades work the same way for deployments deployed via CLI and GUI
> > - deployment is replicable without need of keeping the the deploy command
> > and generated files around (exported deployment plan has all the
> > information)
> >
> > Note that argument of convenience of being able to modify deployment files
> > locally is less and less relevant as we are incrementally moving from
> > forcing user to modify templates manually (all the jinja templating,
> > roles_data.yaml, network_data.yaml generation, container images
> > preparation, derive parameters workflows etc.). In Pike we have made
> > changes to simplify the way Deployment plan is stored and it is extremely
> > easy to import and export it 

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

[Honza Pokorny]

About 10 years ago, we were promised a fully semantic version of HTML.
No more nested divs to structure your documents.  However, all we got
was a few generic, and only marginally useful elements like  and
.

On 2017-08-03 18:59, Ana Krivokapic wrote:
> 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.

While this is useful for addressing a particular element, I think it
would still require quite a bit of parsing.  You'd find yourself writing
string-splitting code all over the place.  It would make the code harder
to read without providing much semantic information --- unless of course
every single element had some kind of ID.

> 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.

I like this option the best.  It seems to be the most natural way of
adding semantic information to the bare-bones building blocks of the
web.  Classes are simple strings that add information about the intended
use of the element.  Using jQuery-like selectors, this can make for some
easy-to-understand code.  Do you want to grab the power state of the
currently expanded node in the list?

$('#node-list div.node.expanded').find('.power-state')

By default, Selenium can query the DOM by id, by class name, and by
xpath.  It can be extended to use pyquery which is the Python
implementation of the jQuery css selector.  I think many of the
automation implementation headaches can be solved by using pyquery.

https://blogs.gnome.org/danni/2012/11/19/extending-selenium-with-jquery/

Furthermore, I think that classes can be used effectively when
describing transient state like the expanded/collapsed state of a
togglable element.  It's easy to implement on the client side, and it
should be helpful on the automation side.

Relying on patternfly presentational class names won't suffice.

> 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.

This seems pretty drastic.  I wonder if there is a way we could extend
the React component class to give us automatic and painfree ids.

> 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] [ui] Integration testing in tripleo-ci

[Honza Pokorny]

On 2017-07-05 12:42, Ben Nemec wrote:
> 
> 
> On 07/05/2017 10:21 AM, Emilien Macchi wrote:
> > On Wed, Jul 5, 2017 at 7:57 AM, Florian Fuchs <flfu...@redhat.com> wrote:
> > > On Tue, Jul 4, 2017 at 7:48 PM, Emilien Macchi <emil...@redhat.com> wrote:
> > > > On Fri, Jun 30, 2017 at 10:51 AM, Honza Pokorny <ho...@redhat.com> 
> > > > wrote:
> > > > > I'd like to write some integration tests for the TripleO UI.  Simple
> > > > > configuration checks, workflow tests, websocket tests, etc.
> > > > > 
> > > > > I had a quick look at the tripleo-ci [1] repository, and it wasn't
> > > > > immediately obvious to me how to extend the existing infrastructure to
> > > > > add something like this.  It seems to me that the current way is just
> > > > > "stick some shell script here and here".  The tripleo.sh script is 
> > > > > about
> > > > > 1,600 LOC and it look rather intimidating.
> > > > > 
> > > > > I'm looking for help or pointers on how to do this.  Is there a 
> > > > > standard
> > > > > way of accomplishing this?  Are there any helpers I should be aware 
> > > > > of?
> > > > > Is there any documentation beyond what is in the git tree?
> > > > > 
> > > > > Any help would be appreciated
> > > > 
> > > > I think we have 2 options here (which could also be mixed):
> > > > 
> > > > - Using tripleo-validatons and make sure we run it in CI.
> > > 
> > > +1 for using ansible playbooks to write UI tests. I just don't think
> > > we should host the test playbooks in the tripleo-validations
> > > repository, because IMO testing the UI is different to what the
> > > tripleo-validations are doing.
> > > That said, the UI tests could use the ansible inventory from
> > > tripleo-validations -- which ends up in
> > > /usr/bin/tripleo-ansible-inventory and is already being used by
> > > playbooks other than tripleo-validations.
> > 
> > If tripleo-ui functional tests are written in Python, it makes a lot
> > of sense to write a Tempest plugin instead of using Ansible.
> 
> +1.  This seems like an obvious place to take advantage of the framework
> Tempest already has in place.  These aren't intended as user-facing tests so
> implementing them as validations would be a weird fit to me.

OK, great, let's go with tempest.  Initially, I was intrigued with the
idea of reusing some of the ansible code we already have in the
validations repository.  But in the end, it seems like tempest is the
better tool for what we want.

Emilien, how do we go about setting up the new project (GitHub, gerrit,
etc)?

> 
> > The major reason to me is consistency with how we test other services
> > in TripleO.
> > 
> > Whatever option we'll take, we'll need a new repository I think that
> > will contain the actual tests. There is a goal in Queens where Tempest
> > plugins are out of tree:
> > https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
> > If we take that path, we'll create a new repo for that.
> > 
> > 
> > The Ansible option would also be fine but we need to acknowledge the
> > fact tripleo-ui testing wouldn't be possible without deploying the
> > tripleo-validations bits.
> > 
> > > Florian
> > > 
> > > 
> > > > - Write a tempest plugin for tripleo-ui (like Horizon has one:
> > > > https://github.com/openstack/tempest-horizon) (it could be
> > > > openstack/tempest-triploe-ui) for example. We could run the tempest
> > > > tests in the CI jobs (we're working on running Tempest on scenario
> > > > jobs, see efforts made in
> > > > https://trello.com/c/Z8jIillp/252-spec-out-the-work-required-to-run-tempest-on-the-tripleo-gating-jobs).
> > > > 
> > > > Please do not implement tests in tripleo-ci or quickstart, I think we
> > > > need a way to test it outside CI and include it directly in the
> > > > product.
> > > > 
> > > > Thanks,
> > > > 
> > > > > Thanks!
> > > > > 
> > > > > Honza Pokorny
> > > > > 
> > > > > [1]: https://github.com/openstack-infra/tripleo-ci
> > > > > 
> > > > > __
> > > > > OpenStack Development Mailing List (not for usag

[openstack-dev] [tripleo] [ui] Integration testing in tripleo-ci

[Honza Pokorny]

I'd like to write some integration tests for the TripleO UI.  Simple
configuration checks, workflow tests, websocket tests, etc.

I had a quick look at the tripleo-ci [1] repository, and it wasn't
immediately obvious to me how to extend the existing infrastructure to
add something like this.  It seems to me that the current way is just
"stick some shell script here and here".  The tripleo.sh script is about
1,600 LOC and it look rather intimidating.

I'm looking for help or pointers on how to do this.  Is there a standard
way of accomplishing this?  Are there any helpers I should be aware of?
Is there any documentation beyond what is in the git tree?

Any help would be appreciated

Thanks!

Honza Pokorny

[1]: https://github.com/openstack-infra/tripleo-ci

__
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] Proposing Florian Fuchs for tripleo-validations core

[Honza Pokorny]

+1

On 2017-04-06 11:53, Martin André wrote:
> Hellooo,
> 
> I'd like to propose we extend Florian Fuchs +2 powers to the
> tripleo-validations project. Florian is already core on tripleo-ui
> (well, tripleo technically so this means there is no changes to make
> to gerrit groups).
> 
> Florian took over many of the stalled patches in tripleo-validations
> and is now the principal contributor in the project [1]. He has built
> a good expertise over the last months and I think it's time he has
> officially the right to approve changes in tripleo-validations.
> 
> Consider this my +1 vote.
> 
> Martin
> 
> [1] 
> http://stackalytics.com/?module=tripleo-validations=patches=pike
> 
> __
> 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

Re: [openstack-dev] [tripleo] tripleo-ui release job failure

[Honza Pokorny]

The included logs don't give me much to go on.  It fails with a pretty
generic timeout message.  I can't even determine if that happened during
"npm install" or after.

Is there any more information available on the source of the failure?

Thanks

Honza Pokorny

On 2017-02-16 12:43, Doug Hellmann wrote:
> The job to build the npm package for tripleo-ui has failed.
> 
> Doug
> 
> --- Begin forwarded message from jenkins ---
> From: jenkins <jenk...@openstack.org>
> To: release-job-failures <release-job-failu...@lists.openstack.org>
> Date: Thu, 16 Feb 2017 16:51:50 +
> Subject: [Release-job-failures] Release of openstack/tripleo-ui failed
> 
> Build failed.
> 
> - tripleo-ui-nodejs6-npm-publish-tarball 
> http://logs.openstack.org/45/452b4cb427a86e4b097b9711fb045a211b5e7039/release/tripleo-ui-nodejs6-npm-publish-tarball/6ec2420/
>  : FAILURE in 35m 53s
> - tripleo-ui-npm-upload tripleo-ui-npm-upload : SKIPPED
> 
> --- End forwarded message ---
> 
> __
> 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

Re: [openstack-dev] [tripleo] Proposing Honza Pokorny core on tripleo-ui

[Honza Pokorny]

Thanks everyone!

On 2017-01-30 10:45, Emilien Macchi wrote:
> Honza, you're now core on tripleo-ui project. Thanks for your hard
> work and congrats!
> 
> On Fri, Jan 27, 2017 at 2:45 AM, Dougal Matthews  wrote:
> > +1!
> >
> > On 25 January 2017 at 15:28, Steven Hardy  wrote:
> >>
> >> On Tue, Jan 24, 2017 at 08:52:51AM -0500, Emilien Macchi wrote:
> >> > I have been discussed with TripleO UI core reviewers and it's pretty
> >> > clear Honza's work has been valuable so we can propose him part of
> >> > Tripleo UI core team.
> >> > His quality of code and reviews make him a good candidate and it would
> >> > also help the other 2 core reviewers to accelerate the review process
> >> > in UI component.
> >> >
> >> > Like usual, this is open for discussion, Tripleo UI core and TripleO
> >> > core, please vote.
> >>
> >> +1
> >>
> >> __
> >> 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
> >
> 
> 
> 
> -- 
> 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

__
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][ui] FYI, the tripleo-ui package is currently broken

[Honza Pokorny]

Thanks for being on top of this, Julie.

Honza Pokorny

On 2017-01-19 15:17, Julie Pichon wrote:
> On 18 January 2017 at 11:35, Julie Pichon <jpic...@redhat.com> wrote:
> > I'm sorry to report we're finding ourselves in the same situation
> > again - CI will fail on all the UI patches, please don't recheck until
> > we have a new dependencies package available.
> >
> > On the plus side, with the help of amoralej on #rdo we figured out why
> > this is happening: the tripleo-ui rpm used in CI is being built from
> > the master branch, instead of using the patch under review. So,
> > instead of happening on the patch itself the CI failures only happen
> > after it merges. I filed [1] to track this. Any pointer from folks
> > familiar with TripleO CI as to where we might want to poke to resolve
> > this is appreciated :)
> 
> We're back in business! Recheck away, merge all the patches :)
> 
> Also thanks to panda we have a fix for the "CI not testing the patch
> currently under review" issue merged so hopefully this time, we can
> avoid the same kind of problems with new dependencies.
> 
> Thanks,
> 
> Julie
> 
> > [1] https://bugs.launchpad.net/tripleo/+bug/1657416
> 
> __
> 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

[openstack-dev] [TripleO][UI] Port number for frontend app

[Honza Pokorny]

Hello folks,

We've been using port 3000 for the GUI during development and testing.
Now that we're working on packaging and shipping our code, we're
wondering if port 3000 is still the best choice.

Would 3000 conflict with any other services?  Is there a better option?

Thanks

Honza Pokorny

__
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] [UI] Version

[Honza Pokorny]

On 2016-07-27 14:18, Steven Hardy wrote:
> On Wed, Jul 27, 2016 at 08:41:32AM -0300, Honza Pokorny wrote:
> > Hello folks,
> > 
> > As the tripleo-ui project is quickly maturing, it might be time to start
> > versioning our code.  As of now, the version is set to 0.0.1 and that
> > hardly reflects the state of the project.
> > 
> > What do you think?
> 
> I would like to see it released as part of the coordinated tripleo release,
> e.g tagged each milestone along with all other projects where we assert the
> release:cycle-with-intermediary tag:
> 
> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L4448
> 
> Because tripleo-ui isn't yet fully integrated with TripleO (e.g packaging,
> undercloud installation and CI testing), we've not tagged it in the last
> two milestone releases, but perhaps we can for the n-3 release?
> 
> https://review.openstack.org/#/c/324489/
> 
> https://review.openstack.org/#/c/340350/
> 
> When we do that, the versioning will align with all other TripleO
> deliverables, solving the problem of the 0.0.1 version?

Yes, this sounds great.

> 
> The steps to achieve this are:
> 
> 1. Get per-commit builds of tripleo-ui working via delorean-current:
> 
> https://trunk.rdoproject.org/centos7-master/current/

Patch for per-commit builds:

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

> 2. Get the tripleo-ui package installed and configured as part of the
> undercloud install (via puppet) - we might want to add a conditional to the
> undercloud.conf so it's configurable (enabled by default?)
> 
> https://github.com/openstack/instack-undercloud/blob/master/elements/puppet-stack-config/puppet-stack-config.pp
> 
> 3. Get the remaining Mistral API pieces landed so it's fully functional
> 
> 4. Implement some basic CI smoke tests to ensure the UI is at least
> accessible.
> 
> Does that sequence make sense, or have I missed something?

This makes sense to me.

> 
> Steve
> 
> __
> 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

[openstack-dev] [TripleO] [UI] Version

[Honza Pokorny]

Hello folks,

As the tripleo-ui project is quickly maturing, it might be time to start
versioning our code.  As of now, the version is set to 0.0.1 and that
hardly reflects the state of the project.

What do you think?

Honza Pokorny

__
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] Network diagram blueprint

[Honza Pokorny]

Hello folks,

Here is a blueprint that describes a new feature for the tripleo GUI:
the network diagram.

https://blueprints.launchpad.net/tripleo-ui/+spec/network-diagram

I invite you to voice your opinions and share feedback.

Thanks

Honza Pokorny

__
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] Mistral workflows for node assignment

[Honza Pokorny]

Hello folks,

I would love to get your thoughts on a new way of assigning roles to
nodes.

Since nova flavors are created during the installation of the
undercloud, they don't correspond to the actual hardware specifications
of the available nodes.  So, once a node is assigned, we should update
the flavor with new hardware specs based on that node.  This is a
two-step operation: update the node and update the flavor.

Now that we have multiple steps and multiple APIs involved in node
assignment, it seems that we should turn this procedure into a mistral
workflow.  I have created a patch that does just that and you're welcome
to review it and submit your feedback:

https://review.openstack.org/320459

The patch introduces two workflows: assign_node and assign_nodes.  The
latter is just a loop of the former.  It works like this:

Given a node_id and a role_name (compute, swift-storage, etc):

1.  Retrieve the node's details using ironic
2.  Create a JSON patch object to update the node's capabilities
3.  Update the node with the new capabilities
4.  Get all nodes for that role and determine the lowest common specs
5.  Recreate flavor with the common specs

The reason for recreating the flavor instead of updating it in place is
because mistral and the nova client don't expose the "set_keys" API yet.
If the above patch receives favorable comments, we can work on getting
those APIs exposed in order to simplify the code in tripleo-common.

Honza Pokorny

__
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