Re: [openstack-dev] [puppet][tripleo] Add ganesha puppet module
On 06/14/2017 01:09 AM, Alex Schultz wrote: On Mon, Jun 12, 2017 at 4:27 AM, Jan Provaznik <jprov...@redhat.com> wrote: Hi, we would like to use nfs-ganesha for accessing shares on ceph storage cluster[1]. There is not yet a puppet module which would install and configure nfs-ganesha service. So to be able to set up nfs-ganesha with TripleO, I'd like to create a new ganesha puppet module under openstack-puppet umbrella unless there is a disagreement? I don't have any particular issue with it. Feel free to follow the guide[0] Thanks, -Alex [0] https://docs.openstack.org/developer/puppet-openstack-guide/new-module.html Great, I've submitted a patch for adding this project: https://review.openstack.org/#/c/474474/ Thanks, Jan __ 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] [puppet][tripleo] Add ganesha puppet module
Hi, we would like to use nfs-ganesha for accessing shares on ceph storage cluster[1]. There is not yet a puppet module which would install and configure nfs-ganesha service. So to be able to set up nfs-ganesha with TripleO, I'd like to create a new ganesha puppet module under openstack-puppet umbrella unless there is a disagreement? Thanks, Jan [1] https://blueprints.launchpad.net/tripleo/+spec/nfs-ganesha __ 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][manila] Ganesha deployment
On Tue, Apr 11, 2017 at 9:45 PM, Ben Nemec <openst...@nemebean.com> wrote: > > > On 04/11/2017 02:00 PM, Giulio Fidente wrote: >> >> On Tue, 2017-04-11 at 16:50 +0200, Jan Provaznik wrote: >>> >>> On Mon, Apr 10, 2017 at 6:55 PM, Ben Nemec <openst...@nemebean.com> >>> wrote: >>>> >>>> On 04/10/2017 03:22 AM, Jan Provaznik wrote: >>>> Well, on second thought it might be possible to make the Storage >>>> network >>>> only routable within overcloud Neutron by adding a bridge mapping >>>> for the >>>> Storage network and having the admin configure a shared Neutron >>>> network for >>>> it. That would be somewhat more secure since it wouldn't require >>>> the >>>> Storage network to be routable by the world. I also think this >>>> would work >>>> today in TripleO with no changes. >>>> >>> >>> This sounds interesting, I was searching for more info how bridge >>> mapping should be done in this case and how specific setup steps >>> should look like, but the process is still not clear to me, I would >>> be >>> grateful for more details/guidance with this. >> >> >> I think this will be represented in neutron as a provider network, >> which has to be created by the overcloud admin, after the overcloud >> deployment is finished >> >> While based on Kilo, this was one of the best docs I could find and it >> includes config examples [1] >> >> It assumes that the operator created a bridge mapping for it when >> deploying the overcloud >> >>>> I think the answer here will be the same as for vanilla Ceph. You >>>> need to >>>> make the network routable to instances, and you'd have the same >>>> options as I >>>> discussed above. >>>> >>> >>> Yes, it seems that using the mapping to provider network would solve >>> the existing problem when using ceph directly and when using ganesha >>> servers in future (it would be just matter of to which network is >>> exposed). >> >> >> +1 >> >> regarding the composability questions, I think this represents a >> "composable HA" scenario where we want to manage a remote service with >> pacemaker using pacemaker-remote >> >> yet at this stage I think we want to add support for new services by >> running them in containers first (only?) and pacemaker+containers is >> still a work in progress so there aren't easy answers >> >> containers will have access to the host networks though, so the case >> for a provider network in the overcloud remains valid >> >> 1. https://docs.openstack.org/kilo/networking-guide/scenario_provider_o >> vs.html >> > > I think there are three major pieces that would need to be in place to have > a storage provider network: > > 1) The storage network must be bridged in the net-iso templates. I don't > think our default net-iso templates do that, but there are examples of > bridged networks in them: > https://github.com/openstack/tripleo-heat-templates/blob/master/network/config/multiple-nics/compute.yaml#L121 > For the rest of the steps I will assume the bridge was named br-storage. > > 2) Specify a bridge mapping when deploying the overcloud. The environment > file would look something like this (datacentre is the default value, so I'm > including it too): > > parameter_defaults: > NeutronBridgeMappings: 'datacentre:br-ex,storage:br-storage' > > 3) Create a provider network after deployment as described in the link > Giulio provided. The specific command will depend on the network > architecture, but it would need to include "--provider:physical_network > storage". > > We might need to add the ability to do 3 as part of the deployment, > depending what is needed for the Ganesha deployment itself. We've typically > avoided creating network resources like this in the deployment because of > the huge variations in what people want, but this might be an exceptional > case since the network will be a required part of the overcloud. > > Thank you both for your help, based on steps suggested above I was able to mount ceph volume in user instance when Overcloud was deployed with net-iso with net-single-nic-with-vlans (which is the easiest one I can deploy in my virtualenv). For net-single-nic-with-vlans I skipped creation of additional bridge (since single bridge is used for all networks in this case) and deployed OC as usually, then I configured networking: neutron net-create storage --s
Re: [openstack-dev] [tripleo][manila] Ganesha deployment
On Mon, Apr 10, 2017 at 6:55 PM, Ben Nemec <openst...@nemebean.com> wrote: > I'm not really an expert on composable roles so I'll leave that to someone > else, but see my thoughts inline on the networking aspect. > > On 04/10/2017 03:22 AM, Jan Provaznik wrote: >> >> 2) define a new VIP (for IP failover) and 2 networks for NfsStorage role: >> a) a frontend network between users and ganesha servers (e.g. >> NfsNetwork name), used by tenants to mount nfs shares - this network >> should be accessible from user instances. > > > Adding a new network is non-trivial today, so I think we want to avoid that > if possible. Is there a reason the Storage network couldn't be used for > this? That is already present on compute nodes by default so it would be > available to user instances, and it seems like the intended use of the > Storage network matches this use case. In a Ceph deployment today that's > the network which exposes data to user instances. > Access to the ceph public network (StorageNetwork) is a big privilege (from discussing this with ceph team), bigger than accessing only ganesha nfs servers, so StorageNetwork should be exposed only when really necessary. >> b) a backend network between ganesha servers ans ceph cluster - >> this could just map to the existing StorageNetwork I think. > > > This actually sounds like a better fit for StorageMgmt to me. It's > non-user-facing storage communication, which is what StorageMgmt is used for > in the vanilla Ceph case. > If StorageMgmt is used for replication and internal ceph nodes communication, I wonder if it's not too permissive access? Ganesha servers should need access ti ceph public network only. >> What i'm not sure at all is how network definition should look like. >> There are following Overcloud deployment options: >> 1) no network isolation is used - then both direct ceph mount and >> mount through ganesha should work because StorageNetwork and >> NfsNetwork are accessible from user instances (there is no restriction >> in accessing other networks it seems). > > > There are no other networks without network-isolation. Everything runs over > the provisioning network. The network-isolation templates should mostly > handle this for you though. > >> 2) network isolation is used: >> a) ceph is used directly - user instances need access to the ceph >> public network (which is StorageNetwork in Overcloud) - how should I >> enable access to this network? I filled a bug for this deployment >> variant here [3] > > > So does this mean that the current manila implementation is completely > broken in network-isolation? If so, that's rather concerning. > This affects deployments of manila with internal (=deployed by TripleO) ceph backend. > If I'm understanding correctly, it sounds like what needs to happen is to > make the Storage network routable so it's available from user instances. > That's not actually something TripleO can do, it's an underlying > infrastructure thing. I'm not sure what the security implications of it are > either. > > Well, on second thought it might be possible to make the Storage network > only routable within overcloud Neutron by adding a bridge mapping for the > Storage network and having the admin configure a shared Neutron network for > it. That would be somewhat more secure since it wouldn't require the > Storage network to be routable by the world. I also think this would work > today in TripleO with no changes. > This sounds interesting, I was searching for more info how bridge mapping should be done in this case and how specific setup steps should look like, but the process is still not clear to me, I would be grateful for more details/guidance with this. > Alternatively I guess you could use ServiceNetMap to move the public Ceph > traffic to the public network, which has to be routable. That seems like it > might have a detrimental effect on the public network's capacity, but it > might be okay in some instances. > I would rather avoid this option (both because of network traffic and because of exposing ceph public network to everybody). >> b) ceph is used through ganesha - user instances need access to >> ganesha servers (NfsNetwork in previous paragraph) - how should I >> enable access to this network? > > > I think the answer here will be the same as for vanilla Ceph. You need to > make the network routable to instances, and you'd have the same options as I > discussed above. > Yes, it seems that using the mapping to provider network would solve the existing problem when using ceph directly and when using ganesha servers in future (it would be just matter of to which network is exposed). >>
[openstack-dev] [tripleo][manila] Ganesha deployment
Hi, TripleO currently supports deploying CephFS and it can be used as a backend for Manila service, so user can mount ceph shares by using either ceph kernel driver or ceph-fuse on his side. There is an ongoing ganesha-nfs project [1] which can be used as a proxy when accessing CephFS. The benefit is that user then interacts only with ganesha server and mounts shares from this server using NFS protocol. And Manila will soon support both variants of ceph backend : 1) ceph is used directly (what we support now) user instance <-- ceph protocol --> ceph cluster 2) ceph is used through ganesha server (what we don't support yet but we would like) user instance <-- NFS protocol --> ganesha server <-- ceph protocol --> ceph cluster We would like to enable both deployment options in TripleO and I wonder how ganesha deployment should look like. Prerequisities are: - use of ganesha servers will be optional - operators can still choose to use ceph directly, ideally it should be possible to deploy Manila both with direct ceph and ganesha backends - ganesha servers should not run on controller nodes (e.g. collocated with manila-share service) because of data traffic, ideally ganesha servers should be dedicated (which is probably not a probablem with composable services) - ganesha servers will probably use active/passive HA model and will be managed by pacemaker+corosync - AFAIK detailed HA architecture is not specified yet and is still in progress by ganesha folks. I imagine that (extremely simplified) setup would look something like this from TripleO point of view: 1) define a new role (e.g. NfsStorage) which represents ganesha servers 2) define a new VIP (for IP failover) and 2 networks for NfsStorage role: a) a frontend network between users and ganesha servers (e.g. NfsNetwork name), used by tenants to mount nfs shares - this network should be accessible from user instances. b) a backend network between ganesha servers ans ceph cluster - this could just map to the existing StorageNetwork I think. 3) pacemaker and ganesha setup magic happens - I wonder if the existing puppet pacemaker modules could be used for setting up another pacemaker cluster on dedicated ganesha nodes? It seems the long term plan is to switch to ceph-ansible for ceph setup in TripleO. So should be the whole HA setup of ganesha server delegated to the ceph ansible isntead? What i'm not sure at all is how network definition should look like. There are following Overcloud deployment options: 1) no network isolation is used - then both direct ceph mount and mount through ganesha should work because StorageNetwork and NfsNetwork are accessible from user instances (there is no restriction in accessing other networks it seems). 2) network isolation is used: a) ceph is used directly - user instances need access to the ceph public network (which is StorageNetwork in Overcloud) - how should I enable access to this network? I filled a bug for this deployment variant here [3] b) ceph is used through ganesha - user instances need access to ganesha servers (NfsNetwork in previous paragraph) - how should I enable access to this network? The ultimate (and future) plan is to deploy ganesha-nfs in VMs (which will run in Overcloud, probably managed by manila ceph driver), in this deployment mode a user should have access to ganesha servers and only ganesha server VMs should have access to ceph public network. Ganesha VMs would run in a separate tenant so I wonder if it's possible to manage access to the ceph public network (StorageNetwork in Overcloud) on per-tenant level? Any thoughts and hints? Thanks, Jan [1] https://github.com/nfs-ganesha/nfs-ganesha/wiki [2] https://github.com/ceph/ceph-ansible/tree/master/roles/ceph-nfs [3] https://bugs.launchpad.net/tripleo/+bug/1680749 __ 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] Upgrade plans for RDO Manager - Brainstorming
On 09/09/2015 05:34 PM, Zane Bitter wrote: On 24/08/15 15:12, Emilien Macchi wrote: Hi, So I've been working on OpenStack deployments for 4 years now and so far RDO Manager is the second installer -after SpinalStack [1]- I'm working on. SpinalStack already had interested features [2] that allowed us to upgrade our customer platforms almost every months, with full testing and automation. Now, we have RDO Manager, I would be happy to share my little experience on the topic and help to make it possible in the next cycle. For that, I created an etherpad [3], which is not too long and focused on basic topics for now. This is technical and focused on Infrastructure upgrade automation. Feel free to continue discussion on this thread or directly in the etherpad. [1] http://spinalstack.enovance.com [2] http://spinalstack.enovance.com/en/latest/dev/upgrade.html [3] https://etherpad.openstack.org/p/rdo-manager-upgrades I added some notes on the etherpad, but I think this discussion poses a larger question: what is TripleO? Why are we using Heat? Because to me the major benefit of Heat is that it maintains a record of the current state of the system that can be used to manage upgrades. And if we're not going to make use of that - if we're going to determine the state of the system by introspecting nodes and update it by using Ansible scripts without Heat's knowledge, then we probably shouldn't be using Heat at all. I'm not saying that to close off the option - I think if Heat is not the best tool for the job then we should definitely consider other options. And right now it really is not the best tool for the job. Adopting Puppet (which was a necessary choice IMO) has meant that the responsibility for what I call "software orchestration"[1] is split awkwardly between Puppet and Heat. For example, the Puppet manifests are baked in to images on the servers, so Heat doesn't know when they've changed and can't retrigger Puppet to update the configuration when they do. We're left trying to reverse-engineer what is supposed to be a declarative model from the workflow that we want for things like updates/upgrades. That said, I think there's still some cause for optimism: in a world where every service is deployed in a container and every container has its own Heat SoftwareDeployment, the boundary between Heat's responsibilities and Puppet's would be much clearer. The deployment could conceivably fit a declarative model much better, and even offer a lot of flexibility in which services run on which nodes. We won't really know until we try, but it seems distinctly possible to aspire toward Heat actually making things easier rather than just not making them too much harder. And there is stuff on the long-term roadmap that could be really great if only we had time to devote to it - for example, as I mentioned in the etherpad, I'd love to get Heat's user hooks integrated with Mistral so that we could have fully-automated, highly-available (in a hypothetical future HA undercloud) live migration of workloads off compute nodes during updates. TBH I don't expect that using containers will significantly simplify (or make clearer) the upgrade process. It would work nicely if upgrade would mean just replacing one container with another (where a container is represented by a heat resource). But I'm convinced that a container replacement will actually involve a complex workflow of actions which have to be done before and after. In the meantime, however, I do think that we have all the tools in Heat that we need to cobble together what we need to do. In Liberty, Heat supports batched rolling updates of ResourceGroups, so we won't need to use user hooks to cobble together poor-man's batched update support any more. We can use the user hooks for their intended purpose of notifying the client when to live-migrate compute workloads off a server that is Unfortunately rolling_updates supports only "pause time" between update batches, so if any workflow would be needed between batches (e.g. pause before next batch until user validates that previous batch update was successful), we still have to use user hooks. But I guess adding hooks support to rolling_updates wouldn't be too difficult. about to upgraded. The Heat templates should already tell us exactly which services are running on which nodes. We can trigger particular software deployments on a stack update with a parameter value change (as we already do with the yum update deployment). For operations that happen in isolation on a single server, we can model them as SoftwareDeployment resources within the individual server templates. For operations that are synchronised across a group of servers (e.g. disabling services on the controller nodes in preparation for a DB migration) we can model them as a SoftwareDeploymentGroup resource in the parent template. And for chaining multiple sequential operations (e.g. disable services, migrate database, enable
Re: [openstack-dev] [TripleO] Releasing tripleo-common on PyPI
On 09/09/2015 12:15 PM, Dougal Matthews wrote: Hi, The tripleo-common library appears to be registered or PyPI but hasn't yet had a release[1]. I am not familiar with the release process - what do we need to do to make sure it is regularly released with other TripleO packages? We will also want to do something similar with the new python-tripleoclient which doesn't seem to be registered on PyPI yet at all. Thanks, Dougal [1]: https://pypi.python.org/pypi/tripleo-common Hi Dougal, thanks for moving this forward. I've never finished the release process upstream, there was no interest/consumer of this lib upstream as UI/CLI decided to use midstream. I'm excited to see this is changing now. Jan __ 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] [Puppet] Package updates strategy
On 05/28/2015 10:25 AM, Martin Mágr wrote: On 05/28/2015 09:35 AM, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Isn't running Puppet with 'ensure = latest' enough? If packaging is correct all dependencies which will require update will be updated together with packages updated by Puppet. Am I missing something or the goal here is to update all packages? Yes - the goal so to update all packages (so puppet only is not sufficient because it will not take care of packages which are not listed in puppet modules). __ 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] [Puppet] Package updates strategy
On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit that this approach fails to take into account the complex ballet of service restarts required to update OpenStack services. (/me shakes fist at OpenStack services.) And furthermore, that the Puppet manifests already encode the necessary relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be doing the Wrong Thing by Puppet if we changed this stuff from under it. The problem of course is that neither Puppet nor yum/apt has a view of the entire system. Yum doesn't know about the relationships between services and Puppet doesn't know about all of the _other_ packages that they depend on. One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. Maybe this could be handled at the packaging stage by reving the package version when there is a known fix in a low-level library, thus triggering a service restart in the puppet phase. My concern is that then e.g. libc update would mean repackaging (bumping version) of zillion of other packages, also zillion of packages would be downloaded/upgraded on each system because of a new package version. I think that providing user a manual (script) way to restart services after update would be sufficient solution (though not so sophisticated). Jan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Core reviewer update proposal
On 05/05/2015 01:57 PM, James Slagle wrote: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. +1 Congrats! Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | I've shifted my focus in a slightly different area, although I plan to contribute to some parts of TripleO I don't have overall overview of all major parts of the project which is necessary for core reviews - feel free to remove me from the core team. Jan __ 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][Tuskar] Common library for shared code
On 03/10/2015 05:53 PM, James Slagle wrote: On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník jprov...@redhat.com wrote: Hi, it would make sense to have a library for the code shared by Tuskar UI and CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is just a thing wrapper for Tuskar API). There are various actions which consist from more that a single API call to an openstack service, to give some examples: - nodes registration - for loading a list of nodes from a user defined file, this means parsing a CSV file and then feeding Ironic with this data - decommission a resource node - this might consist of disabling monitoring/health checks on this node, then gracefully shut down the node - stack breakpoints - setting breakpoints will allow manual inspection/validation of changes during stack-update, user can then update nodes one-by-one and trigger rollback if needed I agree something is needed. In addition to the items above, it's much of the post deployment steps from devtest_overcloud.sh. I'd like to see that be consumable from the UI and CLI. I think we should be aware though that where it makes sense to add things to os-cloud-config directly, we should just do that. Yes, actually I think most of the devtest_overcloud content fits os-cloud-config (and IIRC for this purpose os-cloud-config was created). It would be nice to have a place (library) where the code could live and where it could be shared both by web UI and CLI. We already have os-cloud-config [1] library which focuses on configuring OS cloud after first installation only (setting endpoints, certificates, flavors...) so not all shared code fits here. It would make sense to create a new library where this code could live. This lib could be placed on Stackforge for now and it might have very similar structure as os-cloud-config. And most important... what is the best name? Some of ideas were: - tuskar-common I agree with Dougal here, -1 on this. - tripleo-common - os-cloud-management - I like this one, it's consistent with the os-cloud-config naming I'm more or less happy with any of those. However, If we wanted something to match the os-*-config pattern we might could go with: - os-management-config - os-deployment-config Well, the scope of this lib will be beyond configuration of a cloud so having -config in the name is not ideal. Based on feedback in this thread I tend to go ahead with os-cloud-management and unless someone rises an objection here now, I'll ask infra team what is the process of adding the lib to stackforge. Jan __ 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] dns for overcloud nodes
Hi, by default we don't set nameserver when setting up neutron subnet used by overcloud nodes, then nameserver points to the machine where undercloud's dnsmasq is running. I wonder if we should not change *default* devtest setup to allow dns resolving not only for local network but for internet? Proper DNS resolving is handy e.g. for package update scenario. This would mean: a) set explicitly nameserver when configuring neutron subnet (as it's done for network in overcloud [1]) or b) set forwarding dns server for dnsmasq [2] Any thoughts? Thanks, Jan [1]: https://github.com/openstack/tripleo-incubator/blob/master/scripts/setup-neutron#L53 [2]: https://github.com/openstack/neutron/blob/master/etc/dhcp_agent.ini#L67 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Use MariaDB by default on Fedora
On 06/25/2014 06:58 PM, Giulio Fidente wrote: On 06/16/2014 11:14 PM, Clint Byrum wrote: Excerpts from Gregory Haynes's message of 2014-06-16 14:04:19 -0700: Excerpts from Jan Provazník's message of 2014-06-16 20:28:29 +: Hi, MariaDB is now included in Fedora repositories, this makes it easier to install and more stable option for Fedora installations. Currently MariaDB can be used by including mariadb (use mariadb.org pkgs) or mariadb-rdo (use redhat RDO pkgs) element when building an image. What do you think about using MariaDB as default option for Fedora when running devtest scripts? (first, I believe Jan means that MariaDB _Galera_ is now in Fedora) I think so too. Id like to give this a try. This does start to change us from being a deployment of openstck to being a deployment per distro but IMO thats a reasonable position. Id also like to propose that if we decide against doing this then these elements should not live in tripleo-image-elements. I'm not so sure I agree. We have lio and tgt because lio is on RHEL but everywhere else is still using tgt IIRC. However, I also am not so sure that it is actually a good idea for people to ship on MariaDB since it is not in the gate. As it diverges from MySQL (starting in earnest with 10.x), there will undoubtedly be subtle issues that arise. So I'd say having MariaDB get tested along with Fedora will actually improve those users' test coverage, which is a good thing. I am favourable to the idea of switching to mariadb for fedora based distros. Currently the default mysql element seems to be switching [1], yet for ubuntu/debian only, from the percona provided binary tarball of mysql to the percona provided packaged version of mysql. In theory we could further update it to use percona provided packages of mysql on fedora too but I'm not sure there is much interest in using that combination where people gets mariadb and galera from the official repos. IIRC fedora packages for percona xtradb cluster are not provided (unless something has changed recently). Using different defaults (and even drop support for one or another, depending on the distro), seems to me a better approach in the long term. Are there contrary opinions? 1. https://review.openstack.org/#/c/90134 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] pacemaker management tools
On 06/12/2014 12:17 AM, Gregory Haynes wrote: The issue is that distributions supported in TripleO provide different tools for managing Pacemaker. Ubuntu/Debian provides crmsh, Fedora/RHEL provides pcs, OpenSuse provides both. I didn't find packages for all our distros for any of the tools. Also if there is a third-party repo providing packages for various distros, adding dependency on an untrusted third-party repo might be a problem for some users. Although it's a little bit annoying, I think we will end up with managing commands for both config tools, a resource creation sample: if $USE_PCS;then crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 params ip=192.168.122.120 cidr_netmask=32 op monitor interval=30s else pcs resource create ClusterIP IPaddr2 ip=192.168.0.120 cidr_netmask=32 fi This seems like a reasonable solution if we can ensure that we have CI for both branches of the installation. This is a big issue with our current mariadb/percona installation and it sounds like were heading down the same path here. With mariadb/percona it's slightly different as these are separate elements and each of them works on all distros. With mariadb I was waiting until galera server is merged into Fedora (which already is), so it's a good time now to make it default for Fedora setup (a patch for this will be submitted soon). If we can make USE_PCS directly dependent on the installed distro that would be sufficient (CI for each distro would take care of the different branches) but this gets a bit more complicated if you want to split crm and pcs out into different elements (like in mariadb vs percona)... Yes, usage of pcs is directly dependent on distro. Pcs/crm wouldn't be splitted into separate elements, it's just about calling 2 different commands in an os-refresh-config script depending on distribution (so we are sure both are tested). Jan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] HAProxy and Keystone setup (in Overcloud)
On 04/28/2014 10:05 PM, Jay Dobies wrote:
We may want to consider making use of Heat outputs for this.
This was my first thought as well. stack-show returns a JSON document
that would be easy enough to parse through instead of having it in two
places.
Rather than assuming hard coding, create an output on the overcloud
template that is something like 'keystone_endpoint'. It would look
something like this:
Outputs:
keystone_endpoint:
Fn::Join:
- ''
- - http://;
- {Fn::GetAtt: [ haproxy_node, first_ip ]} # fn select and yada
- :
- {Ref: KeystoneEndpointPort} # thats a parameter
- /v2.0
These are then made available via heatclient as stack.outputs in
'stack-show'.
That way as we evolve new stacks that have different ways of controlling
the endpoints (LBaaS anybody?) we won't have to change os-cloud-config
for each one.
The output endpoint list would be quite long, it would have to contain
full list of all possible services (even if a service is not included in
an image) + SSL URI for each port.
It might be better to get haproxy ports from template params (which
should be available as stack.params) and define only virtual IP in
stack.ouputs, then build endpoint URI in os-cloud-config. I'm not sure
if we would have to change os-cloud-config for LBaaS or not. My first
thought was that VIP and port are only bits which should vary, so
resulting URI should be same in both cases.
2) do Keystone setup from inside Overcloud:
Extend keystone element, steps done in init-keystone script would be
done in keystone's os-refresh-config script. This script would have to
be called only on one of nodes in cluster and only once (though we
already do similar check for other services - mysql/rabbitmq, so I don't
think this is a problem). Then this script can easily get list of
haproxy ports from heat metadata. This looks like more attractive option
to me - it eliminates an extra post-create config step.
Things that can be done from outside the cloud, should be done from
outside the cloud. This helps encourage the separation of concerns and
also makes it simpler to reason about which code is driving the cloud
versus code that is creating the cloud.
Related to Keystone setup is also the plan around keys/cert setup
described here:
http://lists.openstack.org/pipermail/openstack-dev/2014-March/031045.html
But I think this plan would remain same no matter which of the options
above would be used.
What do you think?
Jan
___
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] reviewer update march [additional cores]
On 04/08/2014 01:50 AM, Robert Collins wrote: tl;dr: 3 more core members to propose: bnemec greghaynes jdon +1 to all Jan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements
On 01/07/2014 09:01 PM, James Slagle wrote: Hi, I'd like to discuss some possible ways we could install the OpenStack components from packages in tripleo-image-elements. As most folks are probably aware, there is a fork of tripleo-image-elements called tripleo-puppet-elements which does install using packages, but it does so using Puppet to do the installation and for managing the configuration of the installed components. I'd like to kind of set that aside for a moment and just discuss how we might support installing from packages using tripleo-image-elements directly and not using Puppet. One idea would be to add support for a new type (or likely 2 new types: rpm and dpkg) to the source-repositories element. source-repositories already knows about the git, tar, and file types, so it seems somewhat natural to have additional types for rpm and dpkg. A complication with that approach is that the existing elements assume they're setting up everything from source. So, if we take a look at the nova element, and specifically install.d/74-nova, that script does stuff like install a nova service, adds a nova user, creates needed directories, etc. All of that wouldn't need to be done if we were installing from rpm or dpkg, b/c presumably the package would take care of all that. We could fix that by making the install.d scripts only run if you're installing a component from source. In that sense, it might make sense to add a new hook, source-install.d and only run those scripts if the type is a source type in the source-repositories configuration. We could then have a package-install.d to handle the installation from the packages type. The install.d hook could still exist to do things that might be common to the 2 methods. Thoughts on that approach or other ideas? I'm currently working on a patchset I can submit to help prove it out. But, I'd like to start discussion on the approach now to see if there are other ideas or major opposition to that approach. Hi James, I think it would be really nice to be able install openstack+deps from packages and many users (and cloud providers) would appreciate it. Among other things, with packages provided by a distro you get more stability in compare to installing openstack from git repos and fetching newest possible dependencies from pypi. In a real deployment setup I don't want to use more-than-necessary newer packages/dependencies when building images - taking an example from last days I wouldn't have to bother with newer pip package which breaks image building. Jan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tripleo] Core reviewer update Dec
On 12/04/2013 08:12 AM, Robert Collins wrote: And the 90 day not-active-enough status: | jprovazn **| 220 5 10 7 177.3% |2 ( 9.1%) | |jomara ** | 210 2 4 15 1190.5% |2 ( 9.5%) | |mtaylor **| 173 6 0 8 847.1% |0 ( 0.0%) | | jtomasek **| 100 0 2 8 10 100.0% |1 ( 10.0%) | |jcoufal **| 53 1 0 1 320.0% |0 ( 0.0%) | Jan, Jordan, Martyn, Jiri and Jaromir are still actively contributing to TripleO and OpenStack, but I don't think they are tracking / engaging in the code review discussions enough to stay in -core: I'd be delighted if they want to rejoin as core - as we discussed last time, after a shorter than usual ramp up period if they get stuck in. I will put more attention to reviews in future. Only a nit, it's quite a challenge to find something to review - most of the mornings I check pending patches everything is already reviewed ;). Jan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
