Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?
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
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
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
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
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
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
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
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 individual
Re: [openstack-dev] [Horizon] Draft team mascot
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
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
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
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
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
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
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 abov
Re: [openstack-dev] [heat][tripleo][horizon][tripleo-ui] Parameter groups, tags and deprecation
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 w
[openstack-dev] [TripleO][UI] Review priorities for feature freeze
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?
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) > > 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 mailto:rbr...@redhat.com>> > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > > <mailto:openstack-dev@lists.openstack.org>> > > Date: Tuesday, 28 June 2016 at 17:08 > > To: Jason Rist mailto:jr...@redhat.com>>, "OpenStack > > Development Mailing List (not for usage questions)" > > > <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 > <mailto:jr...@redhat.com>> wrote: > >> On 06/27/2016 06:57 AM, Dougal Matthews wrote: > >>> On 27 June 2016 at 07:45, Renat Akhmerov >>> <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 > >> 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > >> > > > > > > > > -- > > Ryan Brady > > Cloud Engineering > > rbr...@redhat.com <mailto:rbr...@redhat.com> > > 919.890.8925 > > __ > > 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 was thinking of a tornado with eyes or a tasmanian devil. Both are wind related. Thoughts? -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] TripleO deep dive hour?
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&a 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
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
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
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 ar
[openstack-dev] [TripleO] Summit Summary?
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?
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?
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
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?
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
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
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
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
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
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
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
Re: [openstack-dev] [horizon] static files handling, bower/
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 > 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
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!
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
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
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
-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
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
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
On Fri 30 May 2014 02:37:49 PM MDT, James Polley wrote: > > >> On 30 May 2014, at 8:13 pm, 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. >> > > 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] [TripleO] Adding Tuskar to weekly IRC meetings agenda
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] Should #tuskar business be conducted in the #tripleo channel?
On Thu 29 May 2014 10:25:02 AM MDT, Anita Kuno wrote: > As I was reviewing this patch today: > https://review.openstack.org/#/c/96160/ > > It occurred to me that the tuskar project is part of the tripleo > program: > http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n247 > > I wondered if business, including bots posting to irc for #tuskar is > best conducted in the #tripleo channel. I spoke with Chris Jones in > #tripleo and he said the topic hadn't come up before. He asked me if I > wanted to kick off the email thread, so here we are. > > Should #tuskar business be conducted in the #tripleo channel? > > Thanks, > Anita. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think it should, as it relates to TripleO, but it tends to be specific to Tuskar stuff, and #tripleo is pretty noisy sometimes with gerrit and triage bots. Should it still be separate? -- 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
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 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
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
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
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 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
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
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
Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core
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
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)
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
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
