Re: [openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback
On 06/28/2017 03:03 PM, Steven Hardy wrote: On Wed, Jun 28, 2017 at 8:06 PM, Ben Nemec wrote: A few weeks later than I had planned, but here's the other half of the field feedback I mentioned in my previous email: * They very emphatically want in-place upgrades to work when moving from non-containerized to containerized. I think this is already the plan, but I told them I'd make sure development was aware of the desire. It is the plan, and already has basic CI coverage via gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv At this point we need more testing of production-like deployments but in general this is expected to work. Okay, that's what I thought and told them initially, but they feel quite strongly about this so I told them I would check. Job done. :-) * There was also great interest in contributing back some of the custom templates that they've had to write to get advanced features working in the field. Here again we recommended that they start with an RFE so things could be triaged appropriately. I'm hoping we can find some developer time to help polish and shepherd these things through the review process. * Policy configuration was discussed, and I pointed them at some recent work we have done around that: https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html I'm not sure it fully addressed their issues, but I suggested they take a closer look and provide feedback on any ways it doesn't meet their needs. The specific use case they were looking at right now was adding a read-only role. They did provide me with a repo containing their initial work, but unfortunately it's private to Red Hat so I can't share it here. * They wanted to be able to maintain separate role files instead of one monolithic roles_data.yaml. Apparently they have a pre-deploy script now that essentially concatenates some individual files to get this functionality. I think this has already been addressed by https://review.openstack.org/#/c/445687 Yes this is already possible, but only via the CLI - that feature needs porting to tripleo-common so that it can be consumed by tripleo-ui, which was discussed but I'm not sure on the latest status. * They've also been looking at ways to reorganize the templates in a more intuitive fashion. At first glance the changes seemed reasonable, but they were still just defining the layout. I don't know that they've actually tried to use the reorganized templates yet and given the number of relative paths in tht I suspect it may be a bigger headache than they expect, but I thought it was interesting. There may at least be elements of this work that we can use to make the templates easier to understand for deployers. More information on this would be helpful, e.g what specific issues they are trying to solve and the layout they found to be better and why? Looking at the contents of the repo again I'm not sure they actually rearranged tht at all. I think they may just have been defining a structure for their environment files and role definitions. I probably need to follow up with them when they have a little more concrete idea of what they want to do around this. __ 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] Pt. 2 of Passing along some field feedback
On Wed, Jun 28, 2017 at 8:06 PM, Ben Nemec wrote: > A few weeks later than I had planned, but here's the other half of the field > feedback I mentioned in my previous email: > > * They very emphatically want in-place upgrades to work when moving from > non-containerized to containerized. I think this is already the plan, but I > told them I'd make sure development was aware of the desire. It is the plan, and already has basic CI coverage via gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv At this point we need more testing of production-like deployments but in general this is expected to work. > * There was also great interest in contributing back some of the custom > templates that they've had to write to get advanced features working in the > field. Here again we recommended that they start with an RFE so things > could be triaged appropriately. I'm hoping we can find some developer time > to help polish and shepherd these things through the review process. > > * Policy configuration was discussed, and I pointed them at some recent work > we have done around that: > https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html > I'm not sure it fully addressed their issues, but I suggested they take a > closer look and provide feedback on any ways it doesn't meet their needs. > > The specific use case they were looking at right now was adding a read-only > role. They did provide me with a repo containing their initial work, but > unfortunately it's private to Red Hat so I can't share it here. > > * They wanted to be able to maintain separate role files instead of one > monolithic roles_data.yaml. Apparently they have a pre-deploy script now > that essentially concatenates some individual files to get this > functionality. I think this has already been addressed by > https://review.openstack.org/#/c/445687 Yes this is already possible, but only via the CLI - that feature needs porting to tripleo-common so that it can be consumed by tripleo-ui, which was discussed but I'm not sure on the latest status. > * They've also been looking at ways to reorganize the templates in a more > intuitive fashion. At first glance the changes seemed reasonable, but they > were still just defining the layout. I don't know that they've actually > tried to use the reorganized templates yet and given the number of relative > paths in tht I suspect it may be a bigger headache than they expect, but I > thought it was interesting. There may at least be elements of this work > that we can use to make the templates easier to understand for deployers. More information on this would be helpful, e.g what specific issues they are trying to solve and the layout they found to be better and why? Thanks, Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback
A few weeks later than I had planned, but here's the other half of the field feedback I mentioned in my previous email: * They very emphatically want in-place upgrades to work when moving from non-containerized to containerized. I think this is already the plan, but I told them I'd make sure development was aware of the desire. * There was also great interest in contributing back some of the custom templates that they've had to write to get advanced features working in the field. Here again we recommended that they start with an RFE so things could be triaged appropriately. I'm hoping we can find some developer time to help polish and shepherd these things through the review process. * Policy configuration was discussed, and I pointed them at some recent work we have done around that: https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html I'm not sure it fully addressed their issues, but I suggested they take a closer look and provide feedback on any ways it doesn't meet their needs. The specific use case they were looking at right now was adding a read-only role. They did provide me with a repo containing their initial work, but unfortunately it's private to Red Hat so I can't share it here. * They wanted to be able to maintain separate role files instead of one monolithic roles_data.yaml. Apparently they have a pre-deploy script now that essentially concatenates some individual files to get this functionality. I think this has already been addressed by https://review.openstack.org/#/c/445687 * They've also been looking at ways to reorganize the templates in a more intuitive fashion. At first glance the changes seemed reasonable, but they were still just defining the layout. I don't know that they've actually tried to use the reorganized templates yet and given the number of relative paths in tht I suspect it may be a bigger headache than they expect, but I thought it was interesting. There may at least be elements of this work that we can use to make the templates easier to understand for deployers. Thanks. -Ben __ 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
