Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

2017-03-10 Thread Jason Rist
On 03/10/2017 09:26 AM, Heidi Joy Tretheway wrote:
> Hi TripleO team,
>
> Here’s an update on your project logo. Our illustrator tried to be as true as
> possible to your original, while ensuring it matched the line weight, color
> palette and style of the rest. We also worked to make sure that three Os in 
> the
> logo are preserved. Thanks for your patience as we worked on this! Feel free 
> to
> direct feedback to me.
>
>
>
> __
> 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
>
This is a good interpretation of the original, possibly even making it better.  
I like it.  Thanks Heidi!

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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][Containers] Creating launchpad bugs and correct tags

2017-03-03 Thread Jason Rist
On 03/02/2017 04:33 AM, Flavio Percoco wrote:
> On 02/03/17 10:57 +, Dougal Matthews wrote:
> > On 2 March 2017 at 10:40, Flavio Percoco  wrote:
> >
> >> Greetings,
> >>
> >> Just wanted to give a heads up that we're tagging all the containers
> >> related
> >> bugs with the... guess what?... containers tag. If you find an issue
> >> with
> >> one of
> >> the containers jobs or running tripleo on containers, please, file a bug
> >> and tag
> >> it accordingly.
> >>
> >
> > It might be worth adding it to the bug-tagging policy.
> > http://specs.openstack.org/openstack/tripleo-specs/specs/policy/bug-tagging.html#tags
> >
>
> Will do, thanks!
> Flavio
>
>
>
>
> __
> 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
>
I moved it from the "other" tags to "official" tags here:
https://bugs.launchpad.net/tripleo/+manage-official-tags

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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

2017-01-24 Thread Jason Rist
On 01/24/2017 06:52 AM, 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.
>
> Thanks,
>
+1, thanks for reviewing

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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] Update TripleO core members

2017-01-23 Thread Jason Rist
On 01/23/2017 12:03 PM, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
> docker bits.
> - Add Steve Backer on os-collect-config and also docker bits in
> tripleo-common and tripleo-heat-templates.
>
> Indeed, both Flavio and Steve have been involved in deploying TripleO
> in containers, their contributions are very valuable. I would like to
> encourage them to keep doing more reviews in and out container bits.
>
> As usual, core members are welcome to vote on the changes.
>
> Thanks,
>
+1 - Related - can we get a review of some of the other 'sub teams' within 
TripleO, for instance UI?  We've had 2 core reviewers for a long time, and it 
would help to have one or two more.

-J
-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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] [all][rdo][kolla] Recommending the RDO tag for the mailing list

2016-12-19 Thread Jason Rist
On 12/19/2016 07:21 AM, Steven Dake (stdake) wrote:
> Folks,
>
> I am in favor of using a new tag called [rdo] such that RDO (or its 
> transitive dependencies) can be discussed and filtered by email clients as it 
> relates to development topics that affect the broader OpenStack ecosystem.  
> As RDO is a community driven project which is very much related to OpenStack, 
> I think sharing a little bit of OpenStack list bandwidth isn’t too much to 
> ask.
>
> Further I’d invite the broader Kolla team to subscribe to the rdo-list, which 
> is a much more comprehensive coverage of RDO (both users and devs with 
> significant traffic) and filter rdo-list as you prefer:
>
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> Thanks!
> -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
>
+1

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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] release status

2016-12-14 Thread Jason Rist
On 12/14/2016 03:21 PM, Emilien Macchi wrote:
> On Tue, Dec 13, 2016 at 5:02 PM, Emilien Macchi  wrote:
> > I thought it would be useful to share our roadmap for TripleO releases.
> > As a reminder, this is the official source of trust for OpenStack
> > releases schedule:
> > https://releases.openstack.org/ocata/schedule.html
> >
> > Over the last weeks, we discussed about how TripleO project would
> > produce better releases without stressing people at pushing for
> > features late in cycles.
> >
> > - tripleo-specs for Ocata need to be merged by ocata-2 or will be
> > postponed to Pike.
> > - blueprints scheduled for ocata-2 with good progress will be
> > postponed to ocata-3.
>
> done. Though I found 44 blueprints for ocata-3 too big, we'll review
> them and eventually postpone some of them, as this number doesn't
> sound realistic.
>
> > - blueprints scheduled for ocata-2 with zero or low progress will be
> > postponed to pike-1.
>
> I did that operation today. Please let me know if you disagree if your
> blueprint moved to pike-1 and we can discuss about it.
>
> > - we'll release ocata-2 end of this week.
>
> done: https://review.openstack.org/#/c/410958/
>
> > - we'll release a new Newton release next week.
> > - by the end of ocata-3, we'll stop pushing for features except
> > Composable Upgrades which is our critical thing during this cycle.
> > Anything else will be frozen and postponed to Pike.
> > - we'll threat FFE case by case but if the FFE is not related to a
> > blueprint that was targeted for ocata-3, no need to ask, it will be
> > rejected.
> > - between end of ocata-3 and final ocata release, we have 5 weeks. We
> > might want to spend time on stabilization, bug fixing (we currently
> > have more than 100 bugs open, just for ocata-2) and keep CI stable
> > until final release. The last thing we want is to push for last
> > features and stress people because it breaks all the things.
> >
> > Please provide any feedback, it's highly welcome.
> > --
> > Emilien Macchi
>
>
>
I'll be going through and moving a bunch to Pike soon as well.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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] Cheatsheets for FOSDEM and devconf

2016-12-13 Thread Jason Rist
On 12/13/2016 07:32 AM, Carlos Camacho Gonzalez wrote:
> Hi TripleOers!
> 
> We are working preparing some cheatsheets for people jumping into TripleO.
> 
> So there is an early WIP version for a few cheatsheets that we want to share:
> 
> -TripleO manual installation  (Just a copy/paste step-wise process to
> install TripleO)
> - Deployments debugging tips (Relevant commands to know what's
> happening with the deployment)
> - CI (URL's and resource to check our CI status)
> - OOOQ (Also a step-wise recipe to install OOOQ, does not exist yet)
> 
> We already have some drafts available in
> https://github.com/ccamacho/tripleo-cheatsheet
> 
> So, we will like to have some feedback from the community and make a
> stable version for the cheatsheets in the next week.
> 
> Feedback for adding/removing content and general reviews about all of
> them is welcomed.
> 
> Thanks!,
> Carlos
> 
> __
> 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
> 


It would be really great if you had a note about turning on the UI (edit
undercloud.conf, enable_mistral; enable_ui) as well.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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] Network Configuration in TripleO UI

2016-12-08 Thread Jason Rist
On 12/08/2016 05:28 PM, Dan Sneddon wrote:
> On 12/08/2016 06:05 AM, Jiri Tomasek wrote:
> > Hi all,
> >
> > I've been investigating how to implement TripleO network configuration
> > in TripleO UI. Based on my findings I'd like to propose a solution.
> >
> > tl;dr proposal: Slightly refactor Network environment files to match
> > GUI usage, Use Jinja Templating to generate dynamic parts of the
> > templates/environments
> >
> >
> > # Overview
> >
> > I've used Ben Nemec's amazing Network template generator as a reference
> > to help me understand how the network configuration works [1]. In
> > general the process of configuring the network in TripleO is:
> >
> > Define which Networks we intend to use -> Assign Roles to the Networks
> > (+ Assign Role Services to the Network) -> Generate NIC config
> > templates based on previous information
> >
> >
> > # Deeper dive into templates
> >
> > We currently have 2 environment files in THT [2] which define network
> > configuration:
> >
> > network-environment.yaml [3] - holds the information on NIC
> > configuration for each Role using
> > OS::TripleONet::SoftwareConfig resource + related
> > parameter configuration
> >
> > network-isolation.yaml [4]
> > - defines the list of networks using
> > OS::TripleO::Network:: resource
> > - defines ports configuration for each network using
> > OS::TripleO::Network::Ports::VipPort (note that both
> > resources point to the static templates - those templates don't require
> > any manual modification)
> > - holds  Roles - Networks assignment using
> > OS::TripleOPorts::Port for each role and
> > storage (again, templates referenced by those resources don't require
> > any modification)
> >
> > User is intended to go ahead and modify those environments and provide
> > NIC config templates to achieve a network configuration that matches
> > his needs.
> >
> >
> > # How GUI works
> >
> > Before proceeding to proposed changes I need to describe briefly how
> > TripleO UI works. TripleO UI is using THT as a source of truth, which
> > means that it is trying not to add any additional business logic or
> > manipulate templates. Rather it uses environment files as a 'features'
> > which user can enable or disable depending on the needs of the
> > deployment. The information about inter-environment relationships is
> > tracked in capabilities-map.yaml which is also part of the THT. Based
> > on these choices, UI allows user to configure parameters for those
> > features. The parameter values and information about which environments
> > are selected is stored in mistral environment. This approach leaves the
> > plan templates intact. Huge benefit of this approach is that UI (or
> > tripleo-common) does not need to hold explicit business logic related
> > to certain deployment features as it is purely driven by THT. Also
> > Adding a new feature involves only providing the templates/environments
> > and it automatically appears as an option in UI.
> >
> > To achieve best user experience while using this approach, the
> > environment files need to be defined in a granular manner, so they
> > don't require user to modify them and each describe an isolated 'feature'.
> >
> > Roles and Network Configuration are exceptions to this concept as they
> > require modification/generation of the templates/environments and
> > therefore they use Jinja templating to achieve that.
> >
> >
> > # The proposal
> >
> > So having described previous, here is the approach I think we should
> > use to achieve network configuration using TripleO UI:
> >
> > 1. Put networks definitions into separate environment for each network:
> > - this way GUI can provide a list of networks available to use and let
> > user select which of them he wants to use. These environments are not
> > dynamic and if user wants to add a new network, he does so by creating
> > new templates and environment for it. UI also provides means to
> > configure parameters for each network at this point (if needed).
> >
> > For example the environment for a Storage Network looks like this:
> >
> > resource_registry:
> >   OS::TripleO::Network::Storage: ../network/storage.yaml
> >   OS::TripleO::Network::Ports::StorageVipPort:
> > ../network/ports/storage.yaml
> >
> > 2. Assign Roles to Networks
> > Having the Networks selected as well as Roles defined, TripleO UI
> > provides user with means to assign Roles to Networks. This step
> > involves generating the network-environment.yaml file. So TripleO UI
> > sends the mapping of roles to network in json format to tripleo-common
> > which in turn uses network-isolation.j2.yaml Jinja template to generate
> > the environment file. I expect that pre-defined network-isolation.yaml
> > will be included in default plan so the user does not need to start
> > from scratch. Tripleo-common also provides an action to fetch
> > network-roles assignment data by parsing the network-isolation.yaml
> >
> > In addition, user is able to assign 

Re: [openstack-dev] [Horizon] Draft team mascot

2016-12-06 Thread Jason Rist
On 12/06/2016 01:48 PM, Richard Jones wrote:
> >> On 6 Dec 2016, at 20:19, Richard Jones  wrote:
> >> Please let me know what you think (by December 12) of this draft for
> >> our Horizon team mascot.
> >
> On 7 December 2016 at 07:38, Rob Cresswell (rcresswe)
>  wrote:
> > Are we missing an attachment / link ?
>
> Weird! Trying again:
>
>
>
> __
> 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
>
Much UI, such OpenStack, wow.

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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 Alex Schultz core on puppet-tripleo

2016-12-02 Thread Jason Rist
On 12/01/2016 05:26 PM, Emilien Macchi wrote:
> Team,
> 
> Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
> months now.  While he's very active in different areas of TripleO, his
> reviews and contributions on puppet-tripleo have been very useful.
> Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
> think he perfectly understands how puppet-tripleo works. His
> involvement in the project and contributions on puppet-tripleo deserve
> that we allow him to +2 puppet-tripleo.
> 
> Thanks Alex for your involvement and hard work in the project, this is
> very appreciated!
> 
> As usual, I'll let the team to vote about this proposal.
> 
> Thanks,
> 
+1

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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] [all][tc] Exposing project team's metadata in README files

2016-11-30 Thread Jason Rist
On 11/30/2016 11:18 AM, Ben Nemec wrote:
>
>
> On 11/30/2016 03:34 AM, Flavio Percoco wrote:
> > On 25/11/16 13:46 +, Amrith Kumar wrote:
> >> Flavio,
> >>
> >> I see a number of patches[1] which have been landed on this project
> >> but I find
> >> that at least the ones that were landed for Trove, and a random
> >> sampling of
> >> the others all to be different from what you proposed below[2] in one
> >> important aspect.
> >>
> >> In [2] you proposed a structure where the title of the document; or
> >> the first,
> >> and most prominent heading, would be the existing heading of the
> >> document, and
> >> the tags would be below that. In [2] for example, that was:
> >>
> >> "kombu - Messaging library for Python"
> >>
> >> and the tags would be in smaller font below that.
> >
> > Hi,
> >
> > Some fixes landed yesterday to improve the badges layout. For those
> > interested,
> > here's an example of what it looks like now:
> >
> > https://github.com/openstack/keystone
> >
> > Basically, the horizontal padding was reduced to the minimum needed
> > and the
> > badges width was set to the total width of the image.
>
> Any idea why there is so much vertical whitespace after the badges in
> https://github.com/openstack/instack-undercloud ?  It's all clickable so
> I'm thinking it must be coming from the badge image for some reason.
>
> __
> 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
How much is 'so much'? I see at most 50 pixels?

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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 Jason Rist
On 10/25/2016 03:55 AM, Steven Hardy 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.
> 
> 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:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


I obviously have a bias, but this doesn't really have much of a
personality.  I'm pretty disappointed.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] [puppet] [tripleo] our CI is now deploying OpenStack Ocata

2016-10-06 Thread Jason Rist
On 10/06/2016 06:30 AM, Emilien Macchi wrote:
> Quick FYI about TripleO and Puppet CI.
> We bumped RDO to start building OpenStack Ocata packages, and
> successfully made the switch in the TripleO and Puppet gates.
>
> So both CI deploy OpenStack from trunk again, and not Newton.
> Stable gates (newton) are deploying latest Newton packages though.
>
> Thanks for the people who were involved in that process, big kudos here.
>
Thanks Emilien!

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] [horizon] Browser Support

2016-09-19 Thread Jason Rist
This page hasn't been updated for a while - does anyone know the latest?

https://wiki.openstack.org/wiki/Horizon/BrowserSupport

Thanks,
Jason
-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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 Core nominations

2016-09-16 Thread Jason Rist
On 09/15/2016 03:20 AM, Steven Hardy wrote:
> Hi all,
> 
> As we work to finish the last remaining tasks for Newton, it's a good time
> to look back over the cycle, and recognize the excellent work done by
> several new contributors.
> 
> We've seen a different contributor pattern develop recently, where many
> folks are subsystem experts and mostly focus on a particular project or
> area of functionality.  I think this is a good thing, and it's hopefully
> going to allow our community to scale more effectively over time (and it
> fits pretty nicely with our new composable/modular architecture).
> 
> We do still need folks who can review with the entire TripleO architecture
> in mind, but I'm very confident folks will start out as subsystem experts
> and over time broaden their area of experience to encompass more of
> the TripleO projects (we're already starting to see this IMO).
> 
> We've had some discussion in the past[1] about strictly defining subteams,
> vs just adding folks to tripleo-core and expecting good judgement to be
> used (e.g only approve/+2 stuff you're familiar with - and note that it's
> totally fine for a core reviewer to continue to +1 things if the patch
> looks OK but is outside their area of experience).
> 
> So, I'm in favor of continuing that pattern and just welcoming some of our
> subsystem expert friends to tripleo-core, let me know if folks feel
> strongly otherwise :)
> 
> The nominations, are based partly on the stats[2] and partly on my own
> experience looking at reviews, patches and IRC discussion with these folks
> - I've included details of the subsystems I expect these folks to focus
> their +2A power on (at least initially):
> 
> 1. Brent Eagles
> 
> Brent has been doing some excellent work mostly related to Neutron this
> cycle - his reviews have been increasingly detailed, and show a solid
> understanding of our composable services architecture.  He's also provided
> a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> Brent continues this exellent Neutron focussed work, while also expanding
> his review focus such as the good feedback he's been providing on new
> Mistral actions in tripleo-common for custom-roles.
> 
> 2. Pradeep Kilambi
> 
> Pradeep has done a large amount of pretty complex work around Ceilomenter
> and Aodh over the last two cycles - he's dealt with some pretty tough
> challenges around upgrades and has consistently provided good review
> feedback and solid analysis via discussion on IRC.  I propose Prad
> continues this excellent Ceilomenter/Aodh focussed work, while also
> expanding review focus aiming to cover more of t-h-t and other repos over
> time.
> 
> 3. Carlos Camacho
> 
> Carlos has been mostly focussed on composability, and has done a great job
> of working through the initial architecture implementation, including
> writing some very detailed initial docs[3] to help folks make the transition
> to the new architecture.  I'd suggest that Carlos looks to maintain this
> focus on composable services, while also building depth of reviews in other
> repos.
> 
> 4. Ryan Brady
> 
> Ryan has been one of the main contributors implementing the new Mistral
> based API in tripleo-common.  His reviews, patches and IRC discussion have
> consistently demonstrated that he's an expert on the mistral
> actions/workflows and I think it makes sense for him to help with review
> velocity in this area, and also look to help with those subsystems
> interacting with the API such as tripleoclient.
> 
> 5. Dan Sneddon
> 
> For many cycles, Dan has been driving direction around our network
> architecture, and he's been consistently doing a relatively small number of
> very high-quality and insightful reviews on both os-net-config and the
> network templates for tripleo-heat-templates.  I'd suggest Dan continues
> this focus, and he's indicated he may have more bandwidth to help with
> reviews around networking in future.
> 
> Please can I get feedback from exisitng core reviewers - you're free to +1
> these nominations (or abstain), but any -1 will veto the process.  I'll
> wait one week, and if we have consensus add the above folks to
> tripleo-core.
> 
> Finally, there are quite a few folks doing great work that are not on this
> list, but seem to be well on track towards core status.  Some of those
> folks I've already reached out to, but if you're not nominated now, please
> don't be disheartened, and feel free to chat to me on IRC about it.  Also
> note the following:
> 
>  - We need folks to regularly show up, establishing a long-term pattern of
>doing useful reviews, but core status isn't about raw number of reviews,
>it's about consistent downvotes and detailed, well considered and
>insightful feedback that helps increase quality and catch issues early.
> 
>  - Try to spend some time reviewing stuff outside your normal area of
>expertise, to build understanding of the broader TripleO system - as
>discussed 

Re: [openstack-dev] [heat][tripleo][horizon][tripleo-ui] Parameter groups, tags and deprecation

2016-08-25 Thread Jason Rist
On 08/25/2016 03:55 PM, Steven Hardy wrote:
> On Thu, Aug 25, 2016 at 04:19:12PM -0400, Zane Bitter wrote:
> > On 25/08/16 14:02, Steven Hardy wrote:
> >> Hi all,
> >>
> >> So I'm following up on a discussion that started here:
> >>
> >> https://review.openstack.org/#/c/356240
> >>
> >> Basically I recently suggested[1] that relaxing the restriction where a
> >> parameter can only exist in exactly one parameter_group would be a way to
> >> help work around some pain-points we have in TripleO atm.
> >
> > I usually read the scrollback of meetings I'm not able to attend but I must
> > have missed that one, sorry.
> >
> >> Let me start with the the problems we're trying to solve, because I think
> >> they are common to many Heat users, not just TripleO:
> >>
> >> 1. When doing nested validation to discover parameter schema, it's
> >> impossible to tell if a parameter will be provided by the parent
> >
> > IMHO they should all be provided by the parent, but that's another story ;)
> >
> >> This is a known issue from when nested validation was first implemented,
> >> and we never figured out a satisfactory fix, basically because you can't
> >> possibly tell without actually creating things whether an indirectly
> >> provided parameter (e.g a reference to another resource in a parent
> >> template) will resolve to a valid value.
> >>
> >> So when you build a bunch of templates where there are some parameters
> >> which form part of an internal interface (e.g they are always provided by
> >> the parent and thus should not be exposed to end users) and some which are
> >> extra (and should always be provided, or at least exposed to end users) you
> >> have no way to differentiate them.
> >
> > Heat has a way to differentiate them surely, because it has the templates?
> > If you implement it that sounds much more reliable than asking template
> > authors to annotate this stuff manually (for a start the same nested
> > template can be instantiated in different ways, so it's not even possible in
> > general to annotate it in such a way as to indicate which parameters will be
> > set by the parent and which should be set by modifying parameter defaults).
>
> The problem is that many (most?) intrinsic functions return None at
> validation time, which we can't easily distinguish from no value being
> passed into the nested stack.
>
> I'm not saying this can't be fixed, I'm just saying it's probably pretty
> hard from an implementation perspective (Jay and I both had a try at fixing
> this but I'd welcome some fresh eyes on it!).
>
> Some more context here (and Jay mentions a newton targetted bug although
> I'm currently failing to find it):
>
> https://bugs.launchpad.net/heat/+bug/1508857
>
> It's true that no general pattern for annotation is possible, but given a
> sufficiently constrained interface (such as we support in some parts of
> TripleO) it would be a workable alternative to the status-quo (if the
> template annotation was possible, but currently it is not).
>
> >> Example of this here:
> >>
> >> https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/heat-api.yaml#L7
> >>
> >> ServiceNetMap, DefaultPasswords and EndpointMap are internal interfaces,
> >> and the remainder are options for the service that should be exposed to the
> >> user.
> >>
> >> One option would be to add internal interfaces to a parameter_group
> >> "internal", but that then means we can never categorize a parameter as
> >> anything else (such as "deprecated" for example, see below).
> >>
> >> 2. When you ship a template containing parameters, it's impossible to ever
> >> deprecate the parameter names
> >>
> >> The problem here is twofold:
> >>  - We don't provide any means to tag a parameter as deprecated (so that,
> >>for example, a UI or CLI tool could output an annoying warning to
> >> encourage not using it)
> >>  - There's no way to map an old (deprecated) name to a new one unless you
> >>do hacks inside the template such as overwriting one parameter with
> >>another via str_replace (which won't work for all parameter types, and
> >>you still can't ever remove the old parameter because there's no channel
> >>to warn users)
> >>
> >> So, one option here is to add a parameter_group called "deprecated" that's
> >> then introspected by the client during the validation phase, and outputs a
> >> warning when deprecated parameters are used.
> >
> > This seems like a very general problem. I would definitely be in favour of
> > some native support for this in the HOT format.
>
> Sure, so would I - but I remember discussing this in Vancouver, so it'd be
> good to figure out some incremental steps to improve this, again a template
> annotation (parameter_groups or something else) provides a simple interim
> workaround for this non-trivial and long-standing feature gap.
>
> >> 3. No way to subcategorize more than once
> >>
> >> The assumption in the current parameter_group interface is that a UI 

[openstack-dev] [TripleO][UI] Review priorities for feature freeze

2016-08-17 Thread Jason Rist
I started an etherpad with the top-priority reviews for the core team to
be looking at in the lead-up to feature freeze for the TripleO UI.  We
are really needing eyes on the mistral stuff, validations stuff, and
packaging.  There are a few from UI in there as well.

https://etherpad.openstack.org/p/tripleo-ui-newton-reviews

If you have other high-priority patches please add them to the list.

Thank you in advance!
-Jason
-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] [mistal] Mistral logo ideas?

2016-06-29 Thread Jason Rist
On 06/29/2016 12:45 AM, Renat Akhmerov wrote:
> They all look good to me, and yes, I’d prefer mistral-tornado.png over 
> mistral.png. I also have the same concern about Michal’s idea if it will be a 
> small picture. Word “Mistral” may not be distinguishable.
>
> One more thing I’d like to add to the discussion: what if move away from 
> having word “Mistral” in the logo at all? It could just a symbol (mascot, if 
> you will) which does not explicitly tell that it’s Mistral.
>
> Renat Akhmerov
> @Nokia
>
> > On 28 Jun 2016, at 22:20, Elisha, Moshe (Nokia - IL) 
> > <moshe.eli...@nokia.com> wrote:
> >
> > Hi,
> >
> > Attached another draft based on Michal's idea (it probably should be more 
> > colourful)
> >
> > Maybe we can upload them to some online survey and vote…
> >
> >
> > From: Ryan Brady <rbr...@redhat.com <mailto:rbr...@redhat.com>>
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> > <openstack-dev@lists.openstack.org 
> > <mailto:openstack-dev@lists.openstack.org>>
> > Date: Tuesday, 28 June 2016 at 17:08
> > To: Jason Rist <jr...@redhat.com <mailto:jr...@redhat.com>>, "OpenStack 
> > Development Mailing List (not for usage questions)" 
> > <openstack-dev@lists.openstack.org 
> > <mailto:openstack-dev@lists.openstack.org>>
> > Subject: Re: [openstack-dev] [mistal] Mistral logo ideas?
> >
> >
> >
> > On Tue, Jun 28, 2016 at 1:38 AM, Jason Rist <jr...@redhat.com 
> > <mailto:jr...@redhat.com>> wrote:
> >> On 06/27/2016 06:57 AM, Dougal Matthews wrote:
> >>> On 27 June 2016 at 07:45, Renat Akhmerov <renat.akhme...@gmail.com 
> >>> <mailto:renat.akhme...@gmail.com>> wrote:
> >>>
> >>>>
> >>>>> Ideally it would be nice to have something that matches the meaning of
> >>>> the
> >>>>> name. Maybe we can combine wind with one of the other ideas.
> >>>>>
> >>>>> I like the idea of the logo being a stylized wind turbine. Perhaps it
> >>>> could be
> >>>>> a turbine with a gust of wind. Then we can show that Mistral harnesses
> >>>> the
> >>>>> power of the wind :-)
> >>>>
> >>>> Yeah, I’m just wondering how it would look like :)
> >>>>
> >>>>
> >>> Yeah, for this idea we probably need somebody with artistic skills far
> >>> superior
> >>> to anything I could manage. We are getting quite a few good ideas now
> >>> anyway!
> >>>
> >>>
> >>> Renat Akhmerov
> >>>> @Nokia
> >>>>
> >>>>
> >>>
> >>
> >> Ever since I saw the blueprint for a mistral logo, I've been working on 
> >> some ideas.  I've presented a few to Dougal and Ryan, but I'm sharing 
> >> widely here.  I also did the one Michal came up with in Illustrator as 
> >> well.  Please give me some feedback!  Both of the ones I thought of are 
> >> "wind" related.  I thought about doing the ship before as well, but 
> >> perhaps a little too war related, and also obscure.
> >
> > +1 to the mistral-tornado.png logo.  I think it would be easily 
> > distinguishable at any size or distance.
> >
> >>
> >> Thanks,
> >> Jason
> >>
> >> P.S. you may recognize my name from the DLRN logo [1] and the TripleO Logo 
> >> [2].
> >>
> >> [1] 
> >> https://github.com/openstack-packages/DLRN/blob/master/doc/source/_images/DLRN.png
> >>  
> >> <https://github.com/openstack-packages/DLRN/blob/master/doc/source/_images/DLRN.png>
> >> [2] 
> >> https://github.com/dprince/tripleosphinx/blob/master/tripleosphinx/theme/tripleo/static/tripleo_owl.svg
> >>  
> >> <https://github.com/dprince/tripleosphinx/blob/master/tripleosphinx/theme/tripleo/static/tripleo_owl.svg>
> >>
> >> --
> >> Jason E. Rist
> >> Senior Software Engineer
> >> OpenStack User Interfaces
> >> Red Hat, Inc.
> >> openuc: +1.972.707.6408 <tel:%2B1.972.707.6408>
> >> mobile: +1.720.256.3933 <tel:%2B1.720.256.3933>
> >> Freenode: jrist
> >> github/twitter: knowncitizen
> >>
> >> __
>

Re: [openstack-dev] [TripleO] TripleO deep dive hour?

2016-06-29 Thread Jason Rist
On 06/28/2016 04:00 PM, James Slagle wrote:
> We've got some new contributors around TripleO recently, and I'd like
> to offer up a "TripleO deep dive hour".
> 
> The idea is to spend 1 hour a week in a high bandwidth environment
> (Google Hangouts / Bluejeans / ???) to deep dive on a TripleO related
> topic. The topic could be anything TripleO related, such as general
> onboarding, CI, networking, new features, etc.
> 
> I'm by no means an expert on all those things, but I'd like to
> facilitate the conversation and I'm happy to lead the first few
> "dives" and share what I know. If it proves to be a popular format,
> hopefully I can convince some other folks to lead discussions on
> various topics.
> 
> I think it'd be appropriate to record these sessions so that what is
> discussed is available to all. However, I don't intend these to be a
> presentation format, and instead more of a q discussion. If I don't
> get any ideas for topics though, I may choose to prepare something to
> present :).
> 
> Our current meeting time of day at 1400 UTC seems to suit a lot of
> folks, so how about 1400 UTC on Thursdays? If folks think this is
> something that would be valuable and want to do it, we could start
> next Thursday, July 7th.
> 
> 

This sounds very useful. Will you be sending out some sort of invite or
notification once you've decided you're going to hold it?

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

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

2016-06-29 Thread Jason Rist
On 06/29/2016 08:50 AM, Honza Pokorny wrote:
> 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
>
Hi Everyone - We're trying to determine if this is something we can get into 
Newton.  Please comment if this is crazy town banana pants or not.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] Zaqar messages standardization

2016-05-23 Thread Jason Rist
On 05/20/2016 11:39 AM, Dan Prince wrote:
> On Fri, 2016-05-20 at 17:52 +0200, Jiri Tomasek wrote:
>> Hey all,
>>
>> I've been recently working on getting the TripleO UI integrated with
>> Zaqar, so it can receive a messages from Mistral workflows and act
>> upon them without having to do various polling hacks.
>>
>> Since there is currently quite a large amount of new TripleO
>> workflows comming to tripleo-common, we need to standardize this
>> communication so clients can consume the messages consistently.
>>
>> I'll try to outline the requirements as I see it to start the
>> discussion.
>>
>> Zaqar queues:
>> To listen to the Zaqar messages it requires the client to connect to
>> Zaqar WebSocket, send authenticate message and subscribe to queue(s)
>> which it wants to listen to. The currently pending workflow patches
>> which send Zaqar messages [1, 2] expect that the queue is created by
>> client and name is passed as an input to the workflow [3].
>>
>> From the client perspective, it would IMHO be better if all workflows
>> sent messages to the same queue and provide means to identify itself
>> by carrying workflow name and execution id. The reason is, that if
>> client creates a queue and triggers the workflow and then disconnects
>> from the Socket (user refreshes browser), then it does not know what
>> queues it previously created and which it should listen to. If there
>> is single 'tripleo' queue, then all clients always know that it is
>> where it will get all the messages from.
> 
> I think each workflow that supports queue messages (probably most of
> them) should probably allow to set your own queue_name that will get
> messages posted to it. Then it would simply be a convention that the
> client simply pass the same queue name to any concurrent workflows that
> are executed.
> 
> The single queue -> multiple workflows use case is however important to
> support for the UI so adding the execution_id and fully qualified
> workflow name to each queue message should allow both patterns to work
> fine.
> 
> And while the queue name is configurable perhaps we default it to
> 'tripleo' so that you really don't have to set it anywhere unless you
> really want to.
> 
> If you buy this I can update the patches linked below per the latest
> feedback.
> 
> Dan
> 
> 
>>
>> Messages identification and content:
>> The client should be able to identify message by it's name so it can
>> act upon it. The name should probably be relevant to the action or
>> workflow it reports on.
>>
>> { 
>>   body: {
>> name: 'tripleo.validations.v1.run_validation,
>> execution_id: '123123123'
>> data: {}
>>   }
>> }
>>
>> Other parts of the message are optional but it would be good to
>> provide information relevant to the message's purpose, so the client
>> can update relevant state and does not have to do any additional API
>> calls. So e.g. in case of running the validation a message includes
>> validation id.
>>  
>>
>> [1] https://review.openstack.org/#/c/313953/2/workbooks/deployment.ya
>> ml
>> [2] https://review.openstack.org/#/c/313632/8/workbooks/validations.y
>> aml
>> [3] https://review.openstack.org/#/c/313957/1/tripleoclient/v1/overcl
>> oud_execute.py
>>
>> -- Jirka

+1 as well. This seems reasonable.

-J


-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] Austin summit - session recap/summary

2016-05-03 Thread Jason Rist
On 05/03/2016 10:34 AM, Steven Hardy wrote:
> Hi all,
>
> Some folks have requested a summary of our summit sessions, as has been
> provided for some other projects.
>
> I'll probably go into more detail on some of these topics either via
> subsequent more focussed threads an/or some blog posts but what follows is
> an overview of our summit sessions[1] with notable actions or decisions
> highlighted.  I'm including some of my own thoughts and conclusions, folks
> are welcome/encouraged to follow up with their own clarifications or
> different perspectives :)
>
> TripleO had a total of 5 sessions in Austin I'll cover them one-by-one:
>
> -
> Upgrades - current status and roadmap
> -
>
> In this session we discussed the current state of upgrades - initial
> support for full major version upgrades has been implemented, but the
> implementation is monolithic, highly coupled to pacemaker, and inflexible
> with regard to third-party extraconfig changes.
>
> The main outcomes were that we will add support for more granular
> definition of the upgrade lifecycle to the new composable services format,
> and that we will explore moving towards the proposed lightweight HA
> architecture to reduce the need for so much pacemaker specific logic.
>
> We also agreed that investigating use of mistral to drive upgrade workflows
> was a good idea - currently we have a mixture of scripts combined with Heat
> to drive the upgrade process, and some refactoring into discrete mistral
> workflows may provide a more maintainable solution.  Potential for using
> the existing SoftwareDeployment approach directly via mistral (outside of
> the heat templates) was also discussed as something to be further
> investigated and prototyped.
>
> We also touched on the CI implications of upgrades - we've got an upgrades
> job now, but we need to ensure coverage of full release-to-release upgrades
> (not just commit to commit).
>
> ---
> Containerization status/roadmap
> ---
>
> In this session we discussed the current status of containers in TripleO
> (which is to say, the container based compute node which deploys containers
> via Heat onto an an Atomic host node that is also deployed via Heat), and
> what strategy is most appropriate to achieve a fully containerized TripleO
> deployment.
>
> Several folks from Kolla participated in the session, and there was
> significant focus on where work may happen such that further collaboration
> between communities is possible.  To some extent this discussion on where
> (as opposed to how) proved a distraction and prevented much discussion on
> supportable architectural implementation for TripleO, thus what follows is
> mostly my perspective on the issues that exist:
>
> Significant uncertainty exists wrt integration between Kolla and TripleO -
> there's largely consensus that we want to consume the container images
> defined by the Kolla community, but much less agreement that we can
> feasably switch to the ansible-orchestrated deployment/config flow
> supported by Kolla without breaking many of our primary operator interfaces
> in a fundamentally unacceptable way, for example:
>
> - The Mistral based API is being implemented on the expectation that the
>   primary interface to TripleO deployments is a parameters schema exposed
>   by a series of Heat templates - this is no longer true in a "split stack"
>   model where we have to hand off to an alternate service orchestration tool.
>
> - The tripleo-ui (based on the Mistral based API) consumes heat parameter
>   schema to build it's UI, and Ansible doesn't support the necessary
>   parameter schema definition (such as types and descriptions) to enable
>   this pattern to be replicated.  Ansible also doesn't provide a HTTP API,
>   so we'd still have to maintain and API surface for the (non python) UI to
>   consume.
>
> We also discussed ideas around integration with kubernetes (a hot topic on
> the Kolla track this summit), but again this proved inconclusive beyond
> that yes someone should try developing a PoC to stimulate further
> discussion.  Again, significant challenges exist:
>
> - We still need to maintain the Heat parameter interfaces for the API/UI,
>   and there is also a strong preference to maintain puppet as a tool for
>   generating service configuration (so that existing operator integrations
>   via puppet continue to function) - this is a barrier to directly
>   consuming the kolla-kubernetes effort directly.
>
> - A COE layer like kubernetes is a poor fit for deployments where operators
>   require strict control of service placement (e.g exactly which nodes a 
> service
>   runs on, IP address assignments to specific nodes etc) - this is already
>   a strong requirement for TripleO users and we need to figure out if/how
>   it's possible to control container placement per node/namespace.
>
> - There 

[openstack-dev] [TripleO] Summit Summary?

2016-05-02 Thread Jason Rist
Hey Everyone - Forgive me if this has already been sent out - I looked
through all of my emails and didn't see something yet.  Can someone
provide a summary of TripleO from the summit, for instance some of the
output from the design sessions like the Trove, Magnum and some other
teams have done?  Those of us unable to attend are curious!

Thanks,
Jason
-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] Can we create some subteams?

2016-04-13 Thread Jason Rist
On 04/13/2016 08:39 AM, Ryan Brady wrote:
> On Mon, Apr 11, 2016 at 5:54 AM, John Trowbridge  wrote:
>
> > Hola OOOers,
> >
> > It came up in the meeting last week that we could benefit from a CI
> > subteam with its own meeting, since CI is taking up a lot of the main
> > meeting time.
> >
> > I like this idea, and think we should do something similar for the other
> > informal subteams (tripleoclient, UI), and also add a new subteam for
> > tripleo-quickstart (and maybe one for releases?).
> >
> > We should make seperate ACL's for these subteams as well. The informal
> > approach of adding cores who can +2 anything but are told to only +2
> > what they know doesn't scale very well.
> >
>
> +1 to subteams for selected projects.
>
> I think there should be a clearly defined practice of ensuring there is
> enough reviewers so that a subteam core doesn't need to +A their own
> patches.  I don't know if that's a standing rule in tripleo core, but I
> think it should be explicit in subteams.
>
> -r
>
Another +1 to this.
-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] Can we create some subteams?

2016-04-11 Thread Jason Rist
On 04/11/2016 04:19 AM, Steven Hardy wrote:
> On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote:
> > Hola OOOers,
> >
> > It came up in the meeting last week that we could benefit from a CI
> > subteam with its own meeting, since CI is taking up a lot of the main
> > meeting time.
> >
> > I like this idea, and think we should do something similar for the other
> > informal subteams (tripleoclient, UI), and also add a new subteam for
> > tripleo-quickstart (and maybe one for releases?).
>
> +1, from the meeting and other recent discussions it sounds like defining
> some sub-teams would be helpful, let's try to enumerate those discussed:
>
> - tripleo-ci
> - API (Mistral based API which is landing in tripleo-common atm)
> - Tripleo-UI
> - os-net-config
> - python-tripleoclient
> - tripleo-quickstart
>
> Of these, I think tripleo-ci, tripleo-ui, os-net-config and
> tripleo-quickstart all make sense to create sub-teams.
>
> However it's less clear if we should create separate teams for
> tripleoclient and the API - IMO everyone should care about the CLI flow, so
> it'd be good to encourage broader participation there, but if there's
> consensus we can add that.
>
> In the API case it's tough because it's being proposed to tripleo-common,
> so it'll be difficult to have an ACL which only affects the location of the
> API code.  Also it's another key interface where we probably want to really
> encourage broad participation in review/development - currently there's a
> small team working on the API implementation but I really hope that changes
> when we move the Mistral based API to be in the default deployment flow.
>
> Regarding releases, there actually already is a tripleo-release group, but
> I'm not sure we want to maintain that model long-term, instead we should be
> moving towards the common openstack/releases tooling ref:
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html
>
> Improving our release workflow and figuring out how we align/integrate
> better with the OpenStack coordinated/centralized release is high on my
> TODO list as PTL for Newton, and it's definitely something I'm keen to
> discuss further e.g at summit (and get help with! :)
>
> > We should make seperate ACL's for these subteams as well. The informal
> > approach of adding cores who can +2 anything but are told to only +2
> > what they know doesn't scale very well.
>
> Agreed, there's definitely value in doing this now and it will provide more
> value as our community grows.
>
> 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
>
Very big +1 to this.  I feel like it will help speed up the dev process.

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] [fuel] Unrelated changes in patches

2016-04-04 Thread Jason Rist
On 04/04/2016 07:05 AM, Matthew Mosesohn wrote:
> Hi Dmitry,
>
> I've seen several cases where core reviewers bully contributors into
> refactoring a particular piece of logic because it contains common
> lines relating to some non-ideal code, even if the change doesn't
> relate to this logic.
> In general, I'm ok with formatting issues, but changing how a piece of
> existing code works is over the line. It should be handled as a
> separate bug.
>
> But yes, in general, if someone complains about something unrelated to
> your patch, he or she should just file a bug with what is required.
>
> -Matthew
>
>
> On Mon, Apr 4, 2016 at 3:46 PM, Dmitry Guryanov  
> wrote:
> > Hello, colleagues!
> >
> > It's often not so easy to decide, if you should include some unrelated
> > changes to your patch, like fixing spaces, renaming variables or something
> > else, which don't change logic. On the one hand you see something's wrong
> > with the code and you'd like to fix it, on the other hand reviewers can vote
> > of -1 and you'll have to fix you patch and upload it again and this is very
> > annoying. You can also create separate review for such changes, but it will
> > require additional effort from you and reviewers.
> >
> > If you are a reviewer, and you've noted unrelated changes you may hesitate,
> > if you should ask an author to remove them and upload new version of the
> > patch or not. Also such extra changes may confuse you sometimes.
> >
> > So I suggest creating separate patches for unrelated changes if they add new
> > chucks to patch. And I'd like to ask authors to clearly state in the subject
> > of a commit message, that this patch just fixes formatting. And reviewers
> > shouldn't check such patches too severely, so that they'll get into repo as
> > soon as possible.
> >
> > What do you think?
> >
> >
> > --
> > Dmitry Guryanov
> >
> > __
> > 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
>
I agree with Matthew, but huge +1 to separate patch/bug for 
formatting/whitespace issues.

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] eslint without color?

2016-02-14 Thread Jason Rist
On 02/14/2016 10:45 PM, Richard Jones wrote:
> I'm just curious why our eslint configuration (in packages.json) specifies
> --no-color. It's much harder to spot the errors without color, and I always
> end up running it manually to get the color. Also, karma output has color,
> so why one and not the other?
>
> In short, would anyone object to turning color on for eslint?
>
>
>  Richard
>
>
>
> __
> 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
>
I thought I've seen some color-related characters get parsed incorrectly 
before.  Perhaps it is related to that?

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] spec-lite process for tripleo

2016-01-27 Thread Jason Rist
On 01/27/2016 09:21 AM, Derek Higgins wrote:
> Hi All,
> 
> We briefly discussed feature tracking in this weeks tripleo meeting. I
> would like to provide a way for downstream consumers (and ourselves) to
> track new features as they get implemented. The main things that came
> out of the discussion is that people liked the spec-lite process that
> the glance team are using.
> 
> I'm proposing we would start to use the same process, essentially small
> features that don't warrant a blueprint would instead have a wishlist
> bug opened against them and get marked with the spec-lite tag. This bug
> could then be referenced in the commit messages. For larger features
> blueprints can still be used. I think the process documented by
> glance[1] is a good model to follow so go read that and see what you think
> 
> The general feeling at the meeting was +1 to doing this[2] so I hope we
> can soon start enforcing it, assuming people are still happy to proceed?
> 
> thanks,
> Derek.
> 
> [1]
> http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite
> 
> [2]
> http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.html
> 
> 
> __
> 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

I guess my only thought would be to make the bug/rfe fairly descriptive
so we don't have to go tracking down whoever reported it for more
details.  Maybe just some light rules about age and responsiveness so we
can quickly retire those bugs/rfes that people aren't really paying
attention to.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] Removing the Tuskar repos

2015-12-22 Thread Jason Rist
On 12/22/2015 04:38 AM, Dougal Matthews wrote:
> Hi all,
> 
> I mentioned this at the meeting last week, but wanted to get wider input.
> As far as I can tell from the current activity, there is no work going into
> Tuskar and it isn't being tested with CI. This means the code is becoming
> more stale quickly and likely wont work soon (if not already).
> 
> TripleO common is working towards solving the same problems that Tuskar
> attempted and can be seen as the replacement for Tuskar. [1][2]
> 
> Are there any objections to it's removal? This would include the tuskar,
> python-tuskarclient and tuskar-ui repos. We would also need to remove it
> from instack-undercloud and tripleo-image-elements.
> 
> I'll start to beginning the cleanup process sometime in min/late January if
> there are no objections.
> 
> Cheers,
> Dougal
> 
> 
> [1]:
> https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka/tripleo-overcloud-deployment-library.html
> [2]: https://review.openstack.org/230432
> 
> 
> 
> __
> 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

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen

__
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] [ironic] Summit recap

2015-11-02 Thread Jason Rist
On 11/02/2015 03:29 PM, Jim Rollenhagen wrote:
> Hi friends,
>
> I wrote a recap of the summit (from my perspective) that some of you may
> find interesting. Feedback is very welcome. :)
>
> http://words.jimrollenhagen.com/mitaka-summit-recap/
>
> // jim
>
> __
> 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
>
I can't tell you how much I appreciate this.  I wish every project did this, 
particularly Horizon.

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen

__
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] trello

2015-09-09 Thread Jason Rist
On 09/09/2015 07:09 AM, Derek Higgins wrote:
>
>
> On 08/09/15 16:36, Derek Higgins wrote:
> > Hi All,
> >
> > Some of ye may remember some time ago we used to organize TripleO
> > based jobs/tasks on a trello board[1], at some stage this board fell out
> > of use (the exact reason I can't put my finger on). This morning I was
> > putting a list of things together that need to be done in the area of CI
> > and needed somewhere to keep track of it.
> >
> > I propose we get back to using this trello board and each of us add
> > cards at the very least for the things we are working on.
> >
> > This should give each of us a lot more visibility into what is ongoing
> > on in the tripleo project currently, unless I hear any objections,
> > tomorrow I'll start archiving all cards on the boards and removing
> > people no longer involved in tripleo. We can then start adding items and
> > anybody who wants in can be added again.
>
> This is now done, see
> https://trello.com/tripleo
>
> Please ping me on irc if you want to be added.
>
> >
> > thanks,
> > Derek.
> >
> > [1] - https://trello.com/tripleo
> >
> > __
> >
> > 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
Derek - you weren't on today when I went to ping you, can you please add me so 
I can track it for RHCI purposes?

Thanks!

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen

__
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] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

2015-06-04 Thread Jason Rist
On 06/04/2015 11:58 AM, Steven Dake (stdake) wrote:
 Hey folks,
 
 I think it is critical for self-service needs that we have a Horizon 
 dashboard to represent Magnum.  I know the entire Magnum team has no 
 experience in UI development, but I have found atleast one volunteer Bradley 
 Jones to tackle the work.
 
 I am looking for more volunteers to tackle this high impact effort to bring 
 Containers to OpenStack either in the existing Magnum core team or as new 
 contributors.   If your interested, please chime in on this thread.
 
 As far as “how to get patches approved”, there are two models we can go with.
 
 Option #1:
 We add these UI folks to the magnum-core team and trust them not to +2/+A 
 Magnum infrastructure code.  This also preserves us as one team with one 
 mission.
 
 Option #2:
 We make a new core team magnum-ui-core.  This presents special problems if 
 the UI contributor team isn’t large enough to get reviews in.  I suspect 
 Option #2 will be difficult to execute.
 
 Cores, please vote on Option #1, or Option #2, and Adrian can make a decision 
 based upon the results.
 
 Regards
 -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
 

I am interested in helping as well.  In my experience, #1 works best,
but I'm not a core, so I'm not sure my wisdom is counted here.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen

__
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] Midcycle Summary

2015-02-24 Thread Jason Rist
On 02/24/2015 07:48 AM, James Slagle wrote:
 Hi Everyone,

 TripleO held a midcycle meetup from February 18th-20th in Seattle. Thanks to 
 HP
 for hosting the event! I wanted to send out a summary of what went on. We also
 captured some notes on an etherpad[0].

 The first order of business was that I volunteered to serve as PTL of TripleO
 for the remainder of the Kilo cycle after Clint Byrum announced that he was
 stepping down due to a change in focus. Thanks Clint for serving as PTL so far
 throughout Kilo!

 We moved on to talking about the state of TripleO in general. An immediate
 topic of discussion was CI stability, especially as all of our jobs were
 currently failing at the time. It appeared that most agreed that our actual CI
 stability was pretty good overall and that most of the failures continue to be
 caused by finding bugs in our own code and regressions in other projects that
 end up breaking TripleO. There was a lot of agreement that the TripleO CI was
 very useful and continues to find real breakages in OpenStack that are 
 otherwise
 missed.

 We talked a bit about streamlining the CI jobs that are run by getting rid of
 the undercloud jobs entirely or using the jenkins worker as the seed itself.

 As it typically tends to do, the discussion around improving our CI drifted
 into the topic of QuintupleO. Everyone seems to continue to agree that
 QuintupleO would be really helpful to CI and development environments, but 
 that
 no one has time to work on it. The idea of skipping the Ironic PXE/iscsi
 deployment process entirely and just nova boot'ing our instances as regular vm
 images was brought up as a potential way to get QuintupleO off the ground
 initially. You'd lose out on the coverage around Ironic, but it could still be
 very valuable for testing all the other stuff such as large HA deployments
 using Heat, template changes, devtest, etc.

 We moved onto talking about diskimage-builder. Due to some shifts in focus,
 there were some questions about any needed changes to the core team
 of diskimage-builder. In the end, it was more or less decided that any such
 changes would just be disruptive at this point, and that we could instead be
 reactive to any changes that might be needed in the future.

 There were lots of good ideas about how to improve functional testing of
 diskimage-builder and giving it a proper testsuite outside of TripleO CI.
 Functional and unit testing of the individual elements and hook scripts is 
 also
 desired. While there was half a session devoted to the unit testing aspect at
 the Paris summit, we haven't yet made a huge amount of progress in this area,
 but it sounds like that might soon change.

 The tripleo-heat-templates was the next topic of discussion. With having
 multiple implementations in tree, we agreed it was time to deprecate the
 merge.py templates[1]. This will also free up some CI capacity for new jobs
 after the removal of those templates.

 We talked about backwards compatibility as well. The desire here was around
 maintaining the ability to deploy stable versions of OpenStack for the
 Overcloud with the TripleO tooling. Also, it was pointed out that the new
 features that have been rolling out to the TripleO templates are for the
 Overcloud only, so we're not breaking any ability to upgrade the Undercloud.

 Dan Prince gave a detailed overview of the Puppet and TripleO integration
 that's been ongoing since a little before Paris. A lot of progress has been
 made very quickly and there is now a CI job in place exercising a deployment
 via Puppet using the stackforge puppet modules. I don't think I need to go 
 into
 too much more detail here, because Dan already summarized it previously on
 list[2].

 The Puppet talk led into a discussion around the Heat breakpoints feature and
 how that might be used to provide some aspect of workflow while doing a
 deployment. There were some concerns raised that using breakpoints in that way
 was odd, especially since they're not represented in the templates at all. In
 the end, I think most agreed that there was an opportunity here to drive
 further features in Heat to meet the use cases that are trying to be solved
 around Overcloud deployments using breakpoints.

 One theme that resurfaced a few times throughout the midcycle was ways that
 TripleO could better define it's interfaces to make different parts pluggable,
 even if that's just documentation initially. Doing so would allow TripleO to
 integrate more easily with existing solutions that are already in use.

 Thanks again to everyone who was able to participate in the midcycle, and as
 well to those who stayed home and did actual work...such as fixing CI.

 For other folks who attended, feel free to add some details, fill in
 any gaps, or
 disagree with my recollection of events :-).

 [0] https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup
 [1] https://review.openstack.org/#/c/158410/
 [2] 
 

Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-14 Thread Jason Rist
On 01/14/2015 09:14 AM, Matthew Farina wrote:
 I think we're discussing two different situations with slightly different
 requirements.
 
 First, there is development and test. I believe the stated goal is to have
 node.js here. Would an environment not supporting node.js be needed for
 development or testing? Note, the JavaScript under test and to be executed
 by users is in browser rather than server side. The important execution
 environment is in their browser.
 
 The second environment is production. In that case the system packages
 would be used. What's still unclear is who creates and maintains those
 packages since many of them don't exist today.
 
 
 On Wed, Jan 14, 2015 at 10:14 AM, Drew Fisher drew.fis...@oracle.com
 wrote:
 


 On 1/14/15 6:25 AM, Anton Zemlyanov wrote:
 Solaris is supported by node.js:

 x86 is certainly supported.  Always has been.  That's not the issue in
 question.  My point was that SPARC is not supported.


 Solaris 32-bit Binary:
 http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz
 Solaris 64-bit Binary:
 http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz

 I think Solaris is no longer relevant

 I won't stoop to comment on this statement other than to say Solaris is
 quite relevant to Oracle, Oracle's customers and Oracle's partners.

 -Drew


Seems to me like you'd want to test using packages for SPARC, not using
a dev sort of environment.  Packages again for production. My two cents
is that you need to contribute to the node community if you require
SPARC compatibility for node for development, since SPARC is an outlier.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen

__
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] Separate horizon and openstack_dashboard

2014-11-17 Thread Jason Rist
On 11/17/2014 06:43 AM, Yves-Gwenaël Bourhis wrote:
 Le 17/11/2014 14:19, Matthias Runge a écrit :
 
 There is already horizon on pypi[1]

 IMHO this will lead only to more confusion.

 Matthias


 [1] https://pypi.python.org/pypi/horizon/2012.2
 
 Well the current horizon on Pypi is The OpenStack Dashboard +
 horizon(_lib) included
 
 If the future horizon on pypi is openstack_dashboard alone, it would
 still pull horizon_lib as a dependency, so it would not brake the
 existing.
 
 So indeed the horizon package itself in Pypi would not have
 horizon(_lib) in it anymore, but he pip install horizon would pull
 everything due to the dependency horizon will have with horizon_lib.
 
 I find this the least confusing issue and the horizon package on Pypi
 would still be seen as The OpenStack Dashboard like it is now. We
 would only add an horizon_lib package on Pypi.
 Therefore existing third-party requirements.txt would not brake
 because they would pull horizon_lib with horizon. and they would still
 import the proper module. Every backwards compatibility (requirements
 and module) is therefore preserved.
 
 

+1 to this solution

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [Cinder][TripleO] Last days to elect your PTL!

2014-10-03 Thread Jason Rist
On 10/01/2014 08:22 PM, Tristan Cacqueray wrote:
 Hello Cinder and TripleO contributors,

 Just a quick reminder that elections are closing soon, if you haven't
 already you should use your right to vote and pick your favourite candidate!

 Thanks for your time!
 Tristan



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

Hi Tristan - I'm not a super heavy contributor, but I think I have a few 
commits.  I didn't ever get an email from the voting provider?

Thanks,
Jason

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [Horizon] SCSS conversion and SCSS upgrade patches

2014-06-30 Thread Jason Rist
On Mon 30 Jun 2014 08:09:40 AM MDT, Douglas Fish wrote:

 I had an IRC discussion with jtomasek and rdopieralski recently regarding
 Radomir's patch for converting to SCSS bootstrap.
 https://review.openstack.org/#/c/90371/   We were trying to sort out how
 soon this patch should merge.  We'd like to discuss this at the team
 meeting tomorrow, but I'm sharing here to get an initial discussion
 started.

 It seems that in this version of bootstrap SCSS had some bugs.  They are
 low impact, but pretty obvious bugs - I saw mouseover styling and disable
 button styling problems.

 The most straightforward fix to this is to upgrade bootstrap.  I understand
 that Jiri is working on that this week, and would like to have the SCSS
 patch merged ASAP to help with that effort.

 My feeling is that we shouldn't merge the SCSS patch until we have a
 bootstrap patch ready to merge.  I'd like to see dependent patches used to
 manage this so we can get both changes reviewed and merged at the same
 time.

 Radomir has shared that he thinks dependent patches are too painful to use
 for this situation.  Also he'd like to see the SCSS bootstrap patch merged
 ASAP because the horizon split depends on that work as well.

 Doug Fish


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

I agree with Radomir and will voice that same opinion during the 
meeting.  Lets get the SCSS patch up, and then everyone can contribute 
to improvements, not just Jiri.

-J

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [Horizon] Quick Survey: Horizon Mid-Cycle Meetup

2014-06-19 Thread Jason Rist
On Thu 19 Jun 2014 01:58:15 AM MDT, 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 to the meeting?
 * What topics do we want to discuss?

 https://etherpad.openstack.org/p/horizon-juno-meetup

 Thanks for bringing this up!

 Do we really have items to discuss, where it needs a meeting in person?

 Matthias

IMO, nothing we haven't already discussed at the summit, like the split.

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects

2014-06-16 Thread Jason Rist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon 16 Jun 2014 10:19:40 AM MDT, Tomas Sedovic wrote:
 All,
 
 After having proposed some changes[1][2] to
 tripleo-heat-templates[3], reviewers suggested adding a deprecation
 period for the merge.py script.
 
 While TripleO is an official OpenStack program, none of the
 projects under its umbrella (including tripleo-heat-templates) have
 gone through incubation and integration nor have they been shipped
 with Icehouse.
 
 So there is no implicit compatibility guarantee and I have not
 found anything about maintaining backwards compatibility neither on
 the TripleO wiki page[4], tripleo-heat-template's readme[5] or 
 tripleo-incubator's readme[6].
 
 The Release Management wiki page[7] suggests that we follow
 Semantic Versioning[8], under which prior to 1.0.0 (t-h-t is )
 anything goes. According to that wiki, we are using a stronger
 guarantee where we do promise to bump the minor version on
 incompatible changes -- but this again suggests that we do not
 promise to maintain backwards compatibility -- just that we
 document whenever we break it.
 
 According to Robert, there are now downstreams that have shipped
 things (with the implication that they don't expect things to
 change without a deprecation period) so there's clearly a
 disconnect here.
 
 If we do promise backwards compatibility, we should document it 
 somewhere and if we don't we should probably make that more
 visible, too, so people know what to expect.
 
 I prefer the latter, because it will make the merge.py cleanup
 easier and every published bit of information I could find suggests
 that's our current stance anyway.
 
 Tomas
 
 [1]: https://review.openstack.org/#/c/99384/ [2]:
 https://review.openstack.org/#/c/97939/ [3]:
 https://github.com/openstack/tripleo-heat-templates [4]:
 https://wiki.openstack.org/wiki/TripleO [5]: 
 https://github.com/openstack/tripleo-heat-templates/blob/master/README.md

 
[6]: https://github.com/openstack/tripleo-incubator/blob/master/README.rst
 [7]: https://wiki.openstack.org/wiki/TripleO/ReleaseManagement [8]:
 http://semver.org/
 
 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I'm going to have to agree with Tomas here.  There doesn't seem to be
any reasonable expectation of backwards compatibility for the reasons
he outlined, despite some downstream releases that may be impacted.

- -J
- -- 
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen
- -- 
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTnxutAAoJEMqxYTi6t2f4Mh4H+gOF3aUZwIxY9FSEW/Hj1EjJ
eDSDDPuOwWSlMn8VNmEq44ks7KNgGDU/qpjaDUjAJ8BCEm4cXi8JtS7zYsPJJeY3
t3z/cFPkyhWLgg0qQYOB03rbqYGX58G43xa8lFjvVi7GyfqCSKJ3AxauF2bDkx+b
FoQztiaHvU09dw77JmvTxPJ2CpsvBHGaLkG3NneVIBNA8WtnBqKUQrT63ZnP8K++
G98SoMSNpXlztVEnElFMZoi+Lr7rO/37kP9CvqYtXBaDgL2Wbj6B+21Pn5OUVcXd
MTy0CcvvpM/P08DNFW9+coHJcQOKJSeAYuDxn8z0+bpyJkAiSf9o4zlWOWtavfU=
=qXmp
-END PGP SIGNATURE-

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


Re: [openstack-dev] [all] gerrit-dash-creator - much easier process for creating client side dashboards

2014-06-13 Thread Jason Rist
On Fri 13 Jun 2014 02:38:11 AM MDT, Giulio Fidente wrote:
 On 05/31/2014 03:56 PM, Sean Dague wrote:
 We're still working on a way to make it possible to review in server
 side gerrit dashboards more easily to gerrit. In the mean time I've put
 together a tool that makes it easy to convert gerrit dashboard
 definitions into URLs that you can share around.

 a bit off topic but useful to better user and share the 'shortened'
 url we get

 is anyone aware of a service allowing to 1) update an existing
 'shortened' url 2) customize the 'shortened' url a bit 3) has an api?

 reason for the third would be that everytime a change is merged into a
 .dash file we would update the urls automatically


I can't guarantee this but I think bit.ly falls into those categories.

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


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

2014-06-11 Thread Jason Rist
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.

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda

2014-05-30 Thread Jason Rist
On Fri 30 May 2014 04:13:31 AM MDT, Jaromir Coufal wrote:
 Hi All,

 I would like to propose to add Tuskar as a permanent topic to the
 agenda for our weekly IRC meetings. It is an official TripleO's
 project, there happening quite a lot around it and we are targeting
 for Juno to have something solid. So I think that it is important for
 us to regularly keep track on what is going on there.

 -- Jarda

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

+1

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda

2014-05-30 Thread Jason Rist
On Fri 30 May 2014 02:37:49 PM MDT, James Polley wrote:


 On 30 May 2014, at 8:13 pm, Jaromir Coufal jcou...@redhat.com wrote:

 Hi All,

 I would like to propose to add Tuskar as a permanent topic to the agenda for 
 our weekly IRC meetings. It is an official TripleO's project, there 
 happening quite a lot around it and we are targeting for Juno to have 
 something solid. So I think that it is important for us to regularly keep 
 track on what is going on there.


 Sounds good to me.

 What do you think we would talk about under this topic? I'm thinking that a 
 brief summary of changes since last week, and any blockers tuskar is seeing 
 from the broader project would be a good start?

 -- Jarda

 ___
 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

Initially I also think it'd be good to cover some of the plans for Juno 
and how they're progressing?

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [Horizon] Selenium test fixes

2014-05-28 Thread Jason Rist
On 05/27/2014 11:45 PM, Kieran Spear wrote:
 No failures in the last 24 hours. \o/
 
 On 26 May 2014 23:44, Kieran Spear kisp...@gmail.com wrote:
 Hi peeps,

 Could I ask reviewers to prioritise the following:

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

 It should eliminate our selenium gate failures, which seem to be happening 
 many times per day now.

 Cheers,
 Kieran

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


Well done!

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [UX] Initial kick-off IRC meeting

2014-05-23 Thread Jason Rist
On Fri 23 May 2014 06:00:37 AM MDT, Jaromir Coufal wrote:
 Apologies, the time was already in conflict with other meetings. But I
 managed to find a slot for the one on Monday, so the kick-off meeting
 will be:

 * Monday, June 2, 2014 at 17000 UTC
 * openstack-meeting-3

 One more time apologies for this change
 -- Jarda

 On 2014/23/05 12:58, Jaromir Coufal wrote:
 Dear UXers,

 I am happy with your interest in regular OpenStack UX IRC meetings.
 Based on the poll (http://doodle.com/3m29dkn3ef2em5in), there are few
 slots which fit majority of interested people. Unfortunately few other
 teams took empty slots in the meantime so I had to pick first free slot
 which has the most votes.

 I would like to start with initial kick-off meeting on:
 * Wednesday, June 4, 1500 UTC
 * openstack-meting-3

 For more details:
 https://wiki.openstack.org/wiki/Meetings#User_Experience_.28UX.29_Team_Meeting



 I will fill in the agenda during the next week, but also feel free to
 add topics which you would like to discuss:
 https://wiki.openstack.org/wiki/Meetings/UX

 I would like also to ask all participants to fill yourselves into
 following etherpad and assign yourselves to correct timezones, so that
 we can arrange the meeting time to be the most convenient for all:
 https://etherpad.openstack.org/p/ux-meetings

 For people who can't attend (didn't tick this time slot) - if you could
 make one exception for this initial meeting it would be great to see you
 there, we can discuss timing of these meetings there (alternating
 possibility). If you can't, I will try to connect with you on IRC to
 discuss further.

 Also, preferred communication channel for day-to-day communication is
 #openstack-ux, join us who's not there yet ;)

 Thanks all, see you at the first meeting
 -- Jarda

 ___
 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

Hi Jarda - How long do you expect the meeting to last? Thanks!

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [TripleO] Installation instructions

2014-05-21 Thread Jason Rist
On 05/21/2014 02:22 PM, Sanchez, Cristian A wrote:
 Hi,
 In our team we’re planning to make some contributions to TripleO, after we 
 met with Robert Collins in an Intel hosted meeting during Summit.
 As our first step we want to use TripleO to deploy the under-cloud and 
 over-cloud. Is there some instructions of how to start with this?
 
 Thanks
 
 Cristian
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

Hi Cristian - There are quite a few options.  Some of us do devtest:
https://wiki.openstack.org/wiki/Tuskar/Devtest

Some of us do instack:
https://github.com/slagle/instack

And some of us do devstack and then fire up another horizon with
tuskar-ui running:
https://github.com/openstack/tuskar-ui/blob/master/doc/source/install.rst

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [horizon] Unofficial Sunday Summit Meetup

2014-05-11 Thread Jason Rist
On Sun 11 May 2014 03:32:52 AM MDT, Aditya Thatte wrote:
 Is this meeting confirmed? I've reached Atlanta, and staying at the Hilton
 Garden Inn.


 On Tue, May 6, 2014 at 10:10 PM, Jason Rist jr...@redhat.com wrote:

 On Tue 06 May 2014 10:29:43 AM MDT, Jaromir Coufal wrote:
 Hi folks,

 during Horizon's IRC meeting, we got to the idea that it would be
 great to hang out on Sunday evening and meet unofficially before the
 Summit.

 We are gathering all suggestions in following etherpad:
 https://etherpad.openstack.org/p/juno-summit-horizon-sunday-evening
 (you can find the latest info here).

 So everybody interested - join us - we are looking forward to all of
 you! :)

 -- Jarda

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

 At the moment, looks like we're planning on meeting at the Westin
 Sundial restaurant bar at 8PM!  See the etherpad for more info.

 -Jason

 --
 Jason E. Rist
 Senior Software Engineer
 OpenStack Management UI
 Red Hat, Inc.
 openuc: +1.972.707.6408
 mobile: +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





I think so. I'm going to be late, due to my flight being delayed out of 
Denver. Might miss it!

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [horizon] Unofficial Sunday Summit Meetup

2014-05-06 Thread Jason Rist
On Tue 06 May 2014 10:29:43 AM MDT, Jaromir Coufal wrote:
 Hi folks,

 during Horizon's IRC meeting, we got to the idea that it would be
 great to hang out on Sunday evening and meet unofficially before the
 Summit.

 We are gathering all suggestions in following etherpad:
 https://etherpad.openstack.org/p/juno-summit-horizon-sunday-evening
 (you can find the latest info here).

 So everybody interested - join us - we are looking forward to all of
 you! :)

 -- Jarda

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

At the moment, looks like we're planning on meeting at the Westin 
Sundial restaurant bar at 8PM!  See the etherpad for more info.

-Jason

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +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


Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session

2014-04-25 Thread Jason Rist
On 04/24/2014 09:10 AM, Liz Blanchard wrote:
 Hi All,
 
 One of the sessions that I proposed for the Horizon track is to review the 
 results that we got from the Usability Test that was run on Horizon in early 
 March. I wanted to share some of the background of this test and the high 
 level results with you all so that we can start the conversation on this list 
 and then continue with agreeing on next steps during Summit. There will be a 
 few follow-ups to this e-mail from myself and Jacki Bauer which will propose 
 some potential solutions to the high priority findings, so be on the look out 
 for those :)
 
 ---Quick overview of Usability Testing...What is it? Why do it?---
 Usability testing is a technique used in user-centered interaction design to 
 evaluate a product by testing it on users. This can be seen as an 
 irreplaceable usability practice, since it gives direct input on how real 
 users use the system.
 
 ---Who was involved? What did we need to do to prepare?---
 A number of user experience engineers from a bunch of different companies got 
 together and helped plan for a usability test that would focus on 
 self-service end users and the ease of use of the Horizon Dashboard as it 
 exists for the Icehouse release. This effort spun off from the Persona work 
 that we've been doing together. Some folks in the group are just getting into 
 contributing to the design of OpenStack and doing a baseline usability test 
 of Horizon was a great introduction to how the usability of the Horizon UI 
 could continue to be improved based on user's direct feedback.
 
 What we needed to get done before actually jumping into the testing:
 1) Agree on the goals of the testing.
 2) Create a screener and send out to the OpenStack community.
 3) Create a list of tasks that the user would complete and give feedback 
 on during the testing.
 
 ---Who we tested?---
 6 people who we considered to be self-service end users based on their 
 screener responses.
 
 ---What were the tasks that were tested?---
 
 Scenario 1: Launching an instance
 Individual Tasks:
 -Create a security key pair.
 -Create a network.
 -Boot from cirros image.
 -Confirm that instance was launched successfully.
  
 Scenario 2: Understand how many vCPUs are currently in use vs. how much quota 
 is left.
 Individual Tasks:
 -Check out Overview Page to review current quota use/limit details.
  
 Scenario 3: Take a snapshot of an Instance to save for later use.
 Individual Tasks:
 -Either Launch an instance successfully, or identify a running instance in 
 the instance view.
 -Choose to take a snapshot of that instance.
 -Confirm that the snapshot was successful.
  
 Scenario 4: Launch an instance from a snapshot.
 Individual Tasks:
 -Choose to either create an instance and boot from a snapshot, or identify a 
 snapshot to create an instance from.
 -Confirm that the instance was started successfully.
  
 Scenario 5: Launch an instance that boots from a specific volume.
 Individual Tasks:
 -Create a volume.
 -Launch an instance using Volume X as a boot source.
 
 ---When and how we ran the tests?---
 These hour long tests were run over the first two weeks of March 2014. We 
 focused on the latest bits that could be seen in the Icehouse release. The 
 moderator (a UX researcher from HP) would ask the questions and the rest of 
 the group would vigourously take notes :) After all of the testing was 
 complete, we spent some time together debriefing and agreeing on the 
 prioritized list of updates that would be best to make to the Horizon UI 
 based on user feedback.
 
 ---What were the findings?---
 
 High Priority
 * Improve error messages and error message catalog.
 * Fix Launch Instance workflow for end user and power user.
 * Improve informational help information about form fields.
 * Fix terminology. (e.g. launch instance, boot, shutoff, shutdown, etc.)
 * Show details for key pair and network in Launch Instance workflow.
 * Recommend a new Information Architecture.
  
 Medium Priority
 * Create UI guidelines (of best practices) for Developers to use.
 * Improve Online Help.
 * Provide clearer indication the application is working after clicking a 
 button and the application doesn’t respond immediately.
 * Ensure consistency of network selection. (Drag and drop of networks very 
 inconsistent from the other pieces of the launch instance modal)
 * Create consistency of visualizations and section of action button 
 recommendations on Instance table.
 * Suggest defaults for the forms entry fields.
 * Provide Image information details during image selection.
  
 Low Priority
 * Allow users to edit the network an instance after launching instance.
 * Resolve confusion around the split inline actions button.
 * Explain what the Instance Boot Source field in Create Instance modal.
 * Provide description/high level information about flavors for flavor 
 selection.
 * Make sorting clearer visually.
 * Provide solution for subnet 

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

2014-03-05 Thread Jason Rist
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.

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


Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

2014-02-19 Thread Jason Rist
On Wed 19 Feb 2014 10:29:32 AM MST, Dougal Matthews wrote:
 On 19/02/14 17:10, Ladislav Smola wrote:
 Hello,

 I would like to have your opinion about how to deal with passwords in
 Tuskar-API

 The background is, that tuskarAPI is storing heat template parameters in
 its database, it's a
 preparation for more complex workflows, when we will need to store the
 data before the actual
 heat stack-create.

 So right now, the state is unacceptable, we are storing sensitive
 data(all the heat passwords and keys)
 in a raw form in the TuskarAPI database. That is wrong right?

 I agree, this situation needs to change.

 I'm +1 for not storing the passwords if we can avoid it. This would
 apply to all situations and not just Tuskar.

 The question for me, is what passwords will we have and when do we
 need them? Are any of the passwords required long term.

 If we do need to store passwords it becomes a somewhat thorny issue,
 how does Tuskar know what a password is? If this is flagged up by the
 UI/client then we are relying on the user to tell us which isn't wise.

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

Would it be possible to create some token for use throughout? Forgive 
my naivete.

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


Re: [openstack-dev] [Horizon] RFC - Suggestion for switching from Less to Sass (Bootstrap 3 Sass support)

2014-02-05 Thread Jason Rist
On Wed 05 Feb 2014 09:32:54 AM MST, Jaromir Coufal wrote:
 Dear Horizoners,

 in last days there were couple of interesting discussions about
 updating to Bootstrap 3. In this e-mail, I would love to give a small
 summary and propose a solution for us.

 As Bootstrap was heavily dependent on Less, when we got rid of node.js
 we started to use lesscpy. Unfortunately because of this change we
 were unable to update to Bootstrap 3. Fixing lesscpy looks problematic
 - there are issues with supporting all use-cases and even if we fix
 this in some time, we might challenge these issues again in the future.

 There is great news for Bootstrap. It started to support Sass [0].
 (Thanks Toshi and MaxV for highlighting this news!)

 Thanks to this step forward, we might get out of our lesscpy issues by
 switching to Sass. I am very happy with this possible change, since
 Sass is more powerful than Less and we will be able to update our
 libraries without any constraints.

 There are few downsides - we will need to change our Horizon Less
 files to Sass, but it shouldn't be very big deal as far as we
 discussed it with some Horizon folks. We can actually do it as a part
 of Bootstrap update [1] (or CSS files restructuring [2]).

 Other concern will be with compilers. So far I've found 3 ways:
 * rails dependency (how big problem would it be?)
 * https://pypi.python.org/pypi/scss/0.7.1
 * https://pypi.python.org/pypi/SassPython/0.2.1
 * ... (other suggestions?)

 Nice benefit of Sass is, that we can use advantage of Compass
 framework [3], which will save us a lot of energy when writing (not
 just cross-browser) stylesheets thanks to their mixins.

 When we discussed on IRC with Horizoners, it looks like this is good
 way to go in order to move us forward. So I am here, bringing this
 suggestion up to whole community.

 My proposal for Horizon is to *switch from Less to Sass*. Then we can
 unblock our already existing BPs, get Bootstrap updates and include
 Compass framework. I believe this is all doable in Icehouse timeframe
 if there are no problems with compilers.

 Thoughts?

 -- Jarda

 [0] http://getbootstrap.com/getting-started/
 [1] https://blueprints.launchpad.net/horizon/+spec/bootstrap-update
 [2] https://blueprints.launchpad.net/horizon/+spec/css-breakdown
 [3] http://compass-style.org/

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

I think this is a fantastic idea. Having no experience with Less, but 
seeing that it is troublesome - if we can use SASS/Compass, I'd be much 
more comfortable with the switch. +1

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
+1.919.754.4048
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


Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles

2014-01-28 Thread Jason Rist
I thought we were avoiding using overcloud and undercloud within 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.  Future plans for the tuskar-ui include management of the
 undercloud as well, and at that point, 'deployment role' becomes vague, as
 it could also logically apply to the undercloud.
 
 For that reason, I think we should call it an 'overcloud deployment role',
 or 'overcloud role' for short.
 
 That being said, I think that the UI could get away with just displaying
 'Role', as presumably the user would be in a page with enough context to
 make it clear that he's in the overcloud section.
 
 
 Mainn
 
 - Original Message -
 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




-- 
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
+1.919.754.4048
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