Re: [openstack-dev] [TripleO][Tuskar] Questions around Development Process
Thanks to all who replied, it's extremely helpful. I'll add a focus on integration tests to the list of requirements Mainn - Original Message - Hey, you've already got a bunch of answers, but FWIW: a) I think it's fine to do a few big patches deleting stuff you don't want. You can always bring it back from git history. OTOH if you bring it back it will be reviewed again :). b) I think UI + API + pythonclient in parallel is ok, but: - please get tempest (which implies devstack too) API tests up as quickly as possible. Tempest provides the contract definition to detect regressions in API usage. You can't deploy a production cloud on top of devstack, but you can use Heat and Keystone and Glance and Ironic APIs sensibly, which will let meaningful tests of Tuskar API. I'm not sure where the JS / Horizon tests fit precisely, but again - lets make sure that we have functional tests in Tempest as quickly as possible: this is crucial for when we start 'Integration'. Cheers, Rob On 7 December 2013 04:37, Tzu-Mainn Chen tzuma...@redhat.com wrote: Hey all, We're starting to work on the UI for tuskar based on Jarda's wireframes, and as we're doing so, we're realizing that we're not quite sure what development methodology is appropriate. Some questions: a) Because we're essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar will simply disappear), it's difficult to do small incremental patches that support existing functionality. Is it okay to have patches that break functionality? Are there good alternatives? b) In the past, we allowed parallel development of the UI and API by having well-documented expectations of what the API would provide. We would then mock those calls in the UI, replacing them with real API calls as they became available. Is this acceptable? If there are precedents for this kind of stuff, we'd be more than happy to follow them! Thanks, Tzu-Mainn Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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] Questions around Development Process
Hey all, We're starting to work on the UI for tuskar based on Jarda's wireframes, and as we're doing so, we're realizing that we're not quite sure what development methodology is appropriate. Some questions: a) Because we're essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar will simply disappear), it's difficult to do small incremental patches that support existing functionality. Is it okay to have patches that break functionality? Are there good alternatives? b) In the past, we allowed parallel development of the UI and API by having well-documented expectations of what the API would provide. We would then mock those calls in the UI, replacing them with real API calls as they became available. Is this acceptable? If there are precedents for this kind of stuff, we'd be more than happy to follow them! Thanks, Tzu-Mainn Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Questions around Development Process
a) Because we're essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar will simply disappear), it's difficult to do small incremental patches that support existing functionality. Is it okay to have patches that break functionality? Are there good alternatives? This is an incubating project, so there are no api stability promises. If a patch breaks some functionality that we've decided to not support going forward I don't see a problem with it. That said, if a patch breaks some functionality that we _do_ plan to keep, I'd prefer to see it done as a series of dependent commits that end with the feature in a working state again, even if some of the intermediate commits are not fully functional. Hopefully that will both keep the commit sizes down and provide a definite path back to functionality. Is there any sort of policy or convention of sending out a warning before that sort of thing is merged in so that people don't accidentally blindly pull master and break something they were using? b) In the past, we allowed parallel development of the UI and API by having well-documented expectations of what the API Are these expectations documented yet? I'm new to the project and still finding my way around. I've seen the wireframes and am going through Chen's icehouse requirements, but I haven't stumbled on too much talk about the APIs specifically (not suggesting they don't exist, more likely that I haven't found them yet). would provide. We would then mock those calls in the UI, replacing them with real API calls as they became available. Is this acceptable? This sounds reasonable to me. -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][Tuskar] Questions around Development Process
b) In the past, we allowed parallel development of the UI and API by having well-documented expectations of what the API Are these expectations documented yet? I'm new to the project and still finding my way around. I've seen the wireframes and am going through Chen's icehouse requirements, but I haven't stumbled on too much talk about the APIs specifically (not suggesting they don't exist, more likely that I haven't found them yet). Not quite yet; we'd like to finalize the requirements somewhat first. Hopefully something will be available sometime next week. In the meantime, targeted UI work is mostly structural (navigation) and making sure that the right widgets exist for the wireframes. Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Questions around Development Process
Excerpts from Tzu-Mainn Chen's message of 2013-12-06 07:37:20 -0800: Hey all, We're starting to work on the UI for tuskar based on Jarda's wireframes, and as we're doing so, we're realizing that we're not quite sure what development methodology is appropriate. Some questions: a) Because we're essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar will simply disappear), it's difficult to do small incremental patches that support existing functionality. Is it okay to have patches that break functionality? Are there good alternatives? I think Tuskar is early enough in its' life cycle that it has reached that magical plan to throw one away point where you can actually do this without disrupting anybody except yourselves, which actually sounds valuable in this case since you have chosen a different course. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Questions around Development Process
On 2013-12-06 12:19, Jay Dobies wrote: a) Because we're essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar will simply disappear), it's difficult to do small incremental patches that support existing functionality. Is it okay to have patches that break functionality? Are there good alternatives? This is an incubating project, so there are no api stability promises. If a patch breaks some functionality that we've decided to not support going forward I don't see a problem with it. That said, if a patch breaks some functionality that we _do_ plan to keep, I'd prefer to see it done as a series of dependent commits that end with the feature in a working state again, even if some of the intermediate commits are not fully functional. Hopefully that will both keep the commit sizes down and provide a definite path back to functionality. Is there any sort of policy or convention of sending out a warning before that sort of thing is merged in so that people don't accidentally blindly pull master and break something they were using? Not that I know of. Part of using an incubating project is that incompatible changes can be made at any time. I'm well aware how painful that can be if you're trying to consume such a project downstream (I've been there), but that's the price for using a project that hasn't released yet. -Ben ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
