Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer
+1 On Fri, Oct 19, 2018 at 9:46 AM Alex Schultz wrote: > > +1 > On Fri, Oct 19, 2018 at 6:29 AM Emilien Macchi wrote: > > > > On Fri, Oct 19, 2018 at 8:24 AM Juan Antonio Osorio Robles > > wrote: > >> > >> I would like to propose Bob Fournier (bfournie) as a core reviewer in > >> TripleO. His patches and reviews have spanned quite a wide range in our > >> project, his reviews show great insight and quality and I think he would > >> be a addition to the core team. > >> > >> What do you folks think? > > > > > > Big +1, Bob is a solid contributor/reviewer. His area of knowledge has been > > critical in all aspects of Hardware Provisioning integration but also in > > other TripleO bits. > > -- > > 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 __ 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] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"
On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen wrote: > > On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur wrote: >> >> Hi all, >> >> Sorry for chiming in really late in this topic, but I think $subj is worth >> discussing until we settle harder on the potentially confusing terminology. >> >> I think the difference between "Edge" and "Far Edge" is too vague to use >> these >> terms in practice. Think about the "edge" metaphor itself: something rarely >> has >> several layers of edges. A knife has an edge, there are no far edges. I >> imagine >> zooming in and seeing more edges at the edge, and then it's quite cool >> indeed, >> but is it really a useful metaphor for those who never used a strong >> microscope? :) >> >> I think in the trivial sense "Far Edge" is a tautology, and should be >> avoided. >> As a weak proof of my words, I already see a lot of smart people confusing >> these >> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we >> adopt a different terminology, even if it less consistent with typical >> marketing >> term around the "Edge" movement. > > > FWIW, we created rough definitions of "edge" and "far edge" during the edge > WG session in Denver. > It's mostly based on latency to the end user, though we also talked about > quantities of compute resources, if someone can find the pictures. Perhaps these are the pictures Jim was referring to? https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0# I'm involved in some TripleO work called the split control plane: https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html After the PTG I saw that the split control plane was compatible with the type of deployment discussed at the edge WG session in Denver and described the compatibility at: https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane > See the picture and table here: > https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview > >> Now, I don't have really great suggestions. Something that came up in TripleO >> discussions [1] is Core/Hub/Edge, which I think reflects the idea better. > > > I'm also fine with these names, as they do describe the concepts well. :) > > // jim I'm fine with these terms too. In split control plane there's a deployment method for deploying a central site and then deploying remote sites independently. That deployment method could be used to deploy Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack N. Deploy a Hub using stack N+1 and then deploy an Edge using stack N+2 etc. John >> >> I'd be very interested to hear your ideas. >> >> Dmitry >> >> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp >> >> ___ >> openstack-sigs mailing list >> openstack-s...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > __ > 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] Proposing Lukas Bezdicka core on TripleO
+1 I thought he was already core. On Wed, Aug 1, 2018 at 7:33 AM Giulio Fidente wrote: > > Hi, > > I would like to propose Lukas Bezdicka core on TripleO. > > Lukas did a lot work in our tripleoclient, tripleo-common and > tripleo-heat-templates repos to make FFU possible. > > FFU, which is meant to permit upgrades from Newton to Queens, requires > in depth understanding of many TripleO components (for example Heat, > Mistral and the TripleO client) but also of specific TripleO features > which were added during the course of the three releases (for example > config-download and upgrade tasks). I believe his FFU work to have been > very challenging. > > Given his broad understanding, more recently Lukas started helping doing > reviews in other areas. > > I am so sure he'll be a great addition to our group that I am not even > looking for comments, just votes :D > -- > Giulio Fidente > GPG KEY: 08D733BA > > __ > 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] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
On Thu, Jul 26, 2018 at 1:48 AM Cédric Jeanneret wrote:
>
> Hello Sam,
>
> Thanks for the clarifications.
>
> On 07/25/2018 07:46 PM, Sam Doran wrote:
> > I spoke with other Ansible Core devs to get some clarity on this change.
> >
> > This is not a change that is being made quickly, lightly, or without a
> > whole of bunch of reservation. In fact, that PR created by agaffney may
> > not be merged any time soon. He just wanted to get something started and
> > there is still ongoing discussion on that PR. It is definitely a WIP at
> > this point.
> >
> > The main reason for this change is that pretty much all of the Ansible
> > CVEs to date came from "fact injection", meaning a fact that contains
> > executable Python code Jinja will merrily exec(). Vars, hostvars, and
> > facts are different in Ansible (yes, this is confusing — sorry). All
> > vars go through a templating step. By copying facts to vars, it means
> > facts get templated controller side which could lead to controller
> > compromise if malicious code exists in facts.
> >
> > We created an AnsibleUnsafe class to protect against this, but stopping
> > the practice of injecting facts into vars would close the door
> > completely. It also alleviates some name collisions if you set a hostvar
> > that has the same name as a var. We have some methods that filter out
> > certain variables, but keeping facts and vars in separate spaces is much
> > cleaner.
> >
> > This also does not change how hostvars set via set_fact are referenced.
> > (set_fact should really be called set_host_var). Variables set with
> > set_fact are not facts and are therefore not inside the ansible_facts
> > dict. They are in the hostvars dict, which you can reference as {{
> > my_var }} or {{ hostvars['some-host']['my_var'] }} if you need to look
> > it up from a different host.
>
> so if, for convenience, we do this:
> vars:
> a_mounts: "{{ hostvars[inventory_hostname].ansible_facts.mounts }}"
>
> That's completely acceptable and correct, and won't create any security
> issue, right?
>
> >
> > All that being said, the setting to control this behavior as Emilien
> > pointed out is inject_facts_as_vars, which defaults to True and will
> > remain that way for the foreseeable future. I would not rush into
> > changing all the fact references in playbooks. It can be a gradual process.
> >
> > Setting inject_facts_as_vars toTrue means ansible_hostname becomes
> > ansible_facts.hostname. You do not have to use the hostvars dictionary —
> > that is for looking up facts about hosts other than the current host.
> >
> > If you wanted to be proactive, you could start using the ansible_facts
> > dictionary today since it is compatible with the default setting and
> > will not affect others trying to use playbooks that reference ansible_facts.
> >
> > In other words, with the default setting of True, you can use either
> > ansible_hostname or ansible_facts.hostname. Changing it to False means
> > only ansible_facts.hostname is defined.
> >
> >> Like, really. I know we can't really have a word about that kind of
> >> decision, but... damn, WHY ?!
> >
> > That is most certainly not the case. Ansible is developed in the open
> > and we encourage community members to attend meetings
> > and
> > add
> > topics to the agenda
> > for discussion.
> > Ansible also goes through a proposal process for major changes, which
> > you can view here
> > .
> >
> > You can always go to #ansible-devel on Freenode or start a discussion on
> > the mailing list
> > to speak with
> > the Ansible Core devs about these things as well.
>
> And I also have the "Because" linked to my "why" :). big thanks!
Do we have a plan for which Ansible version might be the default in
upcoming TripleO versions?
If this is the thread to discuss it then, I want to point out that
TripleO's been using ceph-ansible for Ceph integration on the client
and server side since Pike and that ceph-ansible 3.1 (which TripleO
master currently uses) fails on Ansible 2.6 and that this won't be
addressed until ceph-ansible 3.2.
John
>
> Bests,
>
> C.
>
> >
> > ---
> >
> > Respectfully,
> >
> > Sam Doran
> > Senior Software Engineer
> > Ansible by Red Hat
> > sdo...@redhat.com
> >
> >
> > __
> > 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
> >
>
> --
> Cédric Jeanneret
> Software Engineer
> DFG:DF
>
> __
> OpenStack Development Mailing List (not for usage qu
Re: [openstack-dev] [tripleo] PTL non-candidacy
On Wed, Jul 25, 2018 at 1:38 PM Raoul Scarazzini wrote: > > On 25/07/2018 15:23, Alex Schultz wrote: > > Hey folks, > > So it's been great fun and we've accomplished much over the last two > > cycles but I believe it is time for me to step back and let someone > > else do the PTLing. I'm not going anywhere so I'll still be around to > > focus on the simplification and improvements that TripleO needs going > > forward. I look forwards to continuing our efforts with everyone. > > Thanks, > > -Alex > > To me you did really a great job. I know you'll be around and so on, but > let me just say thank you. +1000! > > -- > Raoul Scarazzini > ra...@redhat.com > > __ > 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] PTL candidacy for the Stein Cycle
+1 On Wed, Jul 25, 2018 at 8:04 AM Juan Antonio Osorio wrote: > > Hello folks! > > I'd like to nominate myself for the TripleO PTL role for the Stein cycle. > > Alex has done a great job as a PTL: The project is progressing nicely with > many > new, exciting features and uses for TripleO coming to fruition recently. It's > a > great time for the project. But, there's more work to be done. > > I have served the TripleO community as a core-reviewer for some years now and, > more recently, by driving the Security Squad. This project has been a > great learning experience for me, both technically (I got to learn even more > of > OpenStack) and community-wise. Now I wish to better serve the community > further > by bringing my experiences into PTL role. While I have not yet served as PTL > for a project before,I'm eager to learn the ropes and help improve the > community that has been so influential on me. > > For Stein, I would like to focus on: > > * Increasing TripleO's usage in the testing of other projects > Now that TripleO can deploy a standalone OpenStack installation, I hope it > can be leveraged to add value to other projects' testing efforts. I hope > this > would subsequentially help increase TripleO's testing coverage, and reduce > the footprint required for full-deployment testing. > > * Technical Debt & simplification > We've been working on simplifying the deployment story and battle technical > depth -- let’s keep this momentum going. We've been running (mostly) fully > containerized environments for a couple of releases now; I hope we can > reduce > the number of stacks we create, which would in turn simplify the project > structure (at least on the t-h-t side). We should also aim for the most > convergence we can achieve (e.g. CLI and UI workflows). > > * CI and testing > The project has made great progress regarding CI and testing; lets keep this > moving forward and get developers easier ways to bring up testing > environments for them to work on and to be able to reproduce CI jobs. > > Thanks! > > Juan Antonio Osorio Robles > IRC: jaosorior > > > -- > Juan Antonio Osorio R. > e-mail: jaosor...@gmail.com > > __ > 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] Updates/upgrades equivalent for external_deploy_tasks
On Tue, Jul 10, 2018 at 10:21 AM Jiří Stránský wrote: > > Hi, > > with the move to config-download deployments, we'll be moving from > executing external installers (like ceph-ansible) via Heat resources > encapsulating Mistral workflows towards executing them via Ansible > directly (nested Ansible process via external_deploy_tasks). > > Updates and upgrades still need to be addressed here. I think we should > introduce external_update_tasks and external_upgrade_tasks for this > purpose, but i see two options how to construct the workflow with them. > > During update (mentioning just updates, but upgrades would be done > analogously) we could either: > > A) Run external_update_tasks, then external_deploy_tasks. > > This works with the assumption that updates are done very similarly to > deployment. The external_update_tasks could do some prep work and/or > export Ansible variables which then could affect what > external_deploy_tasks do (e.g. in case of ceph-ansible we'd probably > override the playbook path). This way we could also disable specific > parts of external_deploy_tasks on update, in case reuse is undesirable > in some places. > > B) Run only external_update_tasks. > > This would mean code for updates/upgrades of externally deployed > services would be completely separated from how their deployment is > done. If we wanted to reuse some of the deployment tasks, we'd have to > use the YAML anchor referencing mechanisms. (&anchor, *anchor) > > I think the options are comparable in terms of what is possible to > implement with them, the main difference is what use cases we want to > optimize for. > > Looking at what we currently have in external_deploy_tasks (e.g. > [1][2]), i think we'd have to do a lot of explicit reuse if we went with > B (inventory and variables generation, ...). So i'm leaning towards > option A (WIP patch at [3]) which should give us this reuse more > naturally. This approach would also be more in line with how we already > do normal updates and upgrades (also reusing deployment tasks). Please > let me know in case you have any concerns about such approach (looking > especially at Ceph and OpenShift integrators :) ). Thanks for thinking of this Jirka. I like option A and your WIP patch (579170). As you say, it fits with what we're already doing and avoids explicit reuse. John > > Thanks > > Jirka > > [1] > https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/docker/services/ceph-ansible/ceph-base.yaml#L340-L467 > [2] > https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/extraconfig/services/openshift-master.yaml#L70-L231 > [3] https://review.openstack.org/#/c/579170/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits
On Wed, Jun 13, 2018, 12:04 PM Marios Andreou wrote: > > On Wed, Jun 13, 2018 at 6:57 PM, Giulio Fidente > wrote: > >> On 06/13/2018 05:50 PM, Emilien Macchi wrote: >> > Alan Bishop has been highly involved in the Storage backends integration >> > in TripleO and Puppet modules, always here to update with new features, >> > fix (nasty and untestable third-party backends) bugs and manage all the >> > backports for stable releases: >> > >> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22 >> > >> > He's also well knowledgeable of how TripleO works and how containers are >> > integrated, I would like to propose him as core on TripleO projects for >> > patches related to storage things (Cinder, Glance, Swift, Manila, and >> > backends). >> > >> > Please vote -1/+1, >> >> +1 :D >> > > +1 > > +1 >> >> -- >> Giulio Fidente >> GPG KEY: 08D733BA >> >> __ >> 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] container-to-container-upgrades CI job and tripleo-common versions
We hit a bug [1] in CI job container-to-container-upgrades because a workflow that was needed only for Pike and Queens was removed [2] as clean up for the migration to external_deploy_tasks. As we need to support an n undercloud deploying an n-1 overcloud and then upgrading it to an n overcloud, the CI job deploys with Queens THT and master tripleo-common. I take this to be by design as per this support requirement. An implication of this is that we need to keep tripleo-common backwards compatible for the n-1 release and thus we couldn't delete this workflow until Stein. An alternative is to require that tripleo-common be of the same version as tripleo-heat-templates. Recommendations? John PS: for the sake of getting CI I think we should restore the workflow for now [3] [1] https://bugs.launchpad.net/tripleo/+bug/1768116 [2] https://review.openstack.org/#/c/563047 [3] https://review.openstack.org/#/c/565580 __ 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] ironic automated cleaning by default?
On Wed, Apr 25, 2018 at 9:14 AM, Dmitry Tantsur wrote: > Hi all, > > I'd like to restart conversation on enabling node automated cleaning by > default for the undercloud. This process wipes partitioning tables > (optionally, all the data) from overcloud nodes each time they move to > "available" state (i.e. on initial enrolling and after each tear down). > > We have had it disabled for a few reasons: > - it was not possible to skip time-consuming wiping if data from disks > - the way our workflows used to work required going between manageable and > available steps several times > > However, having cleaning disabled has several issues: > - a configdrive left from a previous deployment may confuse cloud-init > - a bootable partition left from a previous deployment may take precedence > in some BIOS > - an UEFI boot partition left from a previous deployment is likely to > confuse UEFI firmware > - apparently ceph does not work correctly without cleaning (I'll defer to > the storage team to comment) > Yes, ceph-disk [1] won't prepare a disk that isn't clean. Deployers new to Ceph may not realize this and deployment tools which trigger ceph-disk will fail to prepare the requested OSDs. It may take the deployer time to realize that is the cause of failure and then they usually enable Ironic's automated cleaning. > For these reasons we don't recommend having cleaning disabled, and I > propose to re-enable it. > > It has the following drawbacks: > - The default workflow will require another node boot, thus becoming > several minutes longer (incl. the CI) > - It will no longer be possible to easily restore a deleted overcloud node. > > What do you think? If I don't hear principal objections, I'll prepare a > patch in the coming days. > +1 John [1] http://docs.ceph.com/docs/hammer/man/8/ceph-disk/ > > Dmitry > > __ > 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] Proposing Marius Cornea core on upgrade bits
+1 On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi wrote: > Greetings, > > As you probably know mcornea on IRC, Marius Cornea has been contributing on > TripleO for a while, specially on the upgrade bits. > Part of the quality team, he's always testing real customer scenarios and > brings a lot of good feedback in his reviews, and quite often takes care of > fixing complex bugs when it comes to advanced upgrades scenarios. > He's very involved in tripleo-upgrade repository where he's already core, > but I think it's time to let him +2 on other tripleo repos for the patches > related to upgrades (we trust people's judgement for reviews). > > As usual, we'll vote! > > Thanks everyone for your feedback and thanks Marius for your hard work and > involvement in the project. > -- > 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] CI'ing ceph-ansible against TripleO scenarios
On Fri, Jan 26, 2018 at 7:29 AM, Giulio Fidente wrote: > On 01/26/2018 01:49 AM, Paul Belanger wrote: >> On Thu, Jan 25, 2018 at 04:22:56PM -0800, Emilien Macchi wrote: >>> Is there any plans to run TripleO CI jobs in ceph-ansible? >>> I know the project is on github but thanks to zuulv3 we can now easily >>> configure ceph-ansible to run Ci jobs in OpenStack Infra. >>> >>> It would be really great to investigate that in the near future so we avoid >>> eventual regressions. >>> Sebastien, Giulio, John, thoughts? >>> -- >>> Emilien Macchi >> >> Just a note, we haven't actually agree to enable CI for github projects just >> yet. While it is something zuul can do now, I believe we still need to >> decide >> when / how to enable it. >> >> We are doing some initial testing with ansible/ansible however. > > but we like being on the front line! :D > > we discussed this same topic with Sebastien and John a few weeks back > and agreed on having some gate job for ceph-ansible CI'ing against TripleO! > > how do we start? I think the candidate branch on ceph-ansible to gate is > "beta-3.1" but there will be more ... I am just not sure we're stable > enough to gate master yet ... but we might do it non-voting, it's up for > debate > > on TripleO side we'd be looking at running scenarios 001 and 004 ... > maybe initially 004 only is good enough as it covers (at least for ceph) > most of what is in 001 as well > > can we continue on IRC? :D > > and thanks Emilien and Paul for starting the thread and helping +1 We talked about this today and there's agreement from Seb to get a job in place for this. I think we could start with the following plan: - Simple extra job in ceph-ansible's CI on github which runs ceph-ansible with the same params that TripleO uses - ceph-ansible triggering zuul: -- I'm hoping I can get a test in place in a test github area with the help of pabelanger (do we have a living example on github of this?) -- Then I can pursue making a real ceph-ansible CI job from the living example Thoughts? John __ 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] Pike Retrospective & Status reporting
On Oct 3, 2017 4:35 AM, "Giulio Fidente" wrote: On 09/18/2017 08:50 PM, Alex Schultz wrote: > Hey folks, > > We started off our PTG with a retrospective for Pike. The output of > which can be viewed here[0][1]. > > One of the recurring themes from the retrospective and the PTG was the > need for better communication during the cycle. One of the ideas that > was mentioned was adding a section to the weekly meeting calling for > current status from the various tripleo squads[2]. Starting next week > (Sept 26th), I would like for folks who are members of one of the > squads be able to provide a brief status or a link to the current > status during the weekly meeting. There will be a spot added to the > agenda to do a status roll call. It was mentioned that folks may > prefer to send a message to the ML and just be able to link to it > similar to what the CI squad currently does[3]. We'll give this a few > weeks and review how it works. hi, I drafted an etherpad for the Integration squad which I hope we can use during the meeting to report about our status [1], primarily consisting of Ceph and IPA integration for now. Juan, John, feel free to make any change or add there anything you feel is useful/necessary. 1. https://etherpad.openstack.org/p/tripleo-integration-squad-status Thanks Giullio. I will update. --John -- Giulio Fidente GPG KEY: 08D733BA __ 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] Debugging TripleO Ceph-Ansible Deployments
I blogged a guide on $subject if anyone wants to test the new method to deploy Ceph http://blog.johnlikesopenstack.com/2017/09/debug-tripleo-ceph-ansible.html John __ 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] all you need to know for PTG TripleO-related topics
On Thu, Sep 7, 2017 at 12:32 PM, Emilien Macchi wrote: > If you use Google Calendar, you really want to use this one: > https://calendar.google.com/calendar/ical/c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com/public/basic.ics > > Or view in HTML here: > https://calendar.google.com/calendar/embed?src=c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com&ctz=America/Denver > > Which contains an updated agenda for TripleO related topics. > > We'll track everything in this etherpad: > https://etherpad.openstack.org/p/tripleo-ptg-queens TripleO Schedule Update for Thursday. 10:45am - 11:30am: Ceph integration futures 3:30pm - 4:30pm: Non x86_64 arch support The chairs of the above sessions have agreed to trade times. The etherpad has been updated but not (yet?) the google calendar. Thanks, John (fultonj) > > I'm looking forward to seeing you folks! > Have safe trips, > -- > 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] Proposing Saravanan KR core
On Fri, Jul 21, 2017 at 11:01 AM, Emilien Macchi wrote: > Saravanan KR has shown an high level of expertise in some areas of > TripleO, and also increased his involvement over the last months: > - Major contributor in DPDK integration > - Derived parameter works > - and a lot of other things like improving UX and enabling new > features to improve performances and networking configurations. > > I would like to propose Saravanan part of TripleO core and we expect > his particular focus on t-h-t, os-net-config and tripleoclient for now > but we hope to extend it later. > > As usual, we'll vote :-) > Thanks, > -- > Emilien Macchi +1 __ 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] Forming our plans around Ansible
On Wed, Jul 12, 2017 at 2:04 AM, Giulio Fidente wrote: > On 07/12/2017 01:53 AM, James Slagle wrote: > >> On Tue, Jul 11, 2017 at 5:53 PM, Steve Baker wrote: >> >>> >>> > >> What would be nice is when a heat->mistral->ansible upgrade step fails, >>> the >>> operator is given an ansible-playbook command to run which skips >>> directly to >>> the failing step. This would dramatically reduce the debug cycle and also >>> make it possible for the operator to automate any required fixes over >>> every >>> host in a role. This would likely mean rendering out ansible config >>> files, >>> playbooks, (and roles?) to the operator's working directory. What >>> happens to >>> these rendered files after deployment is an open question. Delete them? >>> Encourage the operator to track them in source control? >>> >> > interesting question, as long as we run playbooks from a filesystem, I > suppose users can make customizations without "changing" anything in > tripleo ... this is how we tested some of the ceph-ansible fixes! > > for upgrades we should maintain the tasks outside the templates do be able > to do that though, assuming we want users to customize the upgrade tasks I like this option too! Perhaps we could add a new task to a mistral workflow that uses this approach to store the info that was generated dynamically from Heat (e.g. inventory and extra-vars) somewhere (swift?) and then make it easy for the user to get this info and run the playbook manually. Kind of like a debug-on-error option with a dribble file [1] for the deployer. Assuming they get it working again, and we have idempotence, they should just be able to resume the deploy. John [1] https://ftp.gnu.org/old-gnu/Manuals/elisp-manual-20-2.5/html_chapter/elisp_18.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] On the road to Pike
On 02/27/2017 04:53 PM, Emilien Macchi wrote: > Here's a summary of what was said at PTG. Feel free to comment if I > missed something. ... > # Deriving TripleO Parameters from Introspected Data > Driver: fultonj, skramaja > Summary: Set automatically some parameters based on the deployment > type and number of nodes; still letting users override any of the > params we set automatically. > Etherpad: https://etherpad.openstack.org/p/tripleo-derive-params > Spec: https://review.openstack.org/#/c/423304 > Blueprint: WIP (fultonj) ... > To drivers: please create blueprints and link them to this thread, so > I can work on Launchpad for Pike planning. Thanks Emilien, Here is a blueprint for this: https://blueprints.launchpad.net/tripleo/+spec/tripleo-derive-parameters It's going to be revised based on the outcome of the PTG discussion and skramaja is working on the DSL at the moment but the blueprint URL is above. Thanks, John __ 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] [heat][tripleo][mistral][all]PTG: Cross-Project: OpenStack Orchestration Integration
Thanks Rico and Renat. This applies to two specs [1][2] I'm involved in so I'll be sure to be there. --John [1] https://review.openstack.org/#/c/387631/ [2] https://review.openstack.org/#/c/423304/ - Original Message - From: "Renat Akhmerov" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Tuesday, February 14, 2017 12:59:09 AM Subject: [openstack-dev] [heat][tripleo][mistral][all]PTG: Cross-Project: OpenStack Orchestration Integration Ok, thanks Rico. Keep us updated on the schedule changes. I’m currently finalizing the schedule for Mistral, for now I’ll leave Thursday 11.00-12.00 blank. Renat Akhmerov @Nokia On 14 Feb 2017, at 10:49, Rico Lin < rico.lin.gua...@gmail.com > wrote: Let's move the schedule toThursday morning 11:00 am to 12:00 pm in the same room. Hope that schedule work for all:) Also, I will ask if Mon - Tue is available or not, but there might be more cross-project sessions we have to not to conflict with them. 2017-02-14 10:02 GMT+08:00 Renat Akhmerov < renat.akhme...@gmail.com > : On 13 Feb 2017, at 19:30, Emilien Macchi < emil...@redhat.com > wrote: On Mon, Feb 13, 2017 at 4:48 AM, Rico Lin < rico.lin.gua...@gmail.com > wrote: Dear all PTG is approaching, we have few ideas around TripleO team ([1] and [2]) about use case like using Mistral through Heat. It seems some great OpenStacker already start thing about how the Orchestration services (Heat, Mistral, and some other projects) could use together for a better developer or operator experiences. First, of curse, we will arrange a fishbowl design session on Wednesday morning. Let's settle with 10:00 am to 10:50 am at Macon (on level2) for now. Could teams kindly help to make sure they can attend this cross project session or need it reschedule? Can we reschedule it? It seems like the only slot where we have sessions organized is on Wednesday morning, for our container work: https://etherpad.openstack.org/p/tripleo-ptg-pike Wednesday 9:00 Cross-Teams talk about containers and networking Wednesday 10:00: TripleO Containers status update and path forward So I suggest Wednesday afternoon or Thursday or Friday morning. At your convenience. Thursday morning would work for me. Renat Akhmerov @Nokia __ 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 -- May The Force of Open Stack Be With You, Rico Lin irc: ricolin __ 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] [tripleo] Mistral Workflow for deriving THT parameters
is spec? B. Do we want to allow for any parameter to be derived if we unify those parameters under a name and offer workflow that has an identity function which returns it's input as output (but translates for Heat Env files as needed) in addition to other functions (e.g. the cpu_mem_calculator referenced in the spec), because we think they could be used to benefit the deployment for performance or other reasons? I think that giving a name to a set of parameters still involves deriving values with Mistral, it's just that the derivation is a workflow which has to take care of finding that value and saving it in the Heat environment. Such a workflow has a benefit because the deployer doesn't need to know all of the variables that are benefiting them, provided that they know their workload. I.e. the simple power of sharing a combination may be just as valuable as applying formulas to derive a value within that combination. I think we're making a lot of progress overall as we're discussing what abstraction best suits the solution to the individual problems we're trying to solve. Ideally, we'll come to an abstraction that works well for both of our problems. * And another thing, which I couldn't get is, where will the workflow actions be defined, in THT or tripleo_common? The Mistral workflow could be shipped in tripleo-common in workbooks or THT extraconfig/tasks. I'll indicate in the spec that either could be used and solicit feedback. Either way, THT would ship the example profiles/tags as a Heat environment file and users would modify it the same way they modify roles_data.yaml. Heat would be modified to have a OS::Mistral::WorflowExecution resource as the spec is written today. The requirements which I thought of, for deriving workflow are: Parameter Deriving workflow should be * independent to run the workflow I agree. A deployer could see the output (the Heat env files) of the workflow and download them from Swift independently of deploying the overcloud itself. * take basic parameters inputs, for easy deployment, keep very minimal set of mandatory parameters, and rest as optional parameters This may not work for a general solution to allowing users to compose their own performance profiles as indicated in A and B above. I'd certainly use minimal parameters for some settings; e.g. determining the NIC used by Ceph and starting the OSD service with numactl. * read introspection data from Ironic DB and Swift-stored blob Yes. I will add these comments as starting point on the spec. We will work towards bringing down the differences, so that operators headache is reduced to a greater extent. Sounds like a good plan. Regards, Saravanan KR On Fri, Jan 20, 2017 at 9:56 PM, John Fulton wrote: On 01/11/2017 11:34 PM, Saravanan KR wrtoe: Thanks John, I would really appreciate if you could tag me on the reviews. I will do the same for mine too. Hi Saravanan, Following up on this, have a look at the OS::Mistral::WorflowExecution Heat spec [1] to trigger Mistral workflows. I'm hoping to use it for deriving THT parameters for optimal resource isolation in HCI deployments as I mentioned below. I have a spec [2] which describes the derivation of the values, but this is provided as an example for the more general problem of capturing the rules used to derive the values so that deployers may easily apply them. Thanks, John [1] OS::Mistral::WorflowExecution https://review.openstack.org/#/c/267770/ [2] TripleO Performance Profiles https://review.openstack.org/#/c/423304/ On Wed, Jan 11, 2017 at 8:03 PM, John Fulton wrote: On 01/11/2017 12:56 AM, Saravanan KR wrote: Thanks Emilien and Giulio for your valuable feedback. I will start working towards finalizing the workbook and the actions required. Saravanan, If you can add me to the review for your workbook, I'd appreciate it. I'm trying to solve a similar problem, of computing THT params for HCI deployments in order to isolate resources between CephOSDs and NovaComputes, and I was also looking to use a Mistral workflow. I'll add you to the review of any related work, if you don't mind. Your proposal to get NUMA info into Ironic [1] helps me there too. Hope to see you at the PTG. Thanks, John [1] https://review.openstack.org/396147 would you be able to join the PTG to help us with the session on the overcloud settings optimization? I will come back on this, as I have not planned for it yet. If it works out, I will update the etherpad. Regards, Saravanan KR On Wed, Jan 11, 2017 at 5:10 AM, Giulio Fidente wrote: On 01/04/2017 09:13 AM, Saravanan KR wrote: Hello, The aim of this mail is to ease the DPDK deployment with TripleO. I would like to see if the approach of deriving THT parameter based on introspection data, with a high level input would be feasible. Let me brief on the complexity of certain parameters, which are rel
Re: [openstack-dev] [tripleo] Mistral Workflow for deriving THT parameters
On 01/24/2017 12:45 AM, Saravanan KR wrote: Thanks Giulio for adding it to PTG discussion pad. I am not yet sure of my presence in PTG. Hoping that things will fall in place soon. We have spent a considerable about of time in moving from static roles to composable roles. If we are planning to introduce static profiles, then after a while we will end up with the same problem, and definitely, it actually depends on how the features will be composed on a role. Looking forward. Hi Saravanan, I wasn't planning to introduce static profiles. What's proposed in the spec [1] is for the profiles to be easily composed so I mimicked the composable roles pattern. I will reply to your message from the 23rd with more details and an example. John [1] https://review.openstack.org/#/c/423304/ On Mon, Jan 23, 2017 at 6:25 PM, Giulio Fidente wrote: On 01/23/2017 11:07 AM, Saravanan KR wrote: Thanks John for the info. I am going through the spec in detail. And before that, I had few thoughts about how I wanted to approach this, which I have drafted in https://etherpad.openstack.org/p/tripleo-derive-params. And it is not 100% ready yet, I was still working on it. I've linked this etherpad for the session we'll have at the PTG As of now, there are few differences on top of my mind, which I want to highlight, I am still going through the specs in detail: * Profiles vs Features - Considering a overcloud node as a profiles rather than a node which can host these features, would have limitations to it. For example, if i need a Compute node to host both Ceph (OSD) and DPDK, then the node will have multiple profiles or we have to create a profile like - hci_enterprise_many_small_vms_with_dpdk? The first one is not appropriate and the later is not scaleable, may be something else in your mind? * Independent - The initial plan of this was to be independent execution, also can be added to deploy if needed. * Not to expose/duplicate parameters which are straight forward, for example tuned-profile name should be associated with feature internally, Workflows will decide it. for all of the above, I think we need to decide if we want the optimizations to be profile-based and gathered *before* the overcloud deployment is started or if we want to set these values during the overcloud deployment basing on the data we have at runtime seems like both approaches have pros and cons and this would be a good conversation to have with more people at the PTG * And another thing, which I couldn't get is, where will the workflow actions be defined, in THT or tripleo_common? to me it sounds like executing the workflows before stack creation is started would be fine, at least for the initial phase running workflows from Heat depends on the other blueprint/session we'll have about the WorkflowExecution resource and once that will be available, we could trigger the workflow execution from tht if beneficial The requirements which I thought of, for deriving workflow are: Parameter Deriving workflow should be * independent to run the workflow * take basic parameters inputs, for easy deployment, keep very minimal set of mandatory parameters, and rest as optional parameters * read introspection data from Ironic DB and Swift-stored blob I will add these comments as starting point on the spec. We will work towards bringing down the differences, so that operators headache is reduced to a greater extent. thanks -- Giulio Fidente GPG KEY: 08D733BA __ 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] Mistral Workflow for deriving THT parameters
On 01/11/2017 11:34 PM, Saravanan KR wrote: Thanks John, I would really appreciate if you could tag me on the reviews. I will do the same for mine too. Hi Saravanan, Following up on this, have a look at the OS::Mistral::WorflowExecution Heat spec [1] to trigger Mistral workflows. I'm hoping to use it for deriving THT parameters for optimal resource isolation in HCI deployments as I mentioned below. I have a spec [2] which describes the derivation of the values, but this is provided as an example for the more general problem of capturing the rules used to derive the values so that deployers may easily apply them. Thanks, John [1] OS::Mistral::WorflowExecution https://review.openstack.org/#/c/267770/ [2] TripleO Performance Profiles https://review.openstack.org/#/c/423304/ On Wed, Jan 11, 2017 at 8:03 PM, John Fulton wrote: On 01/11/2017 12:56 AM, Saravanan KR wrote: Thanks Emilien and Giulio for your valuable feedback. I will start working towards finalizing the workbook and the actions required. Saravanan, If you can add me to the review for your workbook, I'd appreciate it. I'm trying to solve a similar problem, of computing THT params for HCI deployments in order to isolate resources between CephOSDs and NovaComputes, and I was also looking to use a Mistral workflow. I'll add you to the review of any related work, if you don't mind. Your proposal to get NUMA info into Ironic [1] helps me there too. Hope to see you at the PTG. Thanks, John [1] https://review.openstack.org/396147 would you be able to join the PTG to help us with the session on the overcloud settings optimization? I will come back on this, as I have not planned for it yet. If it works out, I will update the etherpad. Regards, Saravanan KR On Wed, Jan 11, 2017 at 5:10 AM, Giulio Fidente wrote: On 01/04/2017 09:13 AM, Saravanan KR wrote: Hello, The aim of this mail is to ease the DPDK deployment with TripleO. I would like to see if the approach of deriving THT parameter based on introspection data, with a high level input would be feasible. Let me brief on the complexity of certain parameters, which are related to DPDK. Following parameters should be configured for a good performing DPDK cluster: * NeutronDpdkCoreList (puppet-vswitch) * ComputeHostCpusList (PreNetworkConfig [4], puppet-vswitch) (under review) * NovaVcpuPinset (puppet-nova) * NeutronDpdkSocketMemory (puppet-vswitch) * NeutronDpdkMemoryChannels (puppet-vswitch) * ComputeKernelArgs (PreNetworkConfig [4]) (under review) * Interface to bind DPDK driver (network config templates) The complexity of deciding some of these parameters is explained in the blog [1], where the CPUs has to be chosen in accordance with the NUMA node associated with the interface. We are working a spec [2], to collect the required details from the baremetal via the introspection. The proposal is to create mistral workbook and actions (tripleo-common), which will take minimal inputs and decide the actual value of parameters based on the introspection data. I have created simple workbook [3] with what I have in mind (not final, only wireframe). The expected output of this workflow is to return the list of inputs for "parameter_defaults", which will be used for the deployment. I would like to hear from the experts, if there is any drawbacks with this approach or any other better approach. hi, I am not an expert, I think John (on CC) knows more but this looks like a good initial step to me. once we have the workbook in good shape, we could probably integrate it in the tripleo client/common to (optionally) trigger it before every deployment would you be able to join the PTG to help us with the session on the overcloud settings optimization? https://etherpad.openstack.org/p/tripleo-ptg-pike -- Giulio Fidente GPG KEY: 08D733BA __ 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] Mistral Workflow for deriving THT parameters
On 01/11/2017 12:56 AM, Saravanan KR wrote: Thanks Emilien and Giulio for your valuable feedback. I will start working towards finalizing the workbook and the actions required. Saravanan, If you can add me to the review for your workbook, I'd appreciate it. I'm trying to solve a similar problem, of computing THT params for HCI deployments in order to isolate resources between CephOSDs and NovaComputes, and I was also looking to use a Mistral workflow. I'll add you to the review of any related work, if you don't mind. Your proposal to get NUMA info into Ironic [1] helps me there too. Hope to see you at the PTG. Thanks, John [1] https://review.openstack.org/396147 would you be able to join the PTG to help us with the session on the overcloud settings optimization? I will come back on this, as I have not planned for it yet. If it works out, I will update the etherpad. Regards, Saravanan KR On Wed, Jan 11, 2017 at 5:10 AM, Giulio Fidente wrote: On 01/04/2017 09:13 AM, Saravanan KR wrote: Hello, The aim of this mail is to ease the DPDK deployment with TripleO. I would like to see if the approach of deriving THT parameter based on introspection data, with a high level input would be feasible. Let me brief on the complexity of certain parameters, which are related to DPDK. Following parameters should be configured for a good performing DPDK cluster: * NeutronDpdkCoreList (puppet-vswitch) * ComputeHostCpusList (PreNetworkConfig [4], puppet-vswitch) (under review) * NovaVcpuPinset (puppet-nova) * NeutronDpdkSocketMemory (puppet-vswitch) * NeutronDpdkMemoryChannels (puppet-vswitch) * ComputeKernelArgs (PreNetworkConfig [4]) (under review) * Interface to bind DPDK driver (network config templates) The complexity of deciding some of these parameters is explained in the blog [1], where the CPUs has to be chosen in accordance with the NUMA node associated with the interface. We are working a spec [2], to collect the required details from the baremetal via the introspection. The proposal is to create mistral workbook and actions (tripleo-common), which will take minimal inputs and decide the actual value of parameters based on the introspection data. I have created simple workbook [3] with what I have in mind (not final, only wireframe). The expected output of this workflow is to return the list of inputs for "parameter_defaults", which will be used for the deployment. I would like to hear from the experts, if there is any drawbacks with this approach or any other better approach. hi, I am not an expert, I think John (on CC) knows more but this looks like a good initial step to me. once we have the workbook in good shape, we could probably integrate it in the tripleo client/common to (optionally) trigger it before every deployment would you be able to join the PTG to help us with the session on the overcloud settings optimization? https://etherpad.openstack.org/p/tripleo-ptg-pike -- Giulio Fidente GPG KEY: 08D733BA __ 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] [spec] Feedback wanted on TripleO Tendrl Integration Proposal
Hello, I'd like to post a link to a blueprint I am hoping will be discussed at the upcoming summit. Please share any comments you may have in the Gerrit review for the spec. https://review.openstack.org/#/c/387631/ https://blueprints.launchpad.net/tripleo/+spec/tripleo-tendrl-integration This may, as shardy points out, lead to a broader discussion about how TripleO should handle interfacing with external tools. Thanks, John __ 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
