Re: [openstack-dev] [tripleo] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)
Not rooting for any approach here, just want to add a bit of factors which might play a role when deciding which way to go: A) Performance matters, we should be improving simplicity and speed of deployments rather than making it heavier. If the deployment time and resource consumption is not significantly higher, I think it doesn’t cause an issue. But if there is a significant difference between PCMK and keepalived architecture, we would need to review that. B) Containerization of PCMK plans - eventually we would like to run the whole undercloud/overcloud on minimal OS in containers to keep improving the operations on the nodes (updates/upgrades/etc). If because PCMK we would be forever stuck on BM, it would be a bit of pita. As Michele said, maybe we can re-visit this. C) Unification of undercloud/overcloud is important for us, so +1 to whichever method is being used in both. But what I know, HA folks went to keepalived since it is simpler so would be good to keep in sync (and good we have their presence here actually) :) D) Undercloud HA is a nice have which I think we want to get to one day, but it is not in as big demand as for example edge deployments, BM provisioning with pure OS, or multiple envs managed by single undercloud. So even though undercloud HA is important, it won’t bring operators as many benefits as the previously mentioned improvements. Let’s keep it in mind when we are considering the amount of work needed for it. E) One of the use-cases we want to take into account is expanind a single-node deployment (all-in-one) to 3 node HA controller. I think it is important when evaluating PCMK/keepalived HTH — Jarda > On Jul 17, 2018, at 05:04, Emilien Macchi wrote: > > Thanks everyone for the feedback, I've made a quick PoC: > https://review.openstack.org/#/q/topic:bp/undercloud-pacemaker-default > > And I'm currently doing local testing. I'll publish results when progress is > made, but I've made it so we have the choice to enable pacemaker (disabled by > default), where keepalived would remain the default for now. > > On Mon, Jul 16, 2018 at 2:07 PM Michele Baldessari wrote: > On Mon, Jul 16, 2018 at 11:48:51AM -0400, Emilien Macchi wrote: > > On Mon, Jul 16, 2018 at 11:42 AM Dan Prince wrote: > > [...] > > > > > The biggest downside IMO is the fact that our Pacemaker integration is > > > not containerized. Nor are there any plans to finish the > > > containerization of it. Pacemaker has to currently run on baremetal > > > and this makes the installation of it for small dev/test setups a lot > > > less desirable. It can launch containers just fine but the pacemaker > > > installation itself is what concerns me for the long term. > > > > > > Until we have plans for containizing it I suppose I would rather see > > > us keep keepalived as an option for these smaller setups. We can > > > certainly change our default Undercloud to use Pacemaker (if we choose > > > to do so). But having keepalived around for "lightweight" (zero or low > > > footprint) installs that work is really quite desirable. > > > > > > > That's a good point, and I agree with your proposal. > > Michele, what's the long term plan regarding containerized pacemaker? > > Well, we kind of started evaluating it (there was definitely not enough > time around pike/queens as we were busy landing the bundles code), then > due to discussions around k8s it kind of got off our radar. We can > at least resume the discussions around it and see how much effort it > would be. I'll bring it up with my team and get back to you. > > cheers, > Michele > -- > Michele Baldessari > C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > Emilien Macchi > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Building images separation and moving images into right place at right time
Oh, I see it got already split (not in this patch)! Excellent. Thanks for striking me Jay, it actually helped. Many thanks! -- Jarda On 17/04/15 16:00, Jay Dobies wrote: Have you seen Dan's first steps towards splitting the overcloud image building out of devtest_overcloud? It's not the same thing that you're talking about, but it might be a step in that direction. https://review.openstack.org/#/c/173645/ On 04/17/2015 09:50 AM, Jaromir Coufal wrote: Hi All, at the moment we are building discovery, deploy and overcloud images all at once. Then we face user to deal with uploading all images at one step. User should not be exposed to discovery/deploy images. This should happen automatically for the user during undercloud installation as post-config step, so that undercloud is usable. Once user installs undercloud (and have discovery deploy images at their place) he should be able to build / download / create overcloud images (by overcloud images I mean overcloud-full.*). This is what user should deal with. For this we will need to separate building process for discovery+deploy images and for overcloud images. Is that possible? -- Jarda __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Building images separation and moving images into right place at right time
Hi All, at the moment we are building discovery, deploy and overcloud images all at once. Then we face user to deal with uploading all images at one step. User should not be exposed to discovery/deploy images. This should happen automatically for the user during undercloud installation as post-config step, so that undercloud is usable. Once user installs undercloud (and have discovery deploy images at their place) he should be able to build / download / create overcloud images (by overcloud images I mean overcloud-full.*). This is what user should deal with. For this we will need to separate building process for discovery+deploy images and for overcloud images. Is that possible? -- Jarda __ 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] Building images separation and moving images into right place at right time
Hey Arkady, yes, this should stay as fundamental requirement. This is tandard Glance functionality, I just want to separate discover and deploy images since these will not be very likely subject of change and they belong into undercloud installation stage. That's why I want to separate overcloud building images (which is actually already there) so that user can easily replace this image with different one. -- Jarda On 17/04/15 16:18, arkady_kanev...@dell.com wrote: We need an ability for an Admin to add/remove new images at will to deploy new overcloud images at any time. Expect that it is standard glance functionality. -Original Message- From: Jaromir Coufal [mailto:jcou...@redhat.com] Sent: Friday, April 17, 2015 8:51 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [tripleo] Building images separation and moving images into right place at right time Hi All, at the moment we are building discovery, deploy and overcloud images all at once. Then we face user to deal with uploading all images at one step. User should not be exposed to discovery/deploy images. This should happen automatically for the user during undercloud installation as post-config step, so that undercloud is usable. Once user installs undercloud (and have discovery deploy images at their place) he should be able to build / download / create overcloud images (by overcloud images I mean overcloud-full.*). This is what user should deal with. For this we will need to separate building process for discovery+deploy images and for overcloud images. Is that possible? -- Jarda __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard
On 11/11/14 09:30, Jiri Tomasek wrote: On 11/10/2014 12:19 PM, Matthias Runge wrote: On Thu, Oct 30, 2014 at 01:13:48PM +0100, Matthias Runge wrote: Hi, tl;dr: how to progreed in separating horizon and openstack_dashboard About a year ago now we agreed, it makes sense to separate horizon and openstack_dashboard. At the past summit, we discussed this again. Currently, our repo contains two directories: horizon and openstack_dashboard, they both will need new names. We discussed a renaming in the past; the former consensus was: rename horizon to horizon_lib and rename openstack_dashboard to horizon. IMHO that doesn't make any sense and will confuse people a lot. I wouldn't object to rename horizon to horizon_lib, although any other name, e.g django-horizon should be fine as well. openstack_dashboard is our official name; people from outside refer to the Dashboard as Horizon, why not rename to openstack_horizon here? It is official name, but I disagree that people refer more to Dashboard than to Horizon. People mostly talk about Horizon and when they say Horizon they refer to the UI. Dashboard is not much used outside Horizon community and is a bit confusing (overloaded). Small example - when you want to add the general overview page - the actual dashboard, that should be the *dashboard* name how it should be used. Otherwise we are adding _Dashboard_ view into Project's _dashboard_ into OpenStack _Dashboard_ project. That's what I really see confusing :) My opinion and preference: * horizon_lib (framework) + horizon (UI) Thoughts? Opinions? Suggestions? From what was discussed on contributors meetup, keeping the names 'horizon' for the lib (framework) and 'openstack_dashboard' for dashboard seemed most convenient. And I happen to aggree with that. Jirka Not sure if it seemed the most convenient, I haven't seen agreement there. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] proposal: alternating weekly meeting time [doodle poll created]
On 12/11/14 02:45, Richard Jones wrote: I have set up a doodle poll to let folk enter their preferred times. It's in UTC/GMT (/London time, because doodle) so use something like http://everytimezone.com/ to figure that out :) https://doodle.com/47h3f35nad62ncnf Richard Quick Question: Why is the length of the time slot 2h? Since it should take just 1h, should I consider beginning or end of the meeting to be relevant? It is challenging to find time slot between other meetings, since I might have just 1h slot there. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] IRC Meeting Monday, July 21
Hello folks, I apologize that I missed the previous meeting due to some urgency. I wanted to ask Liz to handle the meeting for me but she was not around (vacation). I hope you at least managed to chat a bit about ongoing stuff anyway. Next week (July 28) I am not around, but I will ask somebody else to chair the meeting. Thanks for understanding -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node Management - Juno
Hi Wan, thanks for great notes. My response is inline: On 2014/15/07 23:19, Wan-yen Hsu wrote: The Register Nodes panel uses IPMI user and IPMI Password. However, not all Ironic drivers use IPMI, for instance, some Ironic drivers will use iLO or other BMC interfaces instead of IPMI. I would like to suggest changing IPMI to BMC or IPMI/BMC to acomodate more Ironic drivers. The Driver field will reflect what power management interface (e.g., IPMI + PXE, or iLO + Virtual Media) is used so it can be used to correlate the user and password fields. We are already prepared for multiple drivers. If you look at the Driver field, there is a dropdown menu from which you can choose a driver and based on the selection the additional information (like IP, user, passw) will be changed. Also, myself and a few folks are working on Ironic UEFI support and we hope to land this feature in Juno (Spec is still in review state but the feature is on the Ironic Juno Prioritized list). In order to add UEFI boot feature, a Supported Boot Modes field in the hardware info is needed. The possible values are BIOS Only, UEFI Only, and BIOS+UEFI. We will need to work with you to add this field onto hardware info. There is no problem to accommodate this change in the UI once the back-end supports it. So if there is a desire to expose the feature in the UI, when there is already working back-end solution, feel free to send a patch which adds that to the HW info - it's an easy addition and the UI is prepared for such types of expansions. Thanks! wanyen Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node Management - Juno
On 2014/15/07 20:29, Gregory Haynes wrote:
Excerpts from Jaromir Coufal's message of 2014-07-15 07:15:12 +:
On 2014/10/07 22:19, Gregory Haynes wrote:
Excerpts from Jaromir Coufal's message of 2014-07-09 07:51:56 +:
Hey folks,
after few rounds of reviews and feedbacks, I am sending wireframes,
which are ready for implementation in Juno:
http://people.redhat.com/~jcoufal/openstack/juno/2014-07-09_nodes-ui_juno.pdf
Let me know in case of any questions.
Looks awesome!
I may be way off base here (not super familiar with Tuskar) but what
about bulk importing of nodes? This is basically the only way devtest
makes use of nodes nowdays, so it might be nice to allow people to use
the same data file in both places (nodes.json blob).
-Greg
Hi Greg,
thanks a lot for the feedback. We planned to provide a bulk import of
nodes as well. First we need to provide the basic functionality. I hope
we also manage to add import function in Juno but it depends on how the
progress of implementation goes. The challenge here is that I am not
aware of any standardized way for the data structure of the imported
file (do you have any suggestions here?).
We currently accept a nodes.json blob in the following format:
[{
pm_password: foo,
mac: [78:e7:d1:24:99:a5],
pm_addr: 10.22.51.66,
pm_type: pxe_ipmitool,
memory: 98304,
disk: 1600,
arch: amd64,
cpu: 24,
pm_user: Administrator
},
...
]
So this might be a good starting point?
-Greg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thanks Greg, that's a good starting point. We will need to create a
blueprint in Horizon's launchpad for it - would you mind to register one
with above mentioned format?
-- Jarda
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node Management - Juno
On 2014/10/07 22:19, Gregory Haynes wrote: Excerpts from Jaromir Coufal's message of 2014-07-09 07:51:56 +: Hey folks, after few rounds of reviews and feedbacks, I am sending wireframes, which are ready for implementation in Juno: http://people.redhat.com/~jcoufal/openstack/juno/2014-07-09_nodes-ui_juno.pdf Let me know in case of any questions. Looks awesome! I may be way off base here (not super familiar with Tuskar) but what about bulk importing of nodes? This is basically the only way devtest makes use of nodes nowdays, so it might be nice to allow people to use the same data file in both places (nodes.json blob). -Greg Hi Greg, thanks a lot for the feedback. We planned to provide a bulk import of nodes as well. First we need to provide the basic functionality. I hope we also manage to add import function in Juno but it depends on how the progress of implementation goes. The challenge here is that I am not aware of any standardized way for the data structure of the imported file (do you have any suggestions here?). -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node Management - Juno
Hi Devananda, thank you for your great feedback and notes. Few reactions follow inline: On 2014/10/07 21:29, Devananda van der Veen wrote: Awesome! Glad to see the progress since the design summit. Some comments: - slide 1 shows some driver-specific input fields. We have work in progress to expose this list via the API which I'm hoping to land in J2 or very early in J3. https://review.openstack.org/#/c/102914/ That should help the UI keep up with new drivers and/or changes in driver-specific fields. Perfect, this will be very helpful. - I have proposed adding an additional capabilities field to node.properties, to enable users who wish to have more fine-grained control of instance placement than merely matching on cpu/ram/disk/arch. https://review.openstack.org/#/c/105802/ you may want to add this as an optional field. I am super excited that this field is getting in since we discussed this at the summit. We will build the basic set of fields first but I will keep an eye on adding this extra field as an extension later. But that's really great that we give user more fine-grained control! - on slide 1, the NIC MAC address field doesn't clearly indicate that it can accept more than one NIC's info, while this is demonstrated in the detail view on slide 6. Based on feedback, I provided text area instead of + button to adding more. But probably we should change naming on NIC MAC Adresses and we should also add a tooltip for the format of the input. - slides 5 and 6 shows data about system load, cpu, and swap utilization from provisioned nodes. AIUI, is a feature specific to Tuskar/TripleO that relies on an agent within the provisioned nodes, and is not a part of Ironic. While useful within that context, the UI for Ironic can not expect that information to be present, and in a non-TripleO environment using Ironic (eg, OnMetal, an HPC cluster, etc) it's not clear how the proposed UI for these two slides will look. So the thing is that these metrics are given by SNMP which is the source for them. If there are any other metrics or the Ceilometer agent is not available, the UI is modular, so the graphs can be extended, swapped or even removed if needed. We believe that these are basic metrics what we can easily get from Ceilometer and start with for now. We are very keen to extend those in the future. Cheers, Devananda Cheers, -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Heat] [mid-cycle] Red Hat hosted dinner on Wednesday + food restrictions
Dear all, Red Hat is happy to host a dinner during TripleO/Heat mid-cycle which should be held on Wednesday, July 23rd. I would like to invite each attendee of the meetup and ask you to fill yourselves into the relevant section at the end of the following etherpad by the end of Wednesday (don't forget on food restrictions): https://etherpad.openstack.org/p/juno-midcycle-meetup I am sorry for later announcement, but we need to handle booking by the end of the Wednesday. So distribute this question as much as you can so that we have the answers as soon as possible. Thank you and cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node Management - Juno
Hey folks, after few rounds of reviews and feedbacks, I am sending wireframes, which are ready for implementation in Juno: http://people.redhat.com/~jcoufal/openstack/juno/2014-07-09_nodes-ui_juno.pdf Let me know in case of any questions. Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] Meeting Reminder - July 7, 17:00 UTC
Hi UXers, this is a reminder that our next regular IRC meeting is happening on Monday, July 7th at 17:00 UTC at #openstack-meeting-3. Agenda: https://wiki.openstack.org/wiki/Meetings/UX Feel free to add topics which you are interested in. See you all there -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup - Attendance Confirmation
Thanks a lot for your help. Just a side note - we need to fill in the number of requested rooms, so that we don't get charged for extra cost - we have a group discount price. So for everybody, please, go forward and book your room here: http://tinyurl.com/redhat-marriott -- Jarda On 2014/24/06 17:49, Jordan OMara wrote: On 24/06/14 10:55 -0400, Jordan OMara wrote: On 20/06/14 16:26 -0400, Charles Crouch wrote: Any more takers for the tripleo mid-cycle meetup in Raleigh? If so, please sign up on the etherpad below. The hotel group room rate will be finalized on Monday Jul 23rd (US time), after that time you will be on your own for finding accommodation. Thanks Charles Just an update that I've got us a block of rooms reserved at the nearest, cheapest hotel (the Marriott in downtown Raleigh, about 200 yards from the Red Hat office) - I'll have details on how to actually book at this rate in just a few minutes. Please use the following link to reserve at the marriott (it's copied on the etherpad) http://tinyurl.com/redhat-marriott We have a 24-room block reserved at that rate from SUN-FRI ___ 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
Re: [openstack-dev] [Horizon] Quick Survey: Horizon Mid-Cycle Meetup
On 2014/19/06 09:58, 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 I am not sure TBH, that's why I added also the Topic section to figure out if there is something what needs to be discussed. Though I don't see much interest yet. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Quick Survey: Horizon Mid-Cycle Meetup
Hello folks, there were few discussions about meeting during the cycle and discuss ongoing issues, progress and next steps of bigger topics. As long as it is pretty late announcement, I don't think (and I guess we agreed) that it doesn't worth to organize a special event just for Horizon. So it was suggested that we join the mid-cycle Sprint in Paris (July 2-4). 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 Please fill in information as soon as possible, preferable by the end of this week (Friday), so that people can start with travel arrangements if we have reasonable amount of participants. Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup - Attendance Confirmation
Hi all, I would like to remind you to sign up for mid-cycle meetup which is happening July 21-25 in Raleigh: * https://etherpad.openstack.org/p/juno-midcycle-meetup We need number of participants as soon as possible so that we can ask for group discount at the hotel. Also if we don't get rooms in one of these two hotels (see etherpad) the experience of accommodation is rapidly decreasing. Therefor I would like to ask everybody, if you can confirm your attendance as soon as possible. If you have any related question just let me know, I will be happy to help. Looking forward to seeing you all in Raleigh -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] Meeting Reminder - Jun 18th, 14:30 UTC
Hi UXers, this is a reminder that our next regular IRC meeting is happening tomorrow (Wednesday) June 18th at 14:30 UTC at #openstack-meeting-3. Agenda: https://wiki.openstack.org/wiki/Meetings/UX Feel free to add topics which you are interested in. See you all tomorrow -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Name proposals
Hm, strange. I have contributed in Icehouse but didn't get the e-mail fro voting. I wanted to vote from the link which you provided but it didn't work for me - you already voted from given key. Can anybody help? Thanks -- Jarda On 2014/10/06 21:18, Radomir Dopieralski wrote: Hello everyone. We have collected a fine number of name proposals for the library part of Horizon, and now it is time to vote for them. I have set up a poll on CIVS, and if you contributed to Horizon within the last year, you should receive an e-mail with the link that lets you vote. If you didn't receive an e-mail, but you would like to vote anyways, you can do so by visiting the following URL: http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_ea99af9511f3f255akey=e4c064fca36f8d26 Please rank the names from the best to the worst. The names that were obvious conflicts or intended for the dashboard part were removed from the list. Once we get the results, we will consult with the OpenStack Foundation and select the first valid name with the highest ranking. The poll will end at the next Horizon team meeting, Tuesday, June 17, at 16:00 UTC. Thank you, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] TripleO Mid-Cycle Meetup - Final Dates
Hello folks, I am happy to announce, that based on previous etherpad gathering, mails and discussions, on the weekly meeting we confirmed final dates for TripleO mid-cycle meetup: July 21-25 (Monday-Friday) Red Hat office, Raleigh, North Carolina I will be working on another arrangements like suggested hotels, room booking etc. and in the meantime, please fill yourselves in the etherpad, if you have confirmed that you are going to join us: https://etherpad.openstack.org/p/juno-midcycle-meetup Everybody is welcome. Heat team is considering if they join their meetup or not, because they have few conflicts - hopefully we will know their decision soon. One way or the other they definitely want to have at least some representatives on our meeting and vice-versa so that we keep good communication channel between our teams. I would like also to invite folks from Nova, Ironic or Ceilometer teams to join the TripleO meetup if they can. Looking forward to seeing you all in Raleigh -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
On 2014/10/06 10:25, Clint Byrum wrote: Excerpts from Jaromir Coufal's message of 2014-06-08 16:44:58 -0700: Hi, it looks that there is no more activity on the survey for mid-cycle dates so I went forward to evaluate it. I created a table view into the etherpad [0] and results are following: * option1 (Jul 28 - Aug 1): 27 attendees - collides with Nova/Ironic * option2 (Jul 21-25) : 27 attendees * option3 (Jul 25-29) : 17 attendees - collides with Nova/Ironic * option4 (Aug 11-15) : 13 attendees I think that we can remove options 3 and 4 from the consideration, because there is lot of people who can't make it. So we have option1 and option2 left. Since Robert and Devananda (PTLs on the projects) can't make option1, which also conflicts with Nova/Ironic meetup, I think it is pretty straightforward. Based on the survey the winning date for the mid-cycle meetup is option2: July 21th - 25th. Does anybody have very strong reason why we shouldn't fix the date for option2 and proceed forward with the organization for the meetup? July 21-25 is also the shortest notice. I will not be able to attend as plans have already been made for the summer and I've already been travelling quite a bit recently, after all we were all just at the summit a few weeks ago. I question the reasoning that being close to FF is a bad thing, and suggest adding much later dates. But I understand since the chosen dates are so close, there is a need to make a decision immediately. Alternatively, I suggest that we split Heat out of this, and aim at later dates in August. Hi Clint, here is the challenge: I tried to get feedback as soon as possible. We are not able to satisfy everybody's restrictions. During summer everybody is planning for vacation and it is impossible to find a time which works for all. I was reading your restrictions in the etherpad and it is excluding options from the end of July until second half of August. So I didn't expect that option 2 would conflict with your plans. In August folks usually have scheduled private time off so it will be much worse than July to find some date. Just look at restrictions and on August's dates proposal, how the number of attendees decreased. Furthermore, why I am against being close to FF is that TripleO itself is not restricted by FF but the project is dependent on various other projects for which FF applies to. So being in the middle of the feature proposal milestone makes sense for us to plan forward. What benefit from the meetup do we get if we can't discuss, propose and get needed features in? Options 1, 3 and 4 are out of the question. I am sure that if we do it in the end of August we will for sure lose various attendees (probably more than in July) and furthermore we will not be able to propose new features and neither get them in. As you mentioned, we need to make a decision immediately. The etherpad was on for a while and I had various discussions in the meantime. It seems that July 21-25 makes the biggest sense and allows majority people to attend. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
Hi, it looks that there is no more activity on the survey for mid-cycle dates so I went forward to evaluate it. I created a table view into the etherpad [0] and results are following: * option1 (Jul 28 - Aug 1): 27 attendees - collides with Nova/Ironic * option2 (Jul 21-25) : 27 attendees * option3 (Jul 25-29) : 17 attendees - collides with Nova/Ironic * option4 (Aug 11-15) : 13 attendees I think that we can remove options 3 and 4 from the consideration, because there is lot of people who can't make it. So we have option1 and option2 left. Since Robert and Devananda (PTLs on the projects) can't make option1, which also conflicts with Nova/Ironic meetup, I think it is pretty straightforward. Based on the survey the winning date for the mid-cycle meetup is option2: July 21th - 25th. Does anybody have very strong reason why we shouldn't fix the date for option2 and proceed forward with the organization for the meetup? Thanks for all the interest -- Jarda [0] https://etherpad.openstack.org/p/juno-midcycle-meetup On 2014/28/05 13:05, Jaromir Coufal wrote: Hi to all, after previous TripleO Ironic mid-cycle meetup, which I believe was beneficial for all, I would like to suggest that we meet again in the middle of Juno cycle to discuss current progress, blockers, next steps and of course get some beer all together :) Last time, TripleO and Ironic merged their meetings together and I think it was great idea. This time I would like to invite also Heat team if they want to join. Our cooperation is increasing and I think it would be great, if we can discuss all issues together. Red Hat offered to host this event, so I am very happy to invite you all and I would like to ask, who would come if there was a mid-cycle meetup in following dates and place: * July 28 - Aug 1 * Red Hat office, Raleigh, North Carolina If you are intending to join, please, fill yourselves into this etherpad: https://etherpad.openstack.org/p/juno-midcycle-meetup Cheers -- 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
Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
Yeah, Robert is right. I think, everybody who is approved by his employer (or is expected to be approved) should enter his constraints. So realistically enter dates when you would be able to attend. Personal view: after Aug 11th, we will have about 3 weeks to feature freeze which is very late I would say. I would better target the meetup to July. -- Jarda On 2014/02/06 22:52, Robert Collins wrote: I think you should add the constraints you have. Realistically though, not every will be there, and thats fine. There are some folk we'll need there (e.g. I suspect I'm one of those, but maybe not!) My constraints are: - need to be in Sydney for the 1st-5th, remembering there is an international date line between NC and Sydney. - need to be home for most of a week between the mid cycle meetup and PyCon AU (family). So I can do anytime from Aug 11th on, or anytime ending before or on July the 25th - and I'm going to put that in the etherpad now :0 -Rob On 3 June 2014 04:51, Ben Nemec openst...@nemebean.com wrote: On 05/30/2014 06:58 AM, Jaromir Coufal wrote: On 2014/30/05 10:00, Thomas Spatzier wrote: Excerpt from Zane Bitter's message on 29/05/2014 20:57:10: From: Zane Bitter zbit...@redhat.com To: openstack-dev@lists.openstack.org Date: 29/05/2014 20:59 Subject: Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup snip BTW one timing option I haven't seen mentioned is to follow Pycon-AU's model of running e.g. Friday-Tuesday (July 25-29). I know nobody wants to be stuck in Raleigh, NC on a weekend (I've lived there, I understand ;), but for folks who have a long ways to travel it's one weekend lost instead of two. +1 - excellent idea! It looks that there is an interest in these dates, so I added 3rd option to the etherpad [0]. For one more time, I would like to ask potential attendees to put yourselves to dates which would work for you. -- Jarda [0] https://etherpad.openstack.org/p/juno-midcycle-meetup Just to clarify, I should add my name to the list if I _can_ make it to a given proposal, even if I don't know for sure that I will be going? I don't know what the travel situation is yet so I can't commit to being there on any dates, but I can certainly say which dates would work for me if I can make it. -Ben ___ 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
Re: [openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda
On 2014/30/05 22:37, James Polley wrote: On 30 May 2014, at 8:13 pm, Jaromir Coufal jcou...@redhat.com wrote: Hi All, I would like to propose to add Tuskar as a permanent topic to the agenda for our weekly IRC meetings. It is an official TripleO's project, there happening quite a lot around it and we are targeting for Juno to have something solid. So I think that it is important for us to regularly keep track on what is going on there. Sounds good to me. What do you think we would talk about under this topic? I'm thinking that a brief summary of changes since last week, and any blockers tuskar is seeing from the broader project would be a good start? Yeah, I am thinking about something similar. Communicate direction, discuss changes, progress, blockers. Similar as for all other topics. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda
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
Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?
On 2014/30/05 02:08, James Slagle wrote: On Thu, May 29, 2014 at 12:25 PM, Anita Kuno ante...@anteaya.info 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? +1 I'd say yes. I don't think the additional traffic would be a large distraction at all to normal TripleO business. I can however see how it might be nice to have #tuskar to talk tuskar api and tuskar ui stuff in the same channel. Do folks usually do that? Or is tuskar-ui conversation already happening in #openstack-horizon? It is a mix, but lot of UI related discussions go to Horizon and it *should* be part of Horizon, so I don't think there is strong need to keep #tuskar channel separately. So I am for moving #tuskar discussions to #tripleo. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] Reminder - UX initial meeting starts on Monday
Hi UXers, I just wanted to remind all, that on Monday June 2, 2014 at 1700 UTC we are starting with OpenStack UX meetings (#openstack-meeting-3). More details: https://wiki.openstack.org/wiki/Meetings/UX I'd like to ask all participants if you could write your time zones here: https://etherpad.openstack.org/p/ux-meetings Thanks to all -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] [Heat] [Nova] Mid-cycle collaborative meetup
Hi Devananda, it is interesting. I think that we can invite Nova as well and join our efforts at one place. It will be like a tiny (more focused) summit but it sounds that all projects can benefit a lot from it. What do you think? [added Nova tag to the subject] Nova folks, what do you think? Would you like to join our mid-cycle meeting and have TripleO Ironic Heat Nova teams together at one place? More details about place, dates and attendees are here: https://etherpad.openstack.org/p/juno-midcycle-meetup -- Jarda On 2014/29/05 19:26, Devananda van der Veen wrote: Hi Jaromir, I agree that the midcycle meetup with TripleO and Ironic was very beneficial last cycle, but this cycle, Ironic is co-locating its sprint with Nova. Our focus needs to be working with them to merge the nova.virt.ironic driver. Details will be forthcoming as we work out the exact details with Nova. That said, I'll try to make the TripleO sprint as well -- assuming the dates don't overlap. Cheers, Devananda On Wed, May 28, 2014 at 4:05 AM, Jaromir Coufal jcou...@redhat.com mailto:jcou...@redhat.com wrote: Hi to all, after previous TripleO Ironic mid-cycle meetup, which I believe was beneficial for all, I would like to suggest that we meet again in the middle of Juno cycle to discuss current progress, blockers, next steps and of course get some beer all together :) Last time, TripleO and Ironic merged their meetings together and I think it was great idea. This time I would like to invite also Heat team if they want to join. Our cooperation is increasing and I think it would be great, if we can discuss all issues together. Red Hat offered to host this event, so I am very happy to invite you all and I would like to ask, who would come if there was a mid-cycle meetup in following dates and place: * July 28 - Aug 1 * Red Hat office, Raleigh, North Carolina If you are intending to join, please, fill yourselves into this etherpad: https://etherpad.openstack.__org/p/juno-midcycle-meetup https://etherpad.openstack.org/p/juno-midcycle-meetup Cheers -- Jarda _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
On 2014/29/05 20:57, Zane Bitter wrote: On 29/05/14 13:33, Mike Spreitzer wrote: Devananda van der Veen devananda@gmail.com wrote on 05/29/2014 01:26:12 PM: Hi Jaromir, I agree that the midcycle meetup with TripleO and Ironic was very beneficial last cycle, but this cycle, Ironic is co-locating its sprint with Nova. Our focus needs to be working with them to merge the nova.virt.ironic driver. Details will be forthcoming as we work out the exact details with Nova. That said, I'll try to make the TripleO sprint as well -- assuming the dates don't overlap. Cheers, Devananda On Wed, May 28, 2014 at 4:05 AM, Jaromir Coufal jcou...@redhat.com wrote: Hi to all, after previous TripleO Ironic mid-cycle meetup, which I believe was beneficial for all, I would like to suggest that we meet again in the middle of Juno cycle to discuss current progress, blockers, next steps and of course get some beer all together :) Last time, TripleO and Ironic merged their meetings together and I think it was great idea. This time I would like to invite also Heat team if they want to join. Our cooperation is increasing and I think it would be great, if we can discuss all issues together. Red Hat offered to host this event, so I am very happy to invite you all and I would like to ask, who would come if there was a mid-cycle meetup in following dates and place: * July 28 - Aug 1 * Red Hat office, Raleigh, North Carolina If you are intending to join, please, fill yourselves into this etherpad: https://etherpad.openstack.org/p/juno-midcycle-meetup Cheers -- Jarda Given the organizers, I assume this will be strongly focused on TripleO and Ironic. Would this be a good venue for all the mid-cycle discussion that will be relevant to Heat? Is anyone planning a distinct Heat-focused mid-cycle meetup? We haven't had one in the past, but the project is getting bigger so, given our need to sync with the TripleO folks anyway, this may be a good opportunity to try. Certainly it's unlikely that any Heat developers attending will spend the _whole_ week working with the TripleO team, so there should be time to do something like what you're suggesting. I think we just need to see who is willing able to attend, and work out an agenda on that basis. Last time we managed to work also on the items not related to other projects. So I think it is just matter of putting together an agenda. Each team can work on their own, schedule cross-project topics and huge benefit is that we can discuss interrelated issues directly with members of other teams easily and anytime because we can get up and approach anybody face-to-face. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
On 2014/30/05 10:00, Thomas Spatzier wrote: Excerpt from Zane Bitter's message on 29/05/2014 20:57:10: From: Zane Bitter zbit...@redhat.com To: openstack-dev@lists.openstack.org Date: 29/05/2014 20:59 Subject: Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup snip BTW one timing option I haven't seen mentioned is to follow Pycon-AU's model of running e.g. Friday-Tuesday (July 25-29). I know nobody wants to be stuck in Raleigh, NC on a weekend (I've lived there, I understand ;), but for folks who have a long ways to travel it's one weekend lost instead of two. +1 - excellent idea! It looks that there is an interest in these dates, so I added 3rd option to the etherpad [0]. For one more time, I would like to ask potential attendees to put yourselves to dates which would work for you. -- Jarda [0] https://etherpad.openstack.org/p/juno-midcycle-meetup ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs
Hey Mainn, mostly it is driven by following requirements: https://etherpad.openstack.org/p/ironic-ui plus what you already know from Tuskar point of view - which is simply monitoring, monitoring, monitoring :) Hope it helps -- Jarda On 2014/29/05 05:51, Tzu-Mainn Chen wrote: Hi Jarda, These look pretty good! However, I'm having trouble evaluating from a purely functional point of view, as I'm not entirely sure what the requirements driving these design. Would it be possible to list those out. . . ? Thanks, Tzu-Mainn Chen - Original Message - Hi All, There is a lot of tags in the subject of this e-mail but believe me that all listed projects (and even more) are relevant for the designs which I am sending out. Nodes management section in Horizon is being expected for a while and finally I am sharing the results of designing around it. http://people.redhat.com/~jcoufal/openstack/horizon/nodes/2014-05-28_nodes-ui.pdf These views are based on modular approach and combination of multiple services together; for example: * Ironic - HW details and management * Ceilometer - Monitoring graphs * TripleO/Tuskar - Deployment Roles etc. Whenever some service is missing, that particular functionality should be disabled and not displayed to a user. I am sharing this without any bigger description so that I can get feedback whether people can get oriented in the UI without hints. Of course you cannot get each and every detail without exploring, having tooltips, etc. But the goal for each view is to manage to express at least the main purpose without explanation. If it does not, it needs to be fixed. Next week I will organize a recorded broadcast where I will walk you through the designs, explain high-level vision, details and I will try to answer questions if you have any. So feel free to comment anything or ask whatever comes to your mind here in this thread, so that I can cover your concerns. Any feedback is very welcome - positive so that I know what you think that works, as well as negative so that we can improve the result before implementation. Thank you all -- 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
Hi James, that's a good point. I just restructured the etherpad so that there are 3 sections: one is for July 28 - Aug 1, second is for July 21-25 and third one is for those who want to attend but can't make it within suggested dates. So I would like to encourage everybody who is willing to attend to put himself into the slots when he can (so if both weeks work for you, please enter yourself into both lists). Thanks -- Jarda On 2014/29/05 08:07, James Polley wrote: Thanks for putting this together Jaromir! August 1 may be a problem for those of us from Australia - it's the day of the OpenStack miniconf at Pycon-AU. I don't know if any of us intended to go to that, but if we did we'd need to leave no later than the 4:40pm flight on July 30 in order to make it back in time - and that would have us arriving in Brisbane at 7am on the day of the miniconf. If we stayed till midday Friday and caught the 4:40pm flight out, we'd arrive in BNE at 7am on the 3rd - just in time for the last day of talks and the two days of sprints. As I said, I'm not sure how many other people from this part of the world had intended to go to Pycon-AU and the openstack miniconf, so I'm not sure how much of a problem this is. On Wed, May 28, 2014 at 9:05 PM, Jaromir Coufal jcou...@redhat.com mailto:jcou...@redhat.com wrote: Hi to all, after previous TripleO Ironic mid-cycle meetup, which I believe was beneficial for all, I would like to suggest that we meet again in the middle of Juno cycle to discuss current progress, blockers, next steps and of course get some beer all together :) Last time, TripleO and Ironic merged their meetings together and I think it was great idea. This time I would like to invite also Heat team if they want to join. Our cooperation is increasing and I think it would be great, if we can discuss all issues together. Red Hat offered to host this event, so I am very happy to invite you all and I would like to ask, who would come if there was a mid-cycle meetup in following dates and place: * July 28 - Aug 1 * Red Hat office, Raleigh, North Carolina If you are intending to join, please, fill yourselves into this etherpad: https://etherpad.openstack.__org/p/juno-midcycle-meetup https://etherpad.openstack.org/p/juno-midcycle-meetup Cheers -- Jarda _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
Hi to all, after previous TripleO Ironic mid-cycle meetup, which I believe was beneficial for all, I would like to suggest that we meet again in the middle of Juno cycle to discuss current progress, blockers, next steps and of course get some beer all together :) Last time, TripleO and Ironic merged their meetings together and I think it was great idea. This time I would like to invite also Heat team if they want to join. Our cooperation is increasing and I think it would be great, if we can discuss all issues together. Red Hat offered to host this event, so I am very happy to invite you all and I would like to ask, who would come if there was a mid-cycle meetup in following dates and place: * July 28 - Aug 1 * Red Hat office, Raleigh, North Carolina If you are intending to join, please, fill yourselves into this etherpad: https://etherpad.openstack.org/p/juno-midcycle-meetup Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs
Hi All, There is a lot of tags in the subject of this e-mail but believe me that all listed projects (and even more) are relevant for the designs which I am sending out. Nodes management section in Horizon is being expected for a while and finally I am sharing the results of designing around it. http://people.redhat.com/~jcoufal/openstack/horizon/nodes/2014-05-28_nodes-ui.pdf These views are based on modular approach and combination of multiple services together; for example: * Ironic - HW details and management * Ceilometer - Monitoring graphs * TripleO/Tuskar - Deployment Roles etc. Whenever some service is missing, that particular functionality should be disabled and not displayed to a user. I am sharing this without any bigger description so that I can get feedback whether people can get oriented in the UI without hints. Of course you cannot get each and every detail without exploring, having tooltips, etc. But the goal for each view is to manage to express at least the main purpose without explanation. If it does not, it needs to be fixed. Next week I will organize a recorded broadcast where I will walk you through the designs, explain high-level vision, details and I will try to answer questions if you have any. So feel free to comment anything or ask whatever comes to your mind here in this thread, so that I can cover your concerns. Any feedback is very welcome - positive so that I know what you think that works, as well as negative so that we can improve the result before implementation. Thank you all -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] Initial kick-off IRC meeting
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
Re: [openstack-dev] [UX] Initial kick-off IRC meeting
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
Re: [openstack-dev] [Ironic] [UX] Is there horizon implementation for ironic
Hi, I am currently improving UI designs for node management via Ironic based on the feedback from OpenStack Summit. In the Infrastructure dashboard, there are basic views for nodes, but at this moment it is handled via nova-baremetal (when we implemented these views, Ironic was not ready yet). New views for node management are intended to work with Ironic and after the mockups are reviewed, we are going to work on their implementation. I will be posting the designs by the end of this week hopefully. Any feedback or help with implementation will be very welcome then. Best -- Jarda On 2014/19/05 09:58, 严超 wrote: Hi, All : Ironic is a project for us to control bare metal better. Is there any horizon implementation for ironic to use ironic api and function easyly? */Best Regards！/* */Chao Yan -- /**/My twitter：Andy Yan @yanchao727 https://twitter.com/yanchao727/* */My Weibo：http://weibo.com/herewearenow -- /* ___ 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
Re: [openstack-dev] [UX] OpenStack UX - IRC meeting
Hello everybody interested in UX, for one more time, I am reminding that there is ongoing survey for times which will work for you regarding regular OpenStack UX IRC meetings: http://doodle.com/3m29dkn3ef2em5in Cheers -- Jarda On 2014/06/05 17:27, Jaromir Coufal wrote: Hello UX folks, I am following the initial discussion about tools proposal. Everybody blessed UX IRC meetings so I am starting an initiative to organize them. At this moment, I would like to ask everybody interested in the meeting to participate in a survey and mark times which will work for you so that we can find the best match for the meeting: http://doodle.com/3m29dkn3ef2em5in Thank you all for participation and if you have any questions, I am happy to help. -- 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
[openstack-dev] [UX] OpenStack UX - IRC meeting
Hello UX folks, I am following the initial discussion about tools proposal. Everybody blessed UX IRC meetings so I am starting an initiative to organize them. At this moment, I would like to ask everybody interested in the meeting to participate in a survey and mark times which will work for you so that we can find the best match for the meeting: http://doodle.com/3m29dkn3ef2em5in Thank you all for participation and if you have any questions, I am happy to help. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [UX] Proposed tools and workflows for OpenStack User Experience contributors
Thanks all for great feedback, I will try to do a short summary: Wiki Wiki page is obvious and easy consensus for us. It should contain all important information about UX, such as how to contribute, where to go to start, various links, etc. Mailing list - [UX] --- Everybody agrees that discussions should happen on the mailing list with [UX] tag in the subject. There is no consensus if the discussion should be just general or detailed as well. (We should continue this discussion in separate thread) Discussion forum - (terminate) -- It's agreed that AskBot doesn't work very well - it is a bit chaotic and also big problem is disconnection from the rest of OpenStack teams. It was suggested to search for another solution (also no consensus on which one). IRC meetings Very welcome from everybody. Launchpad (StoryBoard in the future) Also welcome, until StoryBoard is ready for us, we should keep track of BPs and bugs in Launchpad and document how to work with it. Wishlist (currently Launchpad) -- Seems like nice idea. We should figure out what would be the best way to provide this list, but it might be as simple as registering new bug or blueprint in UX's Launchpad (at least from the beginning). Storage place (GitHUb) -- We should do research on what tool would be useful for us. GitHub (or OpenStack's git repository) can work with combination of gerrit. It looks that we should at least give it a try. Templates library - Yes, could be stored at the same place as other materials, just marked and linked properly. ??? (user community for feedback gathering) --- Needs more research - still trying to figure out where and how the best connect with the user community. So mostly we agreed on all suggested tools which makes me very happy. I will start setting up the obvious ones and for the rest (+controversial), I am going to start separate threads, where we can discuss in more details and follow up at Summit. Thank you all for your feedback, you will hear from me soon -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [UX] User Experience cross-project sessions at Summit
Hey Liz, thank you very much for taking a time, proposing and covering this agenda. It looks very good and I am happy that we got two slots for UX discussions. I agree with Thierry that we should definitely cover as much UX areas as possible. Therefore I would like to encourage people from all fields of expertize who have interest in User Experience (no matter if it is user research, GUI, CLI, API, ...) to join our session so that we can group people together and search for the best way of how to cooperate and contribute to OpenStack. Few inline comments follow: On 2014/23/04 20:12, Liz Blanchard wrote: Hi All, I’m happy to say that there will be two slots (back to back) on the cross-project track for us to have discussions around User Experience during Summit \o/. I’d like to propose we talk about the following, but am completely open to suggestions from whoever is interested in attending these sessions. Let me know if anyone has any thoughts here! 1) Introduction of everyone in the session. -What role do you have today? -How does UX affect you? -How will you (if you plan to) contribute to OpenStack UX? -How active do you plan to be for the Juno development cycle? +1. I hope that more people from various areas will join the session and we can find groups of people who are working in similar areas and connect them together. 2) Discussion of where are are currently in UX. -What components have we worked on so far? -What does our current process look like? -What tools do we use? -What has worked well? -What could be improved? It would be great to figure out what are the groups of people and hear from each group what they did so far and what are their goals. 3) Discussion on where we want to go for Juno. -How should we improve our process and tooling during the Juno release? How do we track this and who will take certain action items? -What tools should we remove/add? (Jarda sent a nice e-mail proposal around yesterday that would be great to discuss further) -What are our goals for UX during the Juno release? (More research/requirements work? More designing? More user testing?...) Which components will we focus on? (Horizon? Tuskar? Heat? Ceilometer?….) Which features will we focus on? I think the most important goal for this session would be to connect people together and establish a bridge between us, so that we can communicate, meet and discuss all together in an easy way. Thread about tools and processes helped (thanks all for your feedback), I am going to expand on it and I would like to share a summary and follow up on open questions at this session. Regarding goals for Juno cycle - I would envision us to discuss more global goals for the whole UX community (which from my perspective means mostly gluing people together and finding a way of how to cooperate). For finer goals (like what to focus on in GUI, in CLI, ...), I think it should be discussed in smaller groups (which don't have to overlap, so that people can be present in multiple groups). Therefore I think this kind of planning might happen: A) Later on during the Summit (maybe second block?), discussing each area separately. B) After the Summit through channels which we establish. 4) UX as a program. -What does it mean to be a program? -Would UX make sense to be a program? If so, how should we work together to make this something we could propose as a team? +1 it would be nice to follow up on this topic. I hope we will build on top of previous discussions about UX becoming a program: * Wiki: https://wiki.openstack.org/wiki/UX/ProgramProposal * Email thread: http://lists.openstack.org/pipermail/openstack-dev/2013-November/019884.html Thanks, I am looking forward to meeting all of you -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] Proposed tools and workflows for OpenStack User Experience contributors
Dear OpenStack UX community and everybody else who is interested in OpenStack's user experience, When there is more contributors appearing in time, I would like us to establish a formal process of how the UX work should be organized. Therefore I am suggesting a few tools below for us to be more effective, transparent and to provide a single way to all contributors so that it is easy for everybody to start, to contribute and to get oriented in our world. Wiki = introduction to OpenStack User Experience = how to contribute guide = documentation of processes = redirecting people to the right places of their interest (IRC, Launchpad, etc) Mailing list - [UX] --- = discussions about various issues = openstack-dev mailing list, using [UX] tag in the subject + brings more attention to the UX issues + not separated from other OpenStack's projects + threading is already there (e-mail clients) + no need for setting up and maintaining additional server to run our own forum - requires to store attachments somewhere else (some other server) ... similar case with current askbot anyway - requires contributors to register to the openstack-dev mailing list ... each contributor should do that anyway Discussion forum - (terminate) -- + more interactive + easier for newcomers - separating UX outside the OpenStack world - we haven't found any other suitable tool for discussions yet (current AskBot is not doing very well) - in order not to fragment discussions into multiple places, I am suggesting termination of current AskBot and keeping discussions in mailing list IRC meetings = regular meetings, each 2-3 weeks, short meeting, mostly dealing with organizational stuff and bringing attention on hot topics + brings people together + helps with UX organization - requires people to make a time for it ... should be short though, so it shouldn't be big deal Launchpad (StoryBoard in the future) = organization of UX work, overview of who is working on what, prioritizing stories, etc. + helps organizing work + helps documenting UX efforts - requires maintenance ... the same way as for any other program Wishlist (currently Launchpad) -- = list of areas where other projects need a help from UX and UX person can take tasks + easy way of other teams how to interact with UX team when they look for a help + easy way for UXers to see areas where is a need for help Storage place (GitHUb) -- = server where we can store temporary materials as well as final solutions - github for permanent solutions (guidelines, final designs, ...)? Templates library - = library containing pre-prepared templates for UI designs (ready to use already designed elements, etc) + helps designers to produce designs easier by applying copypaste methodology in the templates ... Should contain wireframes as well as visual designed elements ... Should be available for multiple applications (InDesign, Inkscape, etc) ??? (user community for feedback gathering) --- = tool for grouping people who are willing to give feedback on current UX in OpenStack I am looking forward to hearing back from you with your feedback and opinions. If it seems to you like a good overview of how things can work, I will be happy to break it down into smaller pieces and make it happen so that we can start using all these tools as soon as possible. Thank you all -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][sahara] Merging Sahara-UI Dashboard code into horizon
Hey Chad, thank you very much for starting this thread. Let me start with short introduction to my thoughts about OpenStack Dashboard's direction and our latest work there. I am working towards a higher goal of having the OpenStack UI a stable, simple and coherent story for our end users. Which means that it follows their workflows and enables them to be effective and happy when using it. Historically the UI resembled a little bit admin views, showing models and their objects in tables. We are improving here. One part which is leading towards the high level goal is information architecture reorganization which we started at last summit, but it got blocked a little bit by RBAC implementation. Though it is still an ongoing process. My concern is that the UI is starting to become a place where other projects just add another dashboard or panel in order to get incubated. I don't want this to happen, so I would like to put more thoughts where the Sahara functionality belongs and how it works together in relationship with other functionality and projects which are already in. To understand Sahara more, I read wiki page, various documentations and saw screencasts. After going through all of the materials there appeared various questions, which might be caused with lack of my knowledge about Sahara. So in the following paragraphs, I would like to put some questions (some might be rhetorical) and suggest few solutions to improve the placement of Sahara features. 1) What is the relationship of Sahara to Heat? Isn't Heat supposed to deal with provisioning of such a group of VMs? Is Hadoop cluster somehow different from other stacks that it can't be handled by Heat? The reason why I am asking is, that it looks to me, that what you are doing with Sahara in the first phase is actually designing your cluster with specific node types, you save it as a template (which only specifies which node types and how meany instances should run) and then you provision this cluster. For me it looks more or less the same as how Heat is supposed to work: * Node Type == Heat Resource (Type) * Cluster Template == Heat Template * Cluster == Heat Stack Therefore I am a little bit hesitative to adding another views, which are having similar purpose. If they are different, can you please be a bit more specific about the differencies? 2) Lot of views (menu items) are reflecting mostly data model, but I don't think that there needs to be that many of them. Current views: * Clusters, Cluster Templates, Node Group Templates, Job Executions, Jobs, Job Binaries, Data Sources, Image Registry, Plugins Suggested structure A: * Orchestration - Clusters / Stacks (one view including Clusters, Cluster Templates) - Node Group Templates * Data Processing - Overview - Jobs (one view including Job Executions, Jobs, Job Binaries) - Data Sources ? Image Registry - should be part of already existing Images catalog (why to separate them?) ? Plugins - Do they have to be managed via UI? Can't be all enabled by default and configured somewhere else in the preferences? I think it will confuse users to manage plugins from the top level main navigation - it's not something what with the user visit regularly. The question here is, if Clusters, Cluster Templates and Node Group Templates aren't supposed be reflected somehow with Heat, since Heat is the tool for Orchestration and it already deals with that. Because if we do this, then Clusters look like duplication for Heat Stacks (already described above in paragraph #1). if the answer is no, then suggested structure B: * Data Processing (specific only for Hadoop): - Clusters - Node Group Templates - Jobs - Data Sources I lean towards the A suggestion so far so I understand Sahara. Few comments inline: On 2014/17/04 21:06, Chad Roberts wrote: Per blueprint https://blueprints.launchpad.net/horizon/+spec/merge-sahara-dashboard we are merging the Sahara Dashboard UI code into the Horizon code base. Over the last week, I have been working on making this merge happen and along the way some interesting questions have come up. Hopefully, together we can make the best possible decisions. Sahara is the Data Processing platform for Openstack. During incubation and prior to that, a horizon dashboard plugin was developed to work with the data processing api. Our original implementation was a separate dashboard that we would activate by adding to HORIZON_CONFIG and INSTALLED_APPS. The layout gave us a root of Sahara on the same level as Admin and Project. Under Sahara, we have 9 panels that make-up the entirety of the functionality for the Sahara dashboard. Over the past week there seems to be at least 2 questions that have come up. I'd like to get input from anyone interested. 1) Where should the functionality live within the Horizon UI? So far, 2 options have been presented. a) In a separate dashboard
Re: [openstack-dev] [TripleO][design] review based conceptual design process
On 2014/15/04 23:15, James Slagle wrote: On Tue, Apr 15, 2014 at 2:44 PM, Robert Collins robe...@robertcollins.net wrote: I've been watching the nova process, and I think its working out well - it certainly addresses: - making design work visible - being able to tell who has had input - and providing clear feedback to the designers I'd like to do the same thing for TripleO this cycle.. +1 for the approach. I'm thinking we can just add docs to incubator, since thats already a repository separate to our production code - what do folk think? +1 from me. Think I'd prefer a separate repo for tripleo-specs though. +1 for separate repository. One thing that I don't think I saw called out specifically in the nova-specs thread was about keeping these spec and design documents updated. I'm guessing the plan around that would just be to submit updates in gerrit as patches, and then we can all review the updates as well. I think it's important that we try to keep them up to date and accurate as possible. +1 for gerrit reviews. I am having similar proposal for UX designs. I'd like to keep them stored and up to date with latest changes - also through the gerrit patches. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo
On 2014/10/04 19:40, Nachi Ueno wrote: Hi Jarda Congratulations This release and the demo is super awesome!! Do you have any instruction to install this one? Thank you, Nachi! look at Ladislav's response he posted our guideline for installation. If you have any problems, let us know on #tuskar or #tripleo channel and we will help you to go through it. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo
On 2014/10/04 19:40, Nachi Ueno wrote: Hi Jarda Congratulations This release and the demo is super awesome!! Do you have any instruction to install this one? Thank you, Nachi! look at Ladislav's response he posted our guideline for installation. If you have any problems, let us know on #tuskar channel and we will help you to go through. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] [TripleO] [Tuskar] Demo of current state of Tuskar-UI
On 2014/10/04 22:55, Robert Collins wrote: On 10 April 2014 01:54, Jaromir Coufal jcou...@redhat.com wrote: Hello OpenStackers, I would like to share with you non-narrated demo of current version of 'Tuskar-UI' project, which is very close to Icehouse release (one or two more patches to come in). Very very cool! It's thrilling to see all the effort folk have been putting into this - I just showed it to one of our product folk here and they really love it ;) -Rob Thank you, Rob! I think this was very important step and since now everything will go smoothly :) I also wanted to thank you for valuable feedbacks and contributions. Getting through this milestone brings us a lot of work for Juno which is good news. Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo
On 2014/11/04 10:27, Thomas Goirand wrote: On 04/10/2014 04:32 PM, Jaromir Coufal wrote: Dear Stackers, I am happy to announce that yesterday Tuskar UI (TripleO UI) has tagged branch 0.1.0 for Icehouse release [0]. I put together a narrated demo of all included features [1]. You can find one manual part in the whole workflow - cloud initialization. There is ongoing work on automatic os-cloud-config, but for the release we had to include manual way. Automation should be added soon though. I want to thank all contributors for hard work to make this happen. It has been pleasure to cooperate with all of you guys and I am looking forward to bringing new features [2] in. -- Jarda Are all needed components latest tags enough? In other words, if I update all of TripleO in Debian, will I have a useable system? Cheers, Thomas Hi Thomas, I would say yes. The question is what you mean by usable system? You want to try the Tuskar UI? If yes, here is devtest which will help you to get the dev setup: https://wiki.openstack.org/wiki/Tuskar/Devtest and here is the part for Tuskar UI: https://github.com/openstack/tuskar-ui/blob/master/docs/install.rst If you want more general info about Tuskar, here is wiki page: https://wiki.openstack.org/wiki/Tuskar. We are also very happy to help on #tuskar or #tripleo freenode channels if you experience some troubles. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo
Hi Jarda, Thanks a lot for your reply. Unfortunately, these instructions aren't very useful if you want to do an installation based on packages. Something like: git clone https://git.openstack.org/openstack/tripleo-incubator $TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine is of course a no go. Stuff with pip install or easy_install, or git clone, aren't what Debian users should read. So, I guess the documentation for when using packages have to be written from scratch. I'm not sure where to start... :( Do you have time to help with this? Now, yes, I'd be very happy to chat about this on IRC. However, I have to get my hands on a powerful enough server. I've read a post in this list by Robert that I would need at least 16 GB of RAM. I hope to get a spare hardware for such tests soon. Thomas Right, sorry, I somehow missed Debian note in your e-mail... Robert was right, it is a bit demanding project :) So once you get your server, just jump into the #tuskar channel and somebody will definitely try to help you with setting it up. If you could take notes and help us updating the wiki page with installation instruction for Debian, it would be awesome. Thanks -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo
Dear Stackers, I am happy to announce that yesterday Tuskar UI (TripleO UI) has tagged branch 0.1.0 for Icehouse release [0]. I put together a narrated demo of all included features [1]. You can find one manual part in the whole workflow - cloud initialization. There is ongoing work on automatic os-cloud-config, but for the release we had to include manual way. Automation should be added soon though. I want to thank all contributors for hard work to make this happen. It has been pleasure to cooperate with all of you guys and I am looking forward to bringing new features [2] in. -- Jarda [0] 0.1.0 Icehouse Release of the UI: https://github.com/openstack/tuskar-ui/releases/tag/0.1.0 [1] Narrated demo of TripleO UI 0.1.0: https://www.youtube.com/watch?v=-6whFIqCqLU [2] Juno Planning for Tuskar: https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] [TripleO] [Tuskar] Demo of current state of Tuskar-UI
Hello OpenStackers, I would like to share with you non-narrated demo of current version of 'Tuskar-UI' project, which is very close to Icehouse release (one or two more patches to come in). Tuskar-UI is a user interface based on TripleO approach which allows user to register nodes (currently nova-baremetal - ironic), define hardware profiles (nova-flavors), design OpenStack deployment (Tuskar) and based on HW profiles to deploy OpenStack on your baremetal nodes (Heat). Demo: https://www.youtube.com/watch?v=3_u2PmeF36k Juno roadmap - Tuskar planning for J cycle: https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning If you have any questions, we are happy to help you. Just ask here on the mailing list, or you can find many folks on following channels: #tuskar, #tripleo, #openstack-horizon (UI related channel) Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] [TripleO] [Tuskar] Demo of current state of Tuskar-UI
On 2014/09/04 16:31, mar...@redhat.com wrote: Jarda thanks this was great to watch - seems a lot of things have been fixed/tweaked in last couple weeks. Is everything running from current master branches? marios Yes, everything what you see is currently in the master branch (last changes were merged yesterday night). So it is showing actually the latest state. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar][TripleO] Tuskar Planning for Juno
On 2014/07/04 15:36, Tzu-Mainn Chen wrote: Hi all, One of the topics of discussion during the TripleO midcycle meetup a few weeks ago was the direction we'd like to take Tuskar during Juno. Based on the ideas presented there, we've created a tentative list of items we'd like to address: https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning Please feel free to take a look and question, comment, or criticize! Thanks, Tzu-Mainn Chen Thanks Mainn for the write up, it looks like a good summary for J cycle. I didn't find any disagreements from my side. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] reviewer update march [additional cores]
On 2014/08/04 01:50, Robert Collins wrote: tl;dr: 3 more core members to propose: bnemec greghaynes jdon jdon - jdob +1 for all the folks. -- Jarda On 4 April 2014 08:55, Chris Jones c...@tenshu.net wrote: Hi +1 for your proposed -core changes. Re your question about whether we should retroactively apply the 3-a-day rule to the 3 month review stats, my suggestion would be a qualified no. I think we've established an agile approach to the member list of -core, so if there are a one or two people who we would have added to -core before the goalposts moved, I'd say look at their review quality. If they're showing the right stuff, let's get them in and helping. If they don't feel our new goalposts are achievable with their workload, they'll fall out again naturally before long. So I've actioned the prior vote. I said: Bnemec, jdob, greg etc - good stuff, I value your reviews already, but... So... looking at a few things - long period of reviews: 60 days: |greghaynes | 1210 22 99 0 081.8% | 14 ( 11.6%) | | bnemec | 1160 38 78 0 067.2% | 10 ( 8.6%) | | jdob | 870 15 72 0 082.8% | 4 ( 4.6%) | 90 days: | bnemec | 1450 40 105 0 072.4% | 17 ( 11.7%) | |greghaynes | 1420 23 119 0 083.8% | 22 ( 15.5%) | | jdob | 1060 17 89 0 084.0% | 7 ( 6.6%) | Ben's reviews are thorough, he reviews across all contributors, he shows good depth of knowledge and awareness across tripleo, and is sensitive to the pragmatic balance between 'right' and 'good enough'. I'm delighted to support him for core now. Greg is very active, reviewing across all contributors with pretty good knowledge and awareness. I'd like to see a little more contextual awareness though - theres a few (but not many) reviews where looking at how the big picture of things fitting together more would have been beneficial. *however*, I think that's a room-to-improve issue vs not-good-enough-for-core - to me it makes sense to propose him for core too. Jay's reviews are also very good and consistent, somewhere between Greg and Ben in terms of bigger-context awareness - so another definite +1 from me. -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] reviewer update march
On 2014/03/04 13:02, Robert Collins wrote: Getting back in the swing of things... Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted with -core responsibilities. In this months review: - Dan Prince for -core - Jordan O'Mara for removal from -core - Jiri Tomasek for removal from -core - Jamomir Coufal for removal from -core +1 Not involved much in TripleO code. Existing -core members are eligible to vote - please indicate your opinion on each of the three changes above in reply to this email. +1 to all changes [snip] -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Horizon] Searching for a new name for Tuskar UI
On 2014/27/03 19:04, Jiří Stránský wrote: On 27.3.2014 18:21, Dougal Matthews wrote: [snip] As a side, but related note, I think we should rename the Tuskar client to whatever name the Tuskar UI gets called. The client will eventually have feature parity with the UI and thus will have the same naming issues if it is to remain the tuskarclient Dougal It might be good to do a similar thing as Keystone does. We could keep python-tuskarclient focused only on Python bindings for Tuskar (but keep whatever CLI we already implemented there, for backwards compatibility), and implement CLI as a plugin to OpenStackClient. E.g. when you want to access Keystone v3 API features (e.g. domains resource), then python-keystoneclient provides only Python bindings, it no longer provides CLI. I think this is a nice approach because it allows the python-*client to stay thin for including within Python apps, and there's a common pluggable CLI for all projects (one top level command for the user). At the same time it would solve our naming problems (tuskarclient would stay, because it would be focused on Tuskar only) and we could reuse the already implemented other OpenStackClient plugins for anything on undercloud. We previously raised that OpenStackClient has more plugins (subcommands) that we need on undercloud and that could confuse users, but i'd say it might not be as troublesome to justify avoiding the OpenStackClient way. (Even if we decide that this is a big problem after all and OSC plugin is not enough, we should still probably aim for separating TripleO CLI and Tuskarclient in the future.) Jirka +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Horizon] Searching for a new name for Tuskar UI
Hi OpenStackers, User interface which is managing the OpenStack Infrastructure is currently named Tuskar-UI because of historical reasons. Tuskar itself is a small service, which is giving logic into generating and managing Heat templates and helps user to model and manage his deployment. The user interface, which is the subject of this call, is based on TripleO approach and resembles OpenStack Dashboard (Horizon) with the way of how it consumes other services. The UI is consuming not just Tuskar API, but also Ironic (nova-baremetal), Nova (flavors), Ceilometer, etc in order to design, deploy, manage and monitor your OpenStack deployments. Because of this I find the name Tuskar-UI improper (it's more closer to say TripleO-UI) and I would like the community to help to find better name for it. After brainstorming, we can start voting on the final project's name. https://etherpad.openstack.org/p/openstack-management-ui-names Thanks -- Jarda (jcoufal) ___ 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 2014/05/03 23:36, 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. +1 -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes
Hi Tomas, thanks for the questions, I am replying inline. On 2014/05/02 11:19, Tomas Sedovic wrote: On 05/02/14 03:58, Jaromir Coufal wrote: Hi to everybody, based on the feedback from last week [0] I incorporated changes in the wireframes so that we keep them up to date with latest decisions: http://people.redhat.com/~jcoufal/openstack/tripleo/2014-02-05_tripleo-ui-icehouse.pdf Changes: * Smaller layout change in Nodes Registration (no rush for update) * Unifying views for 'deploying' and 'deployed' states of the page for deployment detail * Improved workflow for associating node profiles with roles - showing final state of MVP - first iteration contains only last row (no node definition link) Hey Jarda, Looking good. I've got two questions: 1. Are we doing node tags (page 4) for the first iteration? Where are they going to live? Yes, it's very easy to do, already part of Ironic. 2. There are multiple node profiles per role on pages 11, 12, 17. Is that just an oversight or do you intend on keeping those in? I though the consensus was to do 1 node profile per deployment role. I tried to avoid the confusion by the comment: '- showing final state of MVP - first iteration contains only last row (no node definition link)' Maybe I should be more clear. By last row I meant that in the first iteration, the form will contain only one row with dropdown to select only one flavor per role. I intend to keep multiple roles for Icehouse scope. We will see if we can get there in time, I am hoping for 'yes'. But I am absolutely aligned with the consensus that we are starting only one node profile per role. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes
Hi Steve! I would say that we finally got to sort of stabilized state of wireframes [0]. I am sure there will appear slight changes (as it is always like this), but there shouldn't be bigger change of direction. We are looking forward to see some high-fidelity mockups if you are willing to help in this area. Thanks for your interest -- Jarda [0] http://people.redhat.com/~jcoufal/openstack/tripleo/2014-02-05_tripleo-ui-icehouse.pdf On 2014/17/01 01:16, Steve Doll wrote: Looking good, let me know if I can be of help to make some high-fidelity mockups. On Thu, Jan 16, 2014 at 6:30 AM, Jay Dobies jason.dob...@redhat.com mailto:jason.dob...@redhat.com wrote: This is a really good evolution. I'm glad the wireframes are getting closer to what we're doing for Icehouse. A few notes... On page 6, what does the Provisioning Status chart reflect? The math doesn't add up if that's supposed to reflect the free v. deployed. That might just be a sample data thing, but the term Provisioning Status makes it sound like this could be tracking some sort of ongoing provisioning operation. What's the distinction between the config shown on the first deployment page and the ones under more options? Is the idea that the ones on the overview page must be specified before the first deployment but the rest can be left to the defaults? The Roles (Resource Category) subtab disappeared but the edit role dialog is still there. How do you get to it? Super happy to see the progress stuff represented. I think it's a good first start towards handling the long running changes. I like the addition of the Undeploy button, but since it's largely a dev utility it feels a bit weird being so prominent. Perhaps consider moving it under scale deployment; it's a variation of scaling, just scaling back to nothing :) You locked the controller count to 1 (good call for Icehouse) but still have incrementers on the scale page. That should also be disabled and hardcoded to 1, right? On 01/16/2014 08:41 AM, Hugh O. Brock wrote: On Thu, Jan 16, 2014 at 01:50:00AM +0100, Jaromir Coufal wrote: Hi folks, thanks everybody for feedback. Based on that I updated wireframes and tried to provide a minimum scope for Icehouse timeframe. http://people.redhat.com/~__jcoufal/openstack/tripleo/__2014-01-16_tripleo-ui-__icehouse.pdf http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-16_tripleo-ui-icehouse.pdf Hopefully we are able to deliver described set of features. But if you find something what is missing which is critical for the first release (or that we are implementing a feature which should not have such high priority), please speak up now. The wireframes are very close to implementation. In time, there will appear more views and we will see if we can get them in as well. Thanks all for participation -- Jarda These look great Jarda, I feel like things are coming together here. --Hugh _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Steve Doll* Art Director, Mirantis Inc. sd...@mirantis.com mailto:sd...@mirantis.com Mobile: +1-408-893-0525 Skype: sdoll-mirantis ___ 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
Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements
On 2014/05/02 15:27, Tzu-Mainn Chen wrote: Hi, In parallel to Jarda's updated wireframes, and based on various discussions over the past weeks, here are the updated Tuskar requirements for Icehouse: https://wiki.openstack.org/wiki/TripleO/TuskarIcehouseRequirements Any feedback is appreciated. Thanks! Tzu-Mainn Chen +1 looks good to me! -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] RFC - Suggestion for switching from Less to Sass (Bootstrap 3 Sass support)
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
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/03/02 12:23, Tomas Sedovic wrote: My apologies for firing this off and then hiding under the FOSDEM rock. In light of the points raised by Devananda and Robert, I no longer think fiddling with the scheduler is the way to go. Note this was never intended to break/confuse all TripleO users -- I considered it a cleaner equivalent to entering incorrect HW specs (i.e. instead of doing that you would switch to this other filter in nova.conf). Regardless, I stand corrected on the distinction between heterogeneous hardware all the way and having a flavour per service definition. That was a very good point to raise. I'm fine with both approaches. So yeah, let's work towards having a single Node Profile (flavor) associated with each Deployment Role (pages 12 13 of the latest mockups[1]), optionally starting with requiring all the Node Profiles to be equal. I think here is a small misinterpretation. All Node Profiles don't have to be equal. We just support one Node Profile association per role. Once that's working fine, we can look into the harder case of having multiple Node Profiles within a Deployment Role. Is everyone comfortable with that? Tomas [1]: http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-27_tripleo-ui-icehouse.pdf +1 for this approach. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/03/02 00:21, Robert Collins wrote: [snip] However me and Robert, we look to have different opinions on what 'homogeneous' means in our context. I think we should clarify that. So I think my point is more this: - either this iteration is entirely limited to homogeneous hardware, in which case, document it, not workarounds or custom schedulers etc. - or it isn't limited, in which case we should consider the options: - flavor per service definition It was confirmed that this solution doesn't have to be big chunk of work worth splitting into different iterations, so +1 for this solution in the first iteration. - custom scheduler - register nodes wrongly -Rob Thanks all for clarification. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes
Hi to everybody, based on the feedback from last week [0] I incorporated changes in the wireframes so that we keep them up to date with latest decisions: http://people.redhat.com/~jcoufal/openstack/tripleo/2014-02-05_tripleo-ui-icehouse.pdf Changes: * Smaller layout change in Nodes Registration (no rush for update) * Unifying views for 'deploying' and 'deployed' states of the page for deployment detail * Improved workflow for associating node profiles with roles - showing final state of MVP - first iteration contains only last row (no node definition link) -- Jarda [0] https://www.youtube.com/watch?v=y2fv6vebFhM On 2014/16/01 01:50, Jaromir Coufal wrote: Hi folks, thanks everybody for feedback. Based on that I updated wireframes and tried to provide a minimum scope for Icehouse timeframe. http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-16_tripleo-ui-icehouse.pdf Hopefully we are able to deliver described set of features. But if you find something what is missing which is critical for the first release (or that we are implementing a feature which should not have such high priority), please speak up now. The wireframes are very close to implementation. In time, there will appear more views and we will see if we can get them in as well. Thanks all for participation -- 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
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/30/01 12:59, Ladislav Smola wrote: On 01/30/2014 12:39 PM, Jiří Stránský wrote: On 01/30/2014 11:26 AM, Tomas Sedovic wrote: [snip] I am for implementing support for Heterogeneous hardware properly, lifeless should post what he recommends soon, so I would rather discuss that. We should be able to do simple version in I. Nobody ever said that any implementation of heterogeneous should be wrong or poor. This is misinterpretation. Lowest common denominator doesn't solve storage vs. compute node. If we really have similar hardware, we don't care about, we can just fill the nova-baremetal/ironic specs the same as the flavor. I disagree with this point. This approach of yours will bring super huge confusion for the end user. Asking user to enter same values for different hardware specs will be huge mistake. User is required to enter the reality, it's up to us, how we will help him to make his life easier. Why would we want to see in UI that the hardware is different, when we can't really determine what goes where. Because it is reality. And as you say assume homogenous hardware and treat it as such. So showing in UI that the hardware is different doesn't make any sense then. This might be just wrong wording, but 'assume homogenous hardware and treat it as such' is meant in a way - we deploy roles on nodes randomly, because we assume similar HW - as a *first* step. Right after that, we add functionality for user to define flavors. So the solution for similar hardware is already there. I don't see this as an incremental step, but as ugly hack that is not placed anywhere on the roadmap. Regards, Ladislav -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/30/01 19:29, Tzu-Mainn Chen wrote: Wouldn't lying about the hardware specs when registering nodes be problematic for upgrades? Users would have to re-register their nodes. +1 for problematic area here One reason why a custom filter feels attractive is that it provides us with a clear upgrade path: Icehouse * nodes are registered with correct attributes * create a custom scheduler filter that allows any node to match * users are informed that for this release, Tuskar will not differentiate between heterogeneous hardware J-Release * implement the proper use of flavors within Tuskar, allowing Tuskar to work with heterogeneous hardware I don't think that this is J-release issue. We are very likely to handle this in I-release. * work with nova regarding scheduler filters (if needed) * remove the custom scheduler filter Mainn -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/30/01 23:33, Devananda van der Veen wrote: I was responding based on Treat similar hardware configuration as equal. When there is a very minor difference in hardware (eg, 1TB vs 1.1TB disks), enrolling them with the same spec (1TB disk) is sufficient to solve all these issues and mask the need for multiple flavors, and the hardware wouldn't need to be re-enrolled. I disagree here, of course user can register HW as they wish, it's their responsibility. But asking them to register nodes as equal (even if they are close) is going to be mess and huge confusion for users. You would actually ask user to enter non-real data - so that he can use our deployment tool somehow. From my point of view, this is not right approach and I would better see him entering correct information and us working with it. My suggestion does not address the desire to support significant variation in hardware specs, such as 8GB RAM vs 64GB RAM, in which case, there is no situation in which I think those differences should be glossed over, even as a short-term hack in Icehouse. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. I think this will lead to a lot of confusion, and difficulty with inventory / resource management. I don't think it's suitable even as a first-approximation. Put another way, I dislike the prospect of removing currently-available functionality (an exact-match scheduler and support for multiple flavors) to enable ease-of-use in a UI. I would say this is not for ease-of-use in the UI. It's for bringing user functionality to deploy in the UI. Then, in next iteration, to support them by picking HW they care about. Not that I dislike UIs or anything... it just feels like two steps backwards. If the UI is limited to homogeneous hardware, accept that; don't take away heterogeneous hardware support from the rest of the stack. It's not about taking away support for heterogeneous HW from the whole stack. I see the proposal more like adding another filter (possibility) for nova-scheduler. Anyway, it sounds like Robert has a solution in mind, so this is all moot :) Cheers, Devananda Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/30/01 21:28, Robert Collins wrote: On 30 January 2014 23:26, Tomas Sedovic tsedo...@redhat.com wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). I don't agree that (1) implies a single nova flavour. In the context of the discussion it implied avoiding doing our own scheduling, and due to the many moving parts we never got beyond that. I think that homogeneous hardware implies single flavor. That's from the definition 'homogeneous'. Question is, how we treat it then. My expectation is that (argh naming of things) a service definition[1] will specify a nova flavour, right from the get go. That gives you homogeneous hardware for any service [control/network/block-storage/object-storage]. If a service definition specifies a nova flavor, then (based on the fact that we have 4 hard-coded roles) we are supporting heterogeneous HW (because we would allow user to specify 4 flavors). What we agreed on in the beginning is homogeneous HW - which links to the fact that we have only one flavor. We should really start with something *simple* and increment on that: 1) one flavor, no association to any role. This is what I see under homogeneous HW - MVP0. (As an addition for the sake of usability we wanted to add 'no care' filter - so that it picks node without need for specifying requirements). 2) association with role - one flavor per role - homogeneous hardware. 3) support multiple node profiles per role. Why to complicate things from the very beginning (1)? Jaromir's wireframes include the ability to define multiple such definitions, so two definitions for compute, for instance (e.g. one might be KVM, one Xen, or one w/GPUs and the other without, with a different host aggregate configured). As long as each definition has a nova flavour, users with multiple hardware configurations can just create multiple definitions, done. That is not entirely policy driven, so for longer term you want to be able to say 'flavour X *or* Y can be used for this', but as a early iteration it seems very straight forward to me. Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal I think this is a problematic idea, because of the points raised elsewhere in the thread. But more importantly, it's totally unnecessary. If one wants to handle minor variations in hardware (e.g. 1TB vs 1.1TB disks) just register them as being identical, with the lowest common denominator - Nova will then treat them as equal. -Rob -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/31/01 22:03, Tzu-Mainn Chen wrote: So after reading the replies on this thread, it seems like I (and others advocating a custom scheduler) may have overthought things a bit. The reason this route was suggested was because of conflicting goals for Icehouse: a) homogeneous nodes (to simplify requirements) b) support diverse hardware sets (to allow as many users as possible to try Tuskar) Option b) requires either a custom scheduler or forcing nodes to have the same attributes, and the answer to that question is where much of the debate lies. I think these two goals are pretty accurate. However, taking a step back, maybe the real answer is: a) homogeneous nodes b) document. . . - **unsupported** means of demoing Tuskar (set node attributes to match flavors, hack the scheduler, etc) Why are people calling it 'hack'? It's an additional filter to nova-scheduler...? - our goals of supporting heterogeneous nodes for the J-release. I wouldn't talk about J-release. I would talk about next iteration or next step. Nobody said that we are not able to make it in I-release. Does this seem reasonable to everyone? Mainn Well +1 for a) and it's documentation. However me and Robert, we look to have different opinions on what 'homogeneous' means in our context. I think we should clarify that. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Tuskar] Deployment Configuration in the UI
Hi folks, based on overcloud.yaml file (thanks Rob for pointing me there), I put together attributes for deployment configuration which should appear in the UI. Can I ask for a help, to review the list if it is accurate and if not to correct it? https://etherpad.openstack.org/p/tuskar-ui-config Thanks a lot for helping -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon]
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
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
Based on this thread which didn't seem to get clear outcome, I have one last suggestion: * Deployment Role It looks that it might satisfy participants of this discussion. When I internally talked to people it got the best reactions from already suggested terms. Depending on your reactions for this suggestion, if we don't get to agreement of majority by the end of the week, I would call for voting starting next week. Thanks -- Jarda On 2014/21/01 15:19, Jaromir Coufal wrote: Hi folks, when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). Definition: Role is a representation of a group of nodes, with specific behavior. Each role contains (or will contain): * one or more Node Profiles (which specify HW which is going in) * association with image (which will be provisioned on new coming nodes) * specific service settings So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term * Resource Class * - older term Are there any other suggestions (ideally something short and accurate)? Or do you prefer any of already suggested terms? Any ideas are welcome - we are not very good in finding the best match for this particular term. Thanks -- 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
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On 2014/22/01 19:46, Tzu-Mainn Chen wrote: - Original Message - Oh dear user... :) I'll step a little bit back. We need to agree if we want to name concepts one way in the background and other way in the UI for user (did we already agree on this point?). We all know pros and cons. And I will still fight for users to get global infrastructure terminology (e.g. he is going to define Node Profiles instead of Flavors). Because I received Jarda, sidepoint - could you explain again what the attributes of a node profile are? Beyond the Flavor, does it also define an image. . . ? Mainn So... For now, the attributes are: - Name - Description - Image (Image was discussed on the level of a Role, not Node Profile) - Node Profile(s) Future: + Service Specific Configuration (?) + Policies (spin up new instance, if...) -- Jarda ___ 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
On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda ___ 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
On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda ___ 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
On 2014/22/01 10:00, Jaromir Coufal wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted 'Resource' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It's short, well describing... I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. -- Jarda ___ 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
Oh dear user... :) I'll step a little bit back. We need to agree if we want to name concepts one way in the background and other way in the UI for user (did we already agree on this point?). We all know pros and cons. And I will still fight for users to get global infrastructure terminology (e.g. he is going to define Node Profiles instead of Flavors). Because I received a lot of negative feedback on mixing overcloud terms into undercloud, confusion about overcloud/undercloud term itself, etc. If it would be easier for developers to name the concepts in the background differently then it's fine - we just need to talk about 2 terms per concept then. And I would be a bit afraid of schizophrenia... On 2014/22/01 15:10, Tzu-Mainn Chen wrote: That's a fair question; I'd argue that it *should* be resources. When we update an overcloud deployment, it'll create additional resources. Honestly it would get super confusing for me, if somebody tells me - you have 5 compute resources. (And I am talking from user's world, not from developers one). But resource itself can be anything. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes
Hey everybody, I am sending updated wireframes. http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-22_tripleo-ui-icehouse.pdf Updates: * p15-18 for down-scaling deployment Any questions are welcome, I am happy to answer them. -- Jarda On 2014/16/01 01:50, Jaromir Coufal wrote: Hi folks, thanks everybody for feedback. Based on that I updated wireframes and tried to provide a minimum scope for Icehouse timeframe. http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-16_tripleo-ui-icehouse.pdf Hopefully we are able to deliver described set of features. But if you find something what is missing which is critical for the first release (or that we are implementing a feature which should not have such high priority), please speak up now. The wireframes are very close to implementation. In time, there will appear more views and we will see if we can get them in as well. Thanks all for participation -- 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
[openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
Hi folks, when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). Definition: Role is a representation of a group of nodes, with specific behavior. Each role contains (or will contain): * one or more Node Profiles (which specify HW which is going in) * association with image (which will be provisioned on new coming nodes) * specific service settings So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term * Resource Class * - older term Are there any other suggestions (ideally something short and accurate)? Or do you prefer any of already suggested terms? Any ideas are welcome - we are not very good in finding the best match for this particular term. Thanks -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes
Hello everybody, based on feedback which I received last week, I am sending updated wireframes. They are still not completely final, more use-cases and smaller updates will occur, but I believe that we are going forward pretty well. http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-20_tripleo-ui-icehouse.pdf What has changed? * 'Architecture' dropdown was added for all node descriptions * New views for Deployed and Free nodes * Removed Configuration part from Deployment Overview page (will be happening under Configuration tab (under construction)) * Added progressing page of overcloud being deployed + Deployment Log * Added Overcloud Horizon UI link to Deployment Overview page * Added view for down-scaling (need more work) * Added Implementation guide for developers New versions of wireframes, supporting other use-cases will occur in time, but I hope that without huge changes. Cheers -- Jarda On 2014/16/01 01:50, Jaromir Coufal wrote: Hi folks, thanks everybody for feedback. Based on that I updated wireframes and tried to provide a minimum scope for Icehouse timeframe. http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-16_tripleo-ui-icehouse.pdf Hopefully we are able to deliver described set of features. But if you find something what is missing which is critical for the first release (or that we are implementing a feature which should not have such high priority), please speak up now. The wireframes are very close to implementation. In time, there will appear more views and we will see if we can get them in as well. Thanks all for participation -- 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
Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes
Sure Steve, that would be awesome! The only blocker for now is that there are still happening some changes based on feedback of what is doable / what is not. So right when we get more confident on stable(-ish) version (or at least I'll try to sort out widgets which should stay how they are), it will be very valuable input. I'll definitely let you know! -- Jarda On 2014/17/01 01:16, Steve Doll wrote: Looking good, let me know if I can be of help to make some high-fidelity mockups. On Thu, Jan 16, 2014 at 6:30 AM, Jay Dobies jason.dob...@redhat.com mailto:jason.dob...@redhat.com wrote: This is a really good evolution. I'm glad the wireframes are getting closer to what we're doing for Icehouse. A few notes... On page 6, what does the Provisioning Status chart reflect? The math doesn't add up if that's supposed to reflect the free v. deployed. That might just be a sample data thing, but the term Provisioning Status makes it sound like this could be tracking some sort of ongoing provisioning operation. What's the distinction between the config shown on the first deployment page and the ones under more options? Is the idea that the ones on the overview page must be specified before the first deployment but the rest can be left to the defaults? The Roles (Resource Category) subtab disappeared but the edit role dialog is still there. How do you get to it? Super happy to see the progress stuff represented. I think it's a good first start towards handling the long running changes. I like the addition of the Undeploy button, but since it's largely a dev utility it feels a bit weird being so prominent. Perhaps consider moving it under scale deployment; it's a variation of scaling, just scaling back to nothing :) You locked the controller count to 1 (good call for Icehouse) but still have incrementers on the scale page. That should also be disabled and hardcoded to 1, right? On 01/16/2014 08:41 AM, Hugh O. Brock wrote: On Thu, Jan 16, 2014 at 01:50:00AM +0100, Jaromir Coufal wrote: Hi folks, thanks everybody for feedback. Based on that I updated wireframes and tried to provide a minimum scope for Icehouse timeframe. http://people.redhat.com/~__jcoufal/openstack/tripleo/__2014-01-16_tripleo-ui-__icehouse.pdf http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-16_tripleo-ui-icehouse.pdf Hopefully we are able to deliver described set of features. But if you find something what is missing which is critical for the first release (or that we are implementing a feature which should not have such high priority), please speak up now. The wireframes are very close to implementation. In time, there will appear more views and we will see if we can get them in as well. Thanks all for participation -- Jarda These look great Jarda, I feel like things are coming together here. --Hugh _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Steve Doll* Art Director, Mirantis Inc. sd...@mirantis.com mailto:sd...@mirantis.com Mobile: +1-408-893-0525 Skype: sdoll-mirantis ___ 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
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
On 2014/14/01 21:35, Vitaly Kramskikh wrote: Hi Jaromir, 2014/1/13 Jaromir Coufal jcou...@redhat.com mailto:jcou...@redhat.com So what we can do at the moment (until there is some way to specify which node to remove) is to inform user, which nodes were removed in the end... at least. In the future, I'd like to enable user to have both ways available - just decrease number and let system to decide which nodes are going to be removed for him (but at least inform in advance which nodes are the chosen ones). Or, let user to choose by himself. I think the functionality to choose which node is allocated for each role is needed to. I didn't realize how/if it is possible from the wireframes. For example, I have 3 racks. I want to allocate 1 node from each rack for Controller and make other nodes Computes and then make each rack a separate availability zone. In this case I need to specify which exact node will become Controller. Is it possible to do this? Hi Vitaly, this is excellent question. And I was rising similar concerns before. I believe I managed to get to some compromise how we can achieve such use-case. In Node Profile, you are able to specify HW specs as well as node tags (both should be already available in Ironic). So if user has Tags well set up (for example mark desired nodes with specific tag), we should be able re-use that tag in Node Profile definition of Controller role and during scheduling process. I hope that in time we will be able to get to smoother experience ;) Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Docker and TripleO
On 2014/01/01 03:35, Robert Collins wrote: So, we've spoken about using containers on baremetal - e.g. the lxc provider - in the past, and with the [righteously deserved] noise Docker is receiving, I think we need to have a short expectation-setting discussion. Previously we've said that deploying machines to deploy containers to deploy OpenStack was overly meta - I stand by it being strictly unnecessary, but since Docker seems to have gotten a really good sweet spot together, I think we're going to want to revisit those discussions. However, I think we should do so no sooner than 6 months, and probably more like a year out. I say 6-12 months because: - Docker currently describes itself as 'not for production use' - It's really an optimisation from our perspective - We need to ship a production ready version of TripleO ASAP, and I think retooling would delay us more than it would benefit us. - There are going to be some nasty bootstrapping issues - we have to deploy the bare metal substrate and update it in all cases anyway - And I think pushing ahead with (any) container without those resolved is unwise - because our goal as always has to be to push the necessary support into the rest of OpenStack, *not* as a TripleO unique facility. This all ties into other threads that have been raised about future architectures we could use: I think we want to evolve to have better flexability and performance, but lets get a v1 minimal but functional - HA, scalable, usable - version in place before we advance. -Rob +1 especially to the last two paragraphs. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations
Hi Jay, Awesome. I'll just add quick note inline (and sorry for smaller delay): On 2014/09/01 18:22, Jay Dobies wrote: I'm trying to hash out where data will live for Tuskar (both long term and for its Icehouse deliverables). Based on the expectations for Icehouse (a combination of the wireframes and what's in Tuskar client's api.py), we have the following concepts: [snip] = Resource Categories = [snip] == Count == In the Tuskar UI, the user selects how many of each category is desired. This stored in Tuskar's domain model for the category and is used when generating the template to pass to Heat to make it happen. Based on latest discussions - instance count is a bit tricky, but it should be specific to Node Profile if we care what hardware we want in the play. Later, we can add possibility to enter just number of instances for the whole resource category and let system to decide for me which node profile to deploy. But I believe this is future look. These counts are what is displayed to the user in the Tuskar UI for each category. The staging concept has been removed for Icehouse. In other words, the wireframes that cover the waiting to be deployed aren't relevant for now. +1 == Image == For Icehouse, each category will have one image associated with it. Last I remember, there was discussion on whether or not we need to support multiple images for a category, but for Icehouse we'll limit it to 1 and deal with it later. Metadata for each Resource Category is owned by the Tuskar API. The images themselves are managed by Glance, with each Resource Category keeping track of just the UUID for its image. I think we were discussing to keep track of image's name there. Thanks for this great work -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations
On 2014/12/01 20:40, Jay Pipes wrote: On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote: So, it's not as simple as it may initially seem :) Ah, I should have been clearer in my statement - my understanding is that we're scrapping concepts like Rack entirely. That was my understanding as well. The existing Tuskar domain model was largely placeholder/proof of concept and didn't necessarily reflect exactly what was desired/expected. Hmm, so this is a bit disappointing, though I may be less disappointed if I knew that Ironic (or something else?) planned to account for datacenter inventory in a more robust way than is currently modeled. If Triple-O/Ironic/Tuskar are indeed meant to be the deployment tooling that an enterprise would use to deploy bare-metal hardware in a continuous fashion, then the modeling of racks, and the attributes of those racks -- location, power supply, etc -- are a critical part of the overall picture. As an example of why something like power supply is important... inside ATT, we had both 8kW and 16kW power supplies in our datacenters. For a 42U or 44U rack, deployments would be limited to a certain number of compute nodes, based on that power supply. The average power draw for a particular vendor model of compute worker would be used in determining the level of compute node packing that could occur for that rack type within a particular datacenter. This was a fundamental part of datacenter deployment and planning. If the tooling intended to do bare-metal deployment of OpenStack in a continual manner does not plan to account for these kinds of things, then the chances that tooling will be used in enterprise deployments is diminished. And, as we all know, when something isn't used, it withers. That's the last thing I want to happen here. I want all of this to be the bare-metal deployment tooling that is used *by default* in enterprise OpenStack deployments, because the tooling fits the expectations of datacenter deployers. It doesn't have to be done tomorrow :) It just needs to be on the map somewhere. I'm not sure if Ironic is the place to put this kind of modeling -- I thought Tuskar was going to be that thing. But really, IMO, it should be on the roadmap somewhere. All the best, -jay Perfect write up, Jay. I can second these needs based on talks I had previously. The goal is to primarily support enterprise deployments and they work with racks, so all of that information such as location, power supply, etc are important. Though this is pretty challenging area and we need to start somewhere. As a proof of concept, Tuskar tried to provide similar views, then we jumped into reality. OpenStack has no strong support in racks field for the moment. As long as we want to deliver working deployment solution ASAP and enhance it in time, we started with currently available features. We are not giving up racks entirely, they are just a bit pushed back, since there is no real support in OpenStack yet. But to deliver more optimistic news, regarding last OpenStack summit, Ironic intends to work with all the racks information (location, power supply, ...). So once Ironic contains all of that information, we can happily start providing such capability for deployment setups, hardware overviews, etc. Having said that, for Icehouse I pushed for Node Tags to get in. It is not the best experience, but using Node Tags, we can actually support various use-cases for user (by him tagging nodes manually at the moment). Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Editing Nodes
On 2014/15/01 22:33, Jay Dobies wrote: On 01/15/2014 08:07 AM, James Slagle wrote: [snip] I may be misinterpreting, but let me say that I don't think Tuskar should be building images. There's been a fair amount of discussion around a Nova native image building service [1][2]. I'm actually not sure what the status/concensus on that is, but maybe longer term, Tuskar might call an API to kick off an image build. I didn't mean to imply that Tuskar would be building images, just kicking them off. Definitely not at the moment. As for whether or not it should, that's an interesting question. You and I are both on the same page on not having a generic image and having the services be configured outside of that, so I'll ignore that idea for now. I've always thought of Tuskar as providing the user with everything they'd need. My gut reaction is that I don't like the idea of saying they have to go through a separate step of creating the image and then configuring the resource category in Tuskar and attaching the image to it. That said, I suspect my gut is wrong, or at very least not in line with the OpenStack way of thinking. Well, I think you are right. We should be able to provide as much as possible. I don't think that Tuskar has to do everything. Image builder would be amazing feature. And I don't think it has to be Tuskar-UI business. There can be UI separate from Tuskar, which is part of Horizon umbrella, dealing only with building images. I think it has enough reasons to become a separate project in the future. Ok, so given that frame of reference, I'll reply inline: On Mon, Jan 13, 2014 at 11:18 AM, Jay Dobies jason.dob...@redhat.com wrote: I'm pulling this particular discussion point out of the Wireframes thread so it doesn't get lost in the replies. = Background = It started with my first bulletpoint: - When a role is edited, if it has existing nodes deployed with the old version, are the automatically/immediately updated? If not, how do we reflect that there's a difference between how the role is currently configured and the nodes that were previously created from it? I would think Roles need to be versioned, and the deployed version recorded as Heat metadata/attribute. When you make a change to a Role, it's a new version. That way you could easily see what's been deployed, and if there's a newer version of the Role to deploy. +1, the more I've been thinking about this, the more I like it. We can't assume changes will be immediately applied to all provisioned instances, so we need some sort of record of what an instance was actually built against. Does it need to be new version of the whole Resource Category? The image information might be part of the node. And we can only display in the UI that certain amount of nodes are running based on different image than is actually available. = Regarding immediate changes = For me, Resource Category is indicating some role of the node. It is given by certain behavior and I expect all the nodes behave the same way. If I change some settings of the role which change the behavior (set of services, config), I would expect all nodes behave the same way - new nodes as well as old ones - so it indicates the immediate change for me. Otherwise, if I expect old nodes to behave one way and new nodes to behave differently, I need to create another role. On the other hand, if I only update image OS, packages, or whatever, but the behavior of the node remains the same (same set of services, same configuration), I do expect to have those nodes with old image working along with nodes containing new image and apply the upgrade when I want to. [snip] But there was also idea that there will be some generic image, containing all services, we would just configure which services to start. In that case we would need to version also this. -1 to this. I think we should stick with specialized images per role. I replied on the wireframes thread, but I don't see how enabling/disabling services in a prebuilt image should work. Plus, I don't really think it fits with the TripleO model of having an image created based on it's specific role (I hate to use that term and muddy the wateri mean in the generic sense here). It was not agreed which way to go. I agree that first step should be to have specific images and don't deal with enabling/disabling services. It's outside the Icehouse timeframe, but for future direction, I am removing the enable/disable functionality from wireframes. [snip] If the image is immediately created, what happens if the user tries to change the resource category counts while it's still being generated? That question applies both if we automatically update existing nodes as well as if we don't and the user is just quick moving around the UI. This should never happen. Once heat stack is updating, you shouldn't be able to apply for other change. What do we do with old images from previous configurations of
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
On 2014/13/01 13:15, Ladislav Smola wrote: The usage of roles is new metric which doesn't exist. It is the most consumed HW resource (which means if CPU is consumed by 60 % and RAM or disk are less, then the role usage is 60 %). It would be great to have such a metric from Ceilometer. However, I don't know how much support they will give us. We can get partial metrics (CPU, RAM, Disk) from Ceilometer, but the final Role usage is questionable. We will be able to get 3 meters avg. in one query, so we should be able to easily determine which metrics we want to show. As I am thinking about it, I would like to show what metric we are showing anyway. Cause naming 'capacity' as max(CPU, RAM, Disk) might be confusing. Those 3 meters are correct. And exposing those 3 metrics at one overview page for quick glance is overwhelming for user. Important for him is to see, how much resources is left for my deployment/role. Showing them 3 graphs instead of one is too much information if I don't want to look at detailed data. That's why I think that 'role capacity' is important to show. And not just actual consumption but also historical data. - When a role is edited, if it has existing nodes deployed with the old version, are the automatically/immediately updated? If not, how do we reflect that there's a difference between how the role is currently configured and the nodes that were previously created from it? I would expect any Role change to be applied immediately. If there is some change where I want to keep older nodes how they are set up and apply new settings only to new added nodes, I would create new Role then. Hmm, I would rather see preview page, because it's quite dangerous operation. Though that's future talking. Well - yes. But what we are talking at the moment is Icehouse timeframe and we don't have anything where to store the information about changes at the moment. And it would be pretty expensive operation. So that's why I said - focus on allow changes, apply immediately. Of course, the direction should go the way of preview all the changes and apply all together. If there is some change where I want to keep older nodes how they are set up and apply new settings only to new added nodes this should not be ever possible. All nodes under the Role has to be the same. That is incorrect. Nodes can be heterogeneous. You can have multiple node profiles, you can have higher hw spec then spec of the node profile (flavor), so that node can be chosen as well, etc. I believe Jay was asking about the preview page. So if it won't be immediately updated, you would store what you want to update. Then you could even see it all summarized on a preview page before you hit 'update'. Nope, I believe it was about keeping nodes with different settings in. I hope I answered the question before. Related question is - when send heat change, are the nodes immediately ready for use once each node is provisioned? Or... when node is provisioned, it waits for the heat template to get finished and then they all get to operation together? I would say that it depends on node. E.g. once compute node is registered to overcloud nova scheduler, you can start to use it. So it should be similar for others. This applies only for stack-update. I am asking in general. When I am doing my first deployment, are the nodes coming up being ready one by one or all at the same time once the process is finished? When doing heat template change and changing number of nodes, are the nodes coming up one by one when they are ready? Or do they appear ready only after stack-update is finished? (talking about all roles, not just compute) -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
On 2014/13/01 12:20, Ladislav Smola wrote: [snip of larger amount of text] - When on the change deployments screen, after making a change but not yet applying it, how are the projected capacity changes calculated? I believe we wanted to make just simple algorithm, that was considering, that adding a new node would would spread the load between the nodes equally. Though this depends on how overcloud is set. It would have to be set the way, that after adding new hardware, overcloud would migrate VM's over them equally(which is not always achievable). So I am not really sure about this part. We are at the beginning, so we should focus on enabling scaling and not to deal with migrations of VM's. We can do that in later steps as enhancements, but it shouldn't slow us down at the moment. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
1) Check for an already deleted server before deleting any. This is related to stack convergence: https://blueprints.launchpad.net/heat/+spec/stack-convergence This will allow users to just delete a server they want to delete, and then update the template to reflect reality. 2) Allow resources to be marked as critical or disposable. Critical resources would not ever be deleted for scaling purposes or during updates. An update would fail if there were no disposable resources. Scaling down would just need to be retried at this point. With those two things, TripleO can make the default disposable for stateless resources, and critical for stateful resources. Tuskar would just report on problems in managing the Heat stack. Admins can then control any business cases for evacuations/retirement of workloads/etc for automation purposes. This is nice feature, though it looks post-I business. I would focus more on 1) at the moment. But it's good direction. Eventually perhaps we could use Mistral to manage that, but for now, I think just being able to protect and manually delete important nodes for scale down is enough. Perhaps Tuskar could even pop up a dialog showing them and allowing manual selection. Clint, this is exactly what I was asking for and thank you for bringing this up. It would be awesome if we can do it. But I was told that this is not very well possible with current TripleO approach. So my question is - when scaling down, are we able to show user a list of participating nodes, let him select which nodes he wants to remove and update the template to reflect the reality then? All in Icehouse timeframe...? Thanks -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
On 2014/13/01 16:45, Jiří Stránský wrote: [snip] The other approach is just to scale the number of nodes in a role and let system decide the best match (which node profile is chosen will be decided on the best fit, probably). Hmm i'm not sure i understand - what do you think by best fit here? E.g. i have 32 GB RAM profile and 256 GB RAM profile in the compute role (and i have unused machines available for both profiles), and i increase compute node count by 2. What do i best-fit against? (Alternatively, if we want to support scaling a role using just one spinner, even though the role has more profiles, maybe we could pick the largest profile with unused nodes available?) Hehe, that is a good question - what is the magic 'best fit'. It will depend on nova-scheduler, how it is implemented. Complete product of my mind follows... Theoretically, it might be the way that scheduler will look at all requirements and find the best distribution across the deployment so it satisfies all needs (for example two roles are fighting for one node). If there is situation that it doesn't matter, it would take the higher/lower one (there can be some preference, priority to set it up). To summarize, I think this is all about scheduler configuration. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes
Hi folks, thanks everybody for feedback. Based on that I updated wireframes and tried to provide a minimum scope for Icehouse timeframe. http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-16_tripleo-ui-icehouse.pdf Hopefully we are able to deliver described set of features. But if you find something what is missing which is critical for the first release (or that we are implementing a feature which should not have such high priority), please speak up now. The wireframes are very close to implementation. In time, there will appear more views and we will see if we can get them in as well. Thanks all for participation -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
Hi Jeff, many thanks for great feedback. Few comments are inline: On 2014/10/01 16:16, Walls, Jeffrey Joel (Cloud OS RD) wrote: Jarda, I love how this is progressing. It will be very nice once it's implemented! The iconography seems to be inconsistent. The ! triangle is used for error conditions and warning conditions; and the x hexagon is also used for error conditions. You are right, in one version I used first set, in other I used other set, I need to get it consistent. Due to rapid wireframing I missed this one (and I am sure there will be more such mistakes). Thanks for pointing this out :) For the Roles usage, will the user be able to scroll back and see more than the last month's usage? On the overview pages, I wanted to keep it simple and show just last month. But if you click on the usage percentage (or detailed statistics icon), you should get modal window with detailed statistics, were you should be able to set timeframe you are interested in (with more details of course) For configuration, will it be possible to supply default values to these and let the user change them only if they want to? For some values it's probably not possible, but for others it will be. The fewer things the user has to enter the better. I completely agree here. If we can provide default values, we should set it up. Unfortunately for the fields which are listed in wireframes, I think we can estimate them. Anyway, I guess that the whole set of configurable items will change in time based on feedback. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
Hi Jay, thanks for your questions, they are great. I am going to answer inline: On 2014/10/01 17:18, Jay Dobies wrote: Thanks for recording this. A few questions: - I'm guessing the capacity metrics will come from Ceilometer. Will Ceilometer provide the averages for the role or is that calculated by Tuskar? The usage of roles is new metric which doesn't exist. It is the most consumed HW resource (which means if CPU is consumed by 60 % and RAM or disk are less, then the role usage is 60 %). It would be great to have such a metric from Ceilometer. However, I don't know how much support they will give us. We can get partial metrics (CPU, RAM, Disk) from Ceilometer, but the final Role usage is questionable. - When on the change deployments screen, after making a change but not yet applying it, how are the projected capacity changes calculated? At the moment, I am working with one time change. Which means - it appears in modal window, and if I don't apply the change, it will get canceled. So we don't have to store 'change' values anyhow. At least for now. - For editing a role, does it make a new image with the changes to what services are deployed each time it's saved? So, there are two things - one thing is provisioning image. We are not dealing with image builder at the moment. So the image already contains services which we should be able to discover (what OpenStack services are included there). And then you go to service tab and enable/disable which services are provided within a role + their configuration. I would expect, that each time I change some Role settings, it gets applied (which might mean re-provisioning nodes if needed). However, I think it is only the case when you change provisioning image. - When a role is edited, if it has existing nodes deployed with the old version, are the automatically/immediately updated? If not, how do we reflect that there's a difference between how the role is currently configured and the nodes that were previously created from it? I would expect any Role change to be applied immediately. If there is some change where I want to keep older nodes how they are set up and apply new settings only to new added nodes, I would create new Role then. - I don't see any indication that the role scaling process is taking place. That's a potentially medium/long running operation, we should have some sort of way to inform the user it's running and if any errors took place. That's correct, I didn't provide that view yet. I was more focusing on views with settings and cofnig then the flow. But I will add this view as well. I completely agree it is needed. That last point is a bit of a concern for me. I like the simplicity of what the UI presents, but the nature of what we're doing doesn't really fit with that. I can click the count button to add 20 nodes in a few seconds, but the execution of that is a long running, asynchronous operation. We have no means of reflecting that it's running, nor finding any feedback on it as it runs or completes. As I mentioned above, yeah, you are right here. I will reflect that. Related question. If I have 20 instances and I press the button to scale it out to 50, if I immediately return to the My Deployment screen what do I see? 20, 50, or the current count as they are stood up? I'll try to send the screen soon. Related question is - when send heat change, are the nodes immediately ready for use once each node is provisioned? Or... when node is provisioned, it waits for the heat template to get finished and then they all get to operation together? It could all be written off as a future feature, but I think we should at least start to account for it in the wireframes. The initial user experience could be off putting if it's hard to discern the difference between what I told the UI to do and when it's actually finished being done. It's also likely to influence the ultimate design as we figure out who keeps track of the running operations and their results (for both simple display purposes to the user and auditing reasons). One more time, thanks a lot for all the question Jay, they help to clarify lot of details in the background. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
On 2014/10/01 19:02, Dougal Matthews wrote: Hi, Thanks for the wireframes and the walkthrough. Very useful. I've a few comments. - I'd like to echo the comments from the recording about Role I think the term probably isn't specific enough but I don't have a great suggestion. However, this is probably suited better to the other thread. - We will have a number of long processes, for example, when a deploy or re-size is happening. How do we keep the user informed of the progress and errors? I don't see anything in the wireframes, but maybe there is a Horizon standard approach I'm less familiar with. For example, I have 50 compute nodes, then I add 10 but I want to know how many are ready etc. That's correct, I already replied to Jay Dobies' mail on similar topic. I will try to visualize that process as well in wireframes in next days. - If I remove some instances, do I as the administrator need to care which are removed? Do we need to choose or be informed at the end? This is great question on which we have long debates. I am convinced that I as administrator, do care which nodes I want to free up. But current TripleO approach is using heat template and there we can just specify number of nodes of that specific role. So it means that I decrease from 10 to 9 instances and app will take care for us for some node to be removed (AFAIK heat removes the last added node). So what we can do at the moment (until there is some way to specify which node to remove) is to inform user, which nodes were removed in the end... at least. In the future, I'd like to enable user to have both ways available - just decrease number and let system to decide which nodes are going to be removed for him (but at least inform in advance which nodes are the chosen ones). Or, let user to choose by himself. Thanks -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
On 2014/10/01 21:17, Jay Dobies wrote: Another question: - A Role (sounds like we're moving away from that so I'll call it Resource Category) can have multiple Node Profiles defined (assuming I'm interpretting the + and the tabs in the Create a Role wireframe correctly). But I don't see anywhere where a profile is selected when scaling the Resource Category. Is the idea behind the profiles that you can select how much power you want to provide in addition to how many nodes? Yes, that is correct, Jay. I mentioned that in walkthrough and in wireframes with the note More views needed (for deploying, scaling, managing roles). I would say there might be two approaches - one is to specify which node profile you want to scale in order to select how much power you want to add. The other approach is just to scale the number of nodes in a role and let system decide the best match (which node profile is chosen will be decided on the best fit, probably). I lean towards the first approach, where you specify what role and which node profile you want to use for scaling. However this is just introduction of the idea and I believe we can get answers until we get to that step. Any preferences for one of above mentioned approaches? -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
Hi everybody, there is first stab of Deployment Management section with future direction (note that it was discussed as a scope for Icehouse). I tried to add functionality in time and break it down to steps. This will help us to focus on one functionality at a time and if we will be in time pressure for Icehouse release, we can cut off last steps. Wireframes: http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-10_tripleo-ui_deployment-management.pdf Recording of walkthrough: https://www.youtube.com/watch?v=9ROxyc85IyE We sare about to start with first step as soon as possible, so please focus on our initial steps the most (which doesn't mean that we should neglect the direction). Every feedback is very welcome, thanks -- Jarda ___ 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
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 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
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge
Hi All, After yesterday's weekly meeting it seems that majority of us is leaning towards this approach (codebase merge). However there are few concerns regarding speed of development and resources especially for reviews. With this e-mail, I'd like to kick off discussion about how we might assure to get enough people so that we can fulfill Horizon as well as Tuskar-UI goals. With respect to the e-mail which was sent Dec 17 (quoted below), I think all of what was written applies, we just need to clarify couple more details. And I hope we can get to consensus by the end of this week so that we can make things happen. *Blueprints:* Currently there is couple of already existing blueprints for Tuskar-UI and there will appear more based on wireframes around deployment setup (which are not finished yet). https://blueprints.launchpad.net/tuskar-ui We want to make sure, that Horizoners are fine with these blueprints being merged with Horizon ones, keeping their priorities and that there will appear couple more in time. *Cores:* To make sure that we have enough people to get the code in and also to help Horizoners to free load of reviews on their side, we propose to merge our core team (plus rdopieralski). All of them contributes to Horizon so they know the code well. People we are talking about: - jomara - jtomasek - lsmola - rdopieralski - tzumainn - (jcoufal) - At the moment I am in the core team but not doing reviews that often. From time to time I check implementation if it matches vision. With speeding up development, I will try to do more but not that often as above mentioned guys. My role there is more about helping to triage bugs and blueprints based on wireframes, project goals and direction. I am completely OK with not being included in core team after merger, I just want to ask if I can keep being able to help with blueprints and bugs triaging. Of course, everybody in core team needs to keep on track. We can evaluate the list in time and if anybody is not doing reviews properly, they should be removed from the list. So the question here is, if Horizoners are OK with above listed guys being merged to horizon-core team? *Reviews:* Even after merger we would love to keep cross-company reviews culture. And here are the main concerns I believe. I envision that the code will be developed really fast and will need attention for reviews. If we can't get code in, in reasonable time, Tuskar UI goals for Icehouse are jeopardized. So we should try to at least get to consensus about notion of future cores cooperation, so we feel that it can work well. My proposal: I think we are able to keep cross-company reviews approach. As was said there are about 6 non-redhat cores in Horizon. What can we do to ease the load for them? * Tuskar UI cores will help with reviews in Horizon (this will decrease the number of needed reviews in Horizon in general) * Tuskar UI cores will review the Tuskar UI code, their main responsibility will be that the code works well from functional and TripleO point of view. * Horizon core reviewer doesn't have to assure that the code works well from TripleO point of view (furthermore it might be hard for them to get the setup with Tuskar UI working, at least from the beginning). * Horizon core reviewer can just keep eye on whatever code is trying to get into Horizon's codebase, that it makes sense for Horizon's standards. So he/she just blesses that this is the right way to do it in Horizon. In time Horizon core reviewers will get more familiar with Tuskar UI and will be able to evaluate also other areas. But we don't want to burden you guys with completely new complex area asking for approvals there. I was also asking for fallback plan. If we merge and the speed of development will be slowed by reviews (that it won't work that smooth as we expected), if we can ask for exception for cross-company reviews in Tuskar-UI (until the end of Icehouse cycle). I hope it won't be big problem since it was already suggested and David was also open to this from the beginning. However I don't think this should be primary approach, just fallback plan. Any other ideas? Thoughts? Thanks everyone -- Jarda PS: One small comment inline: On 2013/17/12 11:04, Ladislav Smola wrote: Horizoners, As an alternative merge option, we could merge directly to Horizon code base. After some conversation, we have realized that it is possible to mix codebase of incubated and integrated projects, as Trove showed us. Contrary to what was said in the last meeting, we do not require any special treatment for the infrastructure tab and we will continue the development of the infrastructure tab with the same rules as the rest of the Horizon. Especially, we want to keep culture of cross company reviewers, so that we make sure that TripleO/Tuskar UI is not only in hands of one company. It is important to mention that there will be more code to keep eyes
