Re: [openstack-dev] [tripleo] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core
Gaël has been added to the validations core team. Welcome! On Fri, Dec 8, 2017 at 6:56 PM, Alex Schultz <aschu...@redhat.com> wrote: > +1 > > On Thu, Dec 7, 2017 at 7:34 AM, Ana Krivokapic <akriv...@redhat.com> > wrote: > > Hey TripleO devs, > > > > Gaël has consistently been contributing high quality reviews and patches > to > > the tripleo-validations project. The project would highly benefit from > his > > addition to the core reviewer team. > > > > Assuming that there are no objections, we will add Gaël to the core team > > next week. > > > > Thanks! > > > > -- > > Regards, > > Ana Krivokapic > > Senior Software Engineer > > OpenStack team > > Red Hat Inc. > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core
Hey TripleO devs, Gaël has consistently been contributing high quality reviews and patches to the tripleo-validations project. The project would highly benefit from his addition to the core reviewer team. Assuming that there are no objections, we will add Gaël to the core team next week. Thanks! -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Facilitating automation testing in TripleO UI
Hi TripleO devs, In our effort to make the TripleO UI code friendlier to automation testing[1], there is an open review[2] for which we seem to have some difficulty reaching the consensus on how best to proceed. There is already a discussion happening on the review itself, and I'd like to move it here, rather than having it in a Gerrit review. The tricky part is around adding HTML element ids to the Nodes page. This page is generated by looping through the list of registered nodes and displaying complete information about each of them. Because of this, many of the elements are repeating on the page (CPU info, BIOS, power state, etc, for each node). We need to figure out how to make these elements easy for the automation testing code to access, both in terms of locating a single group within the page, as well as distinguishing the individual elements of a group from each other. There are several approaches that we've come up so far: 1) Add unique IDs to all the elements. Generate unique `id` html attributes by including the node UUID in the value of the `id` attribute. Do this for both the higher level elements (divs that hold all the information about a single node), as well as the lower level (the ones that hold info about BIOS, CPU, etc). The disadvantage of this approach is cluttering the UI codebase with many `id` attributes that would otherwise not be needed. 2) Add CSS classes instead of IDs. Pros for this approach: no need to generate the clumsy ids containing the node UUID, since the CSS classes don't need to be unique. Cons: we would be adding even more classes to HTML elements, many of which are already cluttered with many classes. Also, these classes would not exist anywhere in CSS or serve any other purpose. 3) Add custom HTML attributes. These usually start with the 'data-' prefix, and would not need to be unique either. Pros: avoids the problems described with both approaches above. Cons: AFAIU, the React framework could have problems with custom attributes (Jirka can probably explain this better). Also, casual readers of the code could be confused about the purpose of these attributes, since no other code present in the UI codebase is using them in any way. It seems that a perfectly optimal solution does not exist here and we will have to compromise on some level. Let's try and figure out what the best course of action here is. [1] https://blueprints.launchpad.net/tripleo/+spec/testing-ids [2] https://review.openstack.org/#/c/483039/ -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Plan description in the create/update plan form
Resending with the [tripleo] tag, sorry... On Thu, Jun 29, 2017 at 2:22 PM, Ana Krivokapic <akriv...@redhat.com> wrote: > Hi TripleO devs, > > I am working on adding a description field to the "Crate Plan" form in the > TripleO UI [1]. The goal is to make it possible for the user to specify a > plan description using a form field when creating a plan. As the plan > description lives in the plan-environment.yaml file[2], the idea is to > retrieve this value from plan-environment.yaml when the user uploads the > plan, populate the form field with it, let the user change it, and then > save it back to the file. > > I have a WIP patch up [3] which solves the issue in the case of uploading > the plan as a folder. However, I am having a hard time solving the case of > uploading the plan as a tarball. The issue is obviously with accessing the > contents of the tarball. Here are some possible approaches that come to > mind: > > 1) Use one of the existing third-party JS libraries that can extract a > tarball in the browser. Pros: front-end only solution, no need for > additional API calls, no need for back-end changes. Cons: adding a new > dependency, these libraries don't seem much maintained. > > 2) Use swift to upload and extract the tarball. Pros: no need for back-end > changes, we can just call the swift API. Cons: splitting the tarball upload > from plan creation, which should really be one atomic operation. > > 3) Modify the plan create workflow to accept a plan description as a > parameter. Pros: keeps plan creation atomic. Cons: changes to the plan > create workflow interface needed. Also this way there is no way to send > back the information about the description to the UI, we would have to just > accept the value of the form field, and overwrite whatever was in the > plan-environment.yaml file. > > Of course there is also a fourth option: > > 4) This is not worth the effort to implement and we should just drop it. :) > > My personal opinion is that the cons of 1) and 2) make these approaches > unacceptable. The cons of 3) make it kind of not worth it - seems like a > lot of work for a partial solution. So I'm leaning towards 4) at the moment. > > I'd like to hear your opinions on this, is there a another/better approach > that I'm missing? Jirka, you mentioned we could postpone this work to the > next cycle and there are improvements that we can work on in the meantime > which would make implementation of this feature easier? > > Any and all thoughts, comments, opinions are welcome. > > [1] https://bugs.launchpad.net/tripleo/+bug/1698818 > [2] https://github.com/openstack/tripleo-heat-templates/blob/master/plan- > environment.yaml#L4-L5 > [3] https://review.openstack.org/#/c/477536/ > > -- > Regards, > Ana Krivokapic > Senior Software Engineer > OpenStack team > Red Hat Inc. > -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Plan description in the create/update plan form
Hi TripleO devs, I am working on adding a description field to the "Crate Plan" form in the TripleO UI [1]. The goal is to make it possible for the user to specify a plan description using a form field when creating a plan. As the plan description lives in the plan-environment.yaml file[2], the idea is to retrieve this value from plan-environment.yaml when the user uploads the plan, populate the form field with it, let the user change it, and then save it back to the file. I have a WIP patch up [3] which solves the issue in the case of uploading the plan as a folder. However, I am having a hard time solving the case of uploading the plan as a tarball. The issue is obviously with accessing the contents of the tarball. Here are some possible approaches that come to mind: 1) Use one of the existing third-party JS libraries that can extract a tarball in the browser. Pros: front-end only solution, no need for additional API calls, no need for back-end changes. Cons: adding a new dependency, these libraries don't seem much maintained. 2) Use swift to upload and extract the tarball. Pros: no need for back-end changes, we can just call the swift API. Cons: splitting the tarball upload from plan creation, which should really be one atomic operation. 3) Modify the plan create workflow to accept a plan description as a parameter. Pros: keeps plan creation atomic. Cons: changes to the plan create workflow interface needed. Also this way there is no way to send back the information about the description to the UI, we would have to just accept the value of the form field, and overwrite whatever was in the plan-environment.yaml file. Of course there is also a fourth option: 4) This is not worth the effort to implement and we should just drop it. :) My personal opinion is that the cons of 1) and 2) make these approaches unacceptable. The cons of 3) make it kind of not worth it - seems like a lot of work for a partial solution. So I'm leaning towards 4) at the moment. I'd like to hear your opinions on this, is there a another/better approach that I'm missing? Jirka, you mentioned we could postpone this work to the next cycle and there are improvements that we can work on in the meantime which would make implementation of this feature easier? Any and all thoughts, comments, opinions are welcome. [1] https://bugs.launchpad.net/tripleo/+bug/1698818 [2] https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml#L4-L5 [3] https://review.openstack.org/#/c/477536/ -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] How to review the deployment plan import/export feature
Hi TripleO devs, The patches ([1], [2], [3], [4]) implementing the deployment plan import/export feature have been up for review for some time. (The corresponding spec is at [5].) In this email, I'd like to explain how to review this feature. Patch [1] adds the import functionality to the create and update plan actions in tripleo-common. Make sure your copy of the tripleo-heat-templates includes the plan-environment.yaml[6] file. On your undercloud, clone a local copy of the tripleo-common repo [7] and cherry-pick the patch [1] on top of it. Then run the steps outlined at [8] in order to install the newly cloned copy of tripleo-common. This will make the updated actions available to Mistral. Then you can use the plan create and plan update commands, then make sure that the contents of the plan-environment.yaml file get correctly imported into the Mistral environment. E.g: $ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates/ new_plan $ mistral environment-get new_plan And similarly for plan update. Patch [2] adds an action and a workflow for exporting deployment plans and patch [3] adds a CLI command that triggers the workflow. You can test these two patches together, or if you want to test only [2] you can manually execute the Mistral workflow. For patch [2] the same instructions from above regarding installing a new copy of tripleo-common apply. You will also need to manually update the plan management workbook: $ mistral workbook-update tripleo-common/workbooks/plan_management.yaml Please note that patch [2] depends on patch [1] - you'll need both of them applied on your local copy of tripleo-common. As far as python-tripleoclient goes, it is enough to simply clone a fresh copy to your undercloud, apply patch [3] and run `python setup.py install`. This will make the new plan export command available to you: $ openstack overcloud plan export new_plan If all goes well, that should create a plan export tarball (new_plan.tar.gz) in the directory you ran the command from. You should check that the tarball contains all the relevant plan files, as well as the plan-environment.yaml file whose contents should be imported from the Mistral environment. Finally, patch [4] integrates the plan export functionality into the TripleO UI. You will need [1] and [2] applied on your undercloud. Then you can cherry pick [4] on top of your tripleo-ui checkout. Access the UI, navigate to Select Deployment -> Manage Deployments. Next to every plan, there should now be a new Export button which you can use to test the plan export functionality. Hope all of this makes sense - if it does not, or you have any other questions regarding this feature, please feel free to respond here or ping me on IRC. Thanks for your patience and I'll look forward to the reviews! [1] https://review.openstack.org/#/c/414169/ [2] https://review.openstack.org/#/c/422789/ [3] https://review.openstack.org/#/c/425858/ [4] https://review.openstack.org/#/c/437676/ [5] https://specs.openstack.org/openstack/tripleo-specs/specs/ocata/gui-plan-import-export.html [6] https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml [7] https://github.com/openstack/tripleo-common [8] https://docs.openstack.org/developer/tripleo-common/readme.html#action-development -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Deployment plan management efforts sync up
://specs.openstack.org/openstack/tripleo-specs/specs/ > ocata/gui-plan-import-export.html#problem-description > > [5] > > https://blueprints.launchpad.net/tripleo/+spec/enhance- > plan-creation-with-plan-environment-json > > > > > > -- Jirka > > Sounds good to me! Thanks for sharing it. > -- > Emilien Macchi > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Deep dive session about the UI - January 12
Hi everyone, For those who missed the deep dive, I am posting the recording [1] of the session. Unfortunately I had screen sharing problems which prevented me to properly cover the part about setting up the development environment during the deep dive. To make up for this, I made a short video that walks through this part [2]. Hope you find it useful! [1] https://bluejeans.com/s/D6TIf/ [2] https://www.youtube.com/watch?v=1puSvUqTKzw On Thu, Dec 15, 2016 at 11:56 AM, Ana Krivokapic <akriv...@redhat.com> wrote: > > > On Tue, Dec 13, 2016 at 5:05 PM, Emilien Macchi <emil...@redhat.com> > wrote: > >> On Mon, Dec 12, 2016 at 1:30 PM, Ana Krivokapic <akriv...@redhat.com> >> wrote: >> > Hi Everyone, >> > >> > On the 12th of January 2017, I'll lead a TripleO deep dive[1] session >> on how >> > to contribute to the TripleO UI. Hope to see many of you there! >> >> That's awesome! Thanks for this work. >> Is there some requirements that we should prepare? (e.g. having an >> undercloud ready, etc). >> > > Good question. Yes, I will start with an installed undercloud and go from > there. A virt setup with all the default options is perfectly fine. > Basically, one would need to follow the TripleO docs [1] up to and > including "Undercloud Installation". l also recommend looking at Trown's > excellent deep dive[2] on how to set up a development environment. > > >> Is it a presentation or/and Hands-On? >> > > My idea was to have a short intro segment where I would do a quick > high-level overview on the TripleO UI. Then I would dive into the specifics > about setting a up a dev environment for the UI development, and maybe even > submit a simple patch for review as part of this. I suppose the audience > could follow along, although I think it would be easier to just watch me do > it and then replicate the steps later (with the help of the video and/or > developer docs). At the end, we will have a special guest Liz Blanchard > talk about how to contribute designs to the UI. > > I started an etherpad[3] with the agenda for the deep dive (still very > much WIP). > > If anyone has any ideas about other things that they would like to see > included, please by all means let me know. The outline above is just my > idea of what could be included. We have plenty of time to add other things > to the list, if people would find them useful. One point though, I did want > to keep it more about how to contribute, as opposed to how to *use* the UI > (developer perspective vs user perspective). The latter is a subject that > would IMO deserve a whole separate session. > > >> >> Also, I propose that we record it as we did for the previous sessions, >> so anyone can watch it again. >> > > Absolutely, great idea. > > >> >> Thanks again. >> >> > >> > [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics >> > >> > -- >> > Regards, >> > Ana Krivokapic >> > Senior Software Engineer >> > OpenStack team >> > Red Hat Inc. >> > >> -- >> Emilien Macchi >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > [1] http://docs.openstack.org/developer/tripleo-docs/index.html > [2] https://www.youtube.com/watch?v=E1d_RmysnA8 > [3] https://etherpad.openstack.org/p/tripleo-deep-dive-ui > > -- > Regards, > Ana Krivokapic > Senior Software Engineer > OpenStack team > Red Hat Inc. > -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Reminder: TripleO deep dive "how to contribute to the tripleo ui" starts in 2 hours
Hope to see many of you there! https://etherpad.openstack.org/p/tripleo-deep-dive-ui -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Deep dive session about the UI - January 12
On Tue, Dec 13, 2016 at 5:05 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Mon, Dec 12, 2016 at 1:30 PM, Ana Krivokapic <akriv...@redhat.com> > wrote: > > Hi Everyone, > > > > On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on > how > > to contribute to the TripleO UI. Hope to see many of you there! > > That's awesome! Thanks for this work. > Is there some requirements that we should prepare? (e.g. having an > undercloud ready, etc). > Good question. Yes, I will start with an installed undercloud and go from there. A virt setup with all the default options is perfectly fine. Basically, one would need to follow the TripleO docs [1] up to and including "Undercloud Installation". l also recommend looking at Trown's excellent deep dive[2] on how to set up a development environment. > Is it a presentation or/and Hands-On? > My idea was to have a short intro segment where I would do a quick high-level overview on the TripleO UI. Then I would dive into the specifics about setting a up a dev environment for the UI development, and maybe even submit a simple patch for review as part of this. I suppose the audience could follow along, although I think it would be easier to just watch me do it and then replicate the steps later (with the help of the video and/or developer docs). At the end, we will have a special guest Liz Blanchard talk about how to contribute designs to the UI. I started an etherpad[3] with the agenda for the deep dive (still very much WIP). If anyone has any ideas about other things that they would like to see included, please by all means let me know. The outline above is just my idea of what could be included. We have plenty of time to add other things to the list, if people would find them useful. One point though, I did want to keep it more about how to contribute, as opposed to how to *use* the UI (developer perspective vs user perspective). The latter is a subject that would IMO deserve a whole separate session. > > Also, I propose that we record it as we did for the previous sessions, > so anyone can watch it again. > Absolutely, great idea. > > Thanks again. > > > > > [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics > > > > -- > > Regards, > > Ana Krivokapic > > Senior Software Engineer > > OpenStack team > > Red Hat Inc. > > > -- > Emilien Macchi > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > [1] http://docs.openstack.org/developer/tripleo-docs/index.html [2] https://www.youtube.com/watch?v=E1d_RmysnA8 [3] https://etherpad.openstack.org/p/tripleo-deep-dive-ui -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Deep dive session about the UI - January 12
On Mon, Dec 12, 2016 at 7:30 PM, Ana Krivokapic <akriv...@redhat.com> wrote: > Hi Everyone, > > On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on > how to contribute to the TripleO UI. Hope to see many of you there! > > > [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics > > -- > Regards, > Ana Krivokapic > Senior Software Engineer > OpenStack team > Red Hat Inc. > If you'd like a calendar invite for this deep dive, email me and I'll add you to the meeting invite. -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Deep dive session about the UI - January 12
Hi Everyone, On the 12th of January 2017, I'll lead a TripleO deep dive[1] session on how to contribute to the TripleO UI. Hope to see many of you there! [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Your draft logo & a sneak peek
On Tue, Oct 25, 2016 at 2:28 PM, Ryan Brady <rbr...@redhat.com> wrote: > > > On Tue, Oct 25, 2016 at 5:55 AM, Steven Hardy <sha...@redhat.com> wrote: > >> Hi team, >> >> I recently received a draft version of our project logo, using the mascot >> we selected together. A final version (and some cool swag) will be ready >> for us before the Project Team Gathering in February. Before they make our >> logo final, they want to be sure we're happy with our mascot. >> >> We can discuss any concerns in Barcelona and you can also provide direct >> feedback to the designers: http://tinyurl.com/OSmascot . Logo feedback is >> due Friday, Nov. 11. > > > I feel the logo draft is missing a lot of the detail and fidelity of our > current logo. > The draft logo has lines that are much too thick especially in the face > area. It's > recognizable from a shorter distance than our current logo. > > Our current logo has more of a cartoon / angry birds type feel to it - > something > with personality. To me, the draft logo is devoid of personality. I > understand why > the foundation wants to have more consistency between logos, but I'm hoping > this isn't the final design approach. > > - Ryan > Can't help but agree with Ryan here. This is definite step down from our current logo. :\ > > > > >> To get a sense of how ours stacks up to others, check out this sneak >> preview of several dozen draft logos from our community: >> https://youtu.be/JmMTCWyY8Y4. >> >> The only comment I have made is this logo does lose some of the OoO >> imagery >> we had with the previous owl version - please feel free to provide >> feedback >> of your own via the url above, thanks! >> >> Thanks! >> >> Steve >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Demo: Deploying OpenStack using TripleO UI
I'd like to share a demo video of the current state of TripleO UI: https://www.youtube.com/watch?v=01yta_1FKaQ P.S. Please note that some of the validations are failing due to physical limitations (low disk space, etc) of the virtual test setup I used to make this video. -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Announcing TripleO UI
Hi All, I am very pleased to inform you that, as of yesterday, TripleO UI is part of upstream OpenStack, under the TripleO program. If you'd like to learn more about TripleO UI, please read the spec [1]. The code repo [2], bug tracker [3], and review queue [4] are in usual places. TripleO UI devs are hanging out in #tripleo on Freenode, with the rest of the TripleO team. We are looking forward to growing a community around this exciting new project! [1] https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka/tripleo-ui.html [2] https://git.openstack.org/cgit/openstack/tripleo-ui/ [3] https://launchpad.net/tripleo-ui [4] https://review.openstack.org/#/q/project:openstack/tripleo-ui+status:open -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] core members for tripleo-ui
On Mon, Feb 29, 2016 at 4:27 PM, Dan Prince <dpri...@redhat.com> wrote: > There is a new projects for the ui called tripleo-ui. As most of the > existing TripleO core members aren't going to be reviewing UI specific > patches is seems reasonable that we might add a few review candidates > who can focus specifically on UI specific patches. Thanks, I think this makes perfect sense! > > I'd like to proposed we add Jiri Tomasek and Ana Krivokapic as core > candidates that will focus primarily on the UI. They would be added to > tripleo core but would agree to only +2 patches within the UI for now, > or at least until they are re-nominated for more general TripleO core, > etc. I'd like to suggest Florian Fuchs instead of myself, as he has far more contributions (both commits and reviews) to the UI project (such as it is so far, [1]) then I do. > > Core members if you could please vote on this so we can add these > members at the close of this week. Thanks, > > Dan > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [1] https://github.com/rdo-management/rdo-director-ui/graphs/contributors -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] TripleO UI
Hi All, In this email[1], Tzu-Mainn summarized recent developments in TripleO regarding the workflow library and the REST API. I'd like to complement that email with some information about the future TripleO UI. The new REST API aims to unify the deployment workflow and has the tripleo client[2] as the only current (CLI) consumer. I wrote a spec[3] to propose adding TripleoO UI, as another (GUI) consumer of the TripleO REST API. The idea is that TripleO UI should provide an alternative way of deploying an overcloud via TripleO, while offering the same capabilities that the CLI does. The spec contains all the information about introducing a new GUI, including the rationale behind shifting the focus from Tuskar-UI to this new GUI. The current location of the TripleO UI code repo is [4]. Note that it is still WIP and not fully capable of doing a deployment just yet. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081327.html [2] https://github.com/openstack/python-tripleoclient [3] https://review.openstack.org/#/c/239056 [4] https://github.com/rdo-management/rdo-director-ui -- Regards, Ana Krivokapic Senior Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon]
On 25/11/14 00:09, David Lyle wrote: I am pleased to nominate Thai Tran and Cindy Lu to horizon-core. Both Thai and Cindy have been contributing significant numbers of high quality reviews during Juno and Kilo cycles. They are consistently among the top non-core reviewers. They are also responsible for a significant number of patches to Horizon. Both have a strong understanding of the Horizon code base and the direction of the project. Horizon core team members please vote +1 or -1 to the nominations either in reply or by private communication. Voting will close on Friday unless I hear from everyone before that. Thanks, David +1 for both. Cindy and Thai, thanks for your hard work! -- Regards, Ana Krivokapic Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Template Blueprint
Hello Horizoners, I would like to draw your attention to the excellent Template Blueprint[1] which David created. The aim of this is to create a template which will be used for all future blueprints. This way we can try to ensure that enough information/detail is provided in blueprints, as we have had problems with blueprints lacking in details in the past. Please take a minute to review [1] and add your comments to the whiteboard. We are hoping to finalize this and starting using this template ASAP. Thanks! [1] https://blueprints.launchpad.net/horizon/+spec/template -- Regards, Ana Krivokapic Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Specs repo
On 06/11/2014 05:22 PM, Jason Rist wrote: On Wed 11 Jun 2014 06:54:53 AM MDT, Ana Krivokapic wrote: Hi Horizoners, A lot of other projects have already adopted and started using a specs repo. Do we want to have one for Horizon? I'm still not quite clear how this works, but I'm open to it if it makes things a little nicer. Basically, specs repos are meant to hold specs - design documents of sorts. They are used to describe and discuss the implementation design of a particular feature. In other words, we would use the existing Gerrit infrastructure to review blueprints. For more detailed information, please see past mailing list threads [1], [2], and e.g. nova-specs repo description [3]. Here are a few pros and cons with regard to having a specs repo. These are just the ones that were the most obvious to me; feel free to add your own. Pros: * This process makes sure implementation design for a feature happens _before_ the actual implementation. This is very important as it potentially saves developers from wasting a lot of time implementing a feature in a suboptimal way. * By making reviewers explicitly focus on the more essential aspects of a feature design, we make sure that the feature gets a better/more efficient implementation. * We will have a feature design recorded for posterity. I don't think I need to explain how useful this can be. Cons: * Shifting effort to talking about doing the work from actually doing the work. I guess we need to make sure reviews are useful and constructive and keep the process from becoming endless bike shedding. * Obviously, it will take more time and effort to get features/patches merged. Personally, I am *for* adding a specs repo for Horizon, as long as we put extra effort to minimize the cons listed above. Thoughts, comments welcome! [1] http://lists.openstack.org/pipermail/openstack-dev/2014-March/030851.html [2] http://lists.openstack.org/pipermail/openstack-dev/2014-March/030102.html [3] https://github.com/openstack/nova-specs ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Specs repo
Hi Horizoners, A lot of other projects have already adopted and started using a specs repo. Do we want to have one for Horizon? -- Regards, Ana Krivokapic Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Help debugging js files
On 06/06/2014 05:39 PM, Abishek Subramanian (absubram) wrote: Hi, I need to make some changes to the horizon.instances.js file and I was wondering what the best method would be to help debug issues in this file? Is there a debugger or something available to debug this file separately? Thanks! Abishek Hi Abishek, A couple of debugging tips with regard to Horizon frond-end development: * Use Chrome's Developer Tools or Firefox's Firebug plugin. They include very powerful tools including a debugger, a console, the ability to edit static files on the fly, etc. * Put COMPRESS_ENABLED = False into your local_settings.py to disable automatic compression of static files. This will help you see which files the errors are actually occurring in. * If you are using devstack or similar for your development environment, use Django's built-in web server, rather than a full fledged web server like Apache. It will make your life much easier - you will not have to run collectstatic after changing static files, you will have the log output in the console instead of having to dig through log files, etc. HTH -- Regards, Ana Krivokapic Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] mocking policy
On 06/04/2014 02:41 PM, Radomir Dopieralski wrote: Hello, I'd like to start a discussion about the use of mocking libraries in Horizon's tests, in particular, mox and mock. As you may know, Mox is the library that has been used so far, and we have a lot of tests written using it. It is based on a similar Java library and does very strict checking, although its error reporting may leave something more to be desired. Mock is a more pythonic library, insluded in the stdlib of recent Python versions, but also available as a separate library for older pythons. It has a much more relaxed approach, allowing you to only test the things that you actually care about and to write tests that don't have to be rewritten after each and every refactoring. Some OpenStack projects, such as Nova, seem to have adopted an approach that favors Mock in newly written tests, but allows use of Mox for older tests, or when it's more suitable for the job. In Horizon we only use Mox, and Mock is not even in requirements.txt. I would like to propose to add Mock to requirements.txt and start using it in new tests where it makes more sense than Mox -- in particular, when we are writing unit tests only testing small part of the code. Thoughts? Makes sense to me. +1 for adding Mock to the requirements (test-requirements.txt rather than requirements.txt, right?) and using it in newly written tests. -- Regards, Ana Krivokapic Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories
On 05/28/2014 02:54 PM, Radomir Dopieralski wrote: Hello, we plan to finally do the split in this cycle, and I started some preparations for that. I also started to prepare a detailed plan for the whole operation, as it seems to be a rather big endeavor. You can view and amend the plan at the etherpad at: https://etherpad.openstack.org/p/horizon-split-plan It's still a little vague, but I plan to gradually get it more detailed. All the points are up for discussion, if anybody has any good ideas or suggestions, or can help in any way, please don't hesitate to add to this document. We still don't have any dates or anything -- I suppose we will work that out soonish. Oh, and great thanks to all the people who have helped me so far with it, I wouldn't even dream about trying such a thing without you. Also thanks in advance to anybody who plans to help! This high level overview looks quite reasonable to me. Count me in on helping out with this effort. Thanks for driving this, Radomir! -- Regards, Ana Krivokapic Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar][Horizon] Javascript linter
On 04/02/2014 07:36 PM, Dougal Matthews wrote: On my phone so I can't follow this up more now, but it looks like JSHint is already used. https://review.openstack.org/#/c/41087/ That commit has since been reverted and JSHint removed from Horizon codebase: https://bugs.launchpad.net/horizon/+bug/1270764 https://review.openstack.org/#/c/68268/ Seems like there's some controversy around whether the licenses are actually incompatible or not. How do we go about clearing that up? :) -- Regards, Ana Krivokapic Associate Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core
On 03/06/2014 04:47 AM, Jason Rist wrote: On Wed 05 Mar 2014 03:36:22 PM MST, Lyle, David wrote: I'd like to nominate Radomir Dopieralski to Horizon Core. I find his reviews very insightful and more importantly have come to rely on their quality. He has contributed to several areas in Horizon and he understands the code base well. Radomir is also very active in tuskar-ui both contributing and reviewing. David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev As someone who benefits from his insightful reviews, I second the nomination. +1 -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Ana Krivokapic Associate Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon]
On 01/27/2014 09:10 AM, Jaromir Coufal wrote: Awesome, thanks a lot for setting this up, David! -- Jarda On 2014/26/01 02:10, Lyle, David wrote: With meeting logging now available in #openstack-meeting-3, the official Horizon meeting time is now Tuesdays at 1600 UTC in #openstack-meeting-3. Looking forward to seeing all Horizon folks there. David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thanks, David! This will make life easier for a lot of people. -- Regards, Ana Krivokapic Associate Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon and Tuskar-UI codebase merge
On 12/19/2013 05:32 PM, Jordan O'Mara wrote: - Original Message - So basically this is our first proposal what we send out: http://lists.openstack.org/pipermail/openstack-dev/2013-December/022196.html After Horizon meetings, several e-mails and also couple of other discussions of people who are for/against codebase merge, it looks that in the end upstream leans towards 'umbrella' solution. After all, +1 for umbrella solution from my side too. Tuskar UI will get closer to the nature of the project (based on Horizon, UI related audience). And in the same time, we will not rush things up before the project graduates. In Icehouse we can easier reach goals of both - Horizon as well as Tuskar UI - and after Icehouse release we can review back and get to the codebase merge in the end. Do you all agree? -- Jarda +1, I think this is the most sensible approach. +1 from me, this approach makes perfect sense. On 2013/18/12 22:33, Gabriel Hurley wrote: From my experience, directly adding incubated projects to the main Horizon codebase prior to graduation has been fraught with peril. That said, the closer they can be together prior to the graduation merge, the better. I like the idea of these types of projects being under the OpenStack Dashboard Program umbrella. Ideally I think it would be a jointly-managed resource in Gerrit. The Horizon Core folks would have +2 power, but the Tuskar core folks would also have +2 power. (I'm 90% certain that can be done in the Gerrit admin...) That way development speed isn't bottlenecked by Horizon Core, but there's a closer tie-in with the people who may ultimately be maintaining it. It becomes easier to keep track of, and can be more easily guided in the right directions. With a little work incubated dashboard components like this could even be made to be a non-gating part of the testing infrastructure to indicate when things change or break. Adding developers to Horizon Core just for the purpose of reviewing an incubated umbrella project is not the right way to do things at all. If my proposal of two separate groups having the +2 power in Gerrit isn't technically feasible then a new group should be created for management of umbrella projects. All the best, - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Ana Krivokapic Associate Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
