Re: [openstack-dev] [puppet] Ubuntu problems + Help needed
Some pointers for perusal as to the observed problems would be helpful, Thanks! On Wed, Dec 20, 2017 at 11:09 AM Chuck Short <zul...@gmail.com> wrote: > Hi Mohammed, > > I might be able to help where can I find this info? > > Thanks > chuck > > On Wed, Dec 20, 2017 at 12:03 PM, Mohammed Naser <mna...@vexxhost.com> > wrote: > >> Hi everyone, >> >> I'll get right into the point. >> >> At the moment, the Puppet OpenStack modules don't have much >> contributors which can help maintain the Ubuntu support. We deploy on >> CentOS (so we try to get all the fixes in that we can) and there is a >> lot of activity from the TripleO team as well which does their >> deployments on CentOS which means that the CentOS support is very >> reliable and CI is always sought after. >> >> However, starting a while back, we started seeing occasional failures >> with Ubuntu deploys which lead us set the job to non-voting. At the >> moment, the Puppet integration jobs for Ubuntu are always failing >> because of some Tempest issue. This means that with every Puppet >> change, we're wasting ~80 minutes of CI run time for a job that will >> always fail. >> >> We've had a lot of support from the packaging team at RDO (which are >> used in Puppet deployments) and they run our integration before >> promoting packages which makes it helpful in finding issues together. >> However, we do not have that with Ubuntu neither has there been anyone >> who is taking initiative to look and investigate those issues. >> >> I understand that there are users out there who use Ubuntu with Puppet >> OpenStack modules. We need your help to come and try and clear those >> issues out. We'd be more than happy to give assistance to lead you in >> the right way to help fix those issues. >> >> Unfortunately, if we don't have any folks stepping up to resolving >> this, we'll be forced to drop all CI for Ubuntu and make a note to >> users that Ubuntu is not fully tested and hope that as users run into >> issues, they can contribute fixes back (or that someone can work on >> getting Ubuntu gating working again). >> >> Thanks for reading through this, I am quite sad that we'd have to drop >> support for such a major operating system, but there's only so much we >> can do with a much smaller team. >> >> Thank you, >> Mohammed >> >> __ >> 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 > -- Andrew Woodward __ 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] [puppet][puppet-ceph]
On Tue, Sep 5, 2017 at 6:47 AM Mohammed Naser <mna...@vexxhost.com> wrote: > On Tue, Sep 5, 2017 at 4:15 AM, Emil Enemærke <enema...@gmail.com> wrote: > > Hi, > > > > I have stated using the puppet-ceph module for deploying ceph, and have > > noticed a heavy use of exec in fx define 'ceph::osd' > > (https://github.com/openstack/puppet-ceph/blob/master/manifests/osd.pp). > Is > > there a reason for not writing this define as an ensurable type/provider? > > Otherwise I will fork the module an start on rewriting it for a > > type/provider. > > > > Thanks for helping out. I'm happy to see folks using the puppet-ceph > modules! I think the reason why we've relied of the Exec's is purely > historic. If you have a patch that would convert it to an ensurable > type and provider, we'd be more than happy to merge it! > As manser pointed out, the reason for the exec's is purely historic, in that the initial implementation team wasn't comfortable with developing ruby providers given our familiarity at the time. It was easier for us to develop and troubleshoot the execs directly. We'd be more than happy to have reviews to migrate to a ruby implementation If you have any questions, feel free to pop by on #puppet-openstack on freenode > > > > Cheers > > Emil > > > > > __ > > 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 > -- Andrew Woodward __ 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] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
removing the directory include, proposed structure, service config files could simply be /etc/nova/$service.conf We should make per-service config files standard in the upstream themselves, and this is an area where we need to collaborate with Debian as well. At the same time, we should also be thinking about multiple instances support for services (a.k.a cinder-volume) that may run multiple instances but with different config files. Ceph does this quite well with the radosgw service. > > > - /usr/share/doc/packages/openstack-nova/nova.conf.sample > > > > The unmodified sample config from upstream > > > > > > > > - /etc/nova/README > > > > Explaining the configuration structure and where to find the whole > > > > sample config. > > > > > > > > > > From a packaging standpoint it's probably better to provide less and > > > not more default configuration files as the tooling usually has to go > > > an clean this stuff up as they have their own ways of configuring the > > > services. Currently they may align with the existing packaging files > > > or they may completely remove what's provided via packaging and setup > > > their own structure. Speaking from experience, having to cleanup > > > package provided configuration files is a pain[0][1]. > > > > There are not more config files with this proposal. It's the same > > amount, just more possibilities. the nova-dist.conf is already in use > > for RDO and neutron [2]. This would be just used for all services. > > /etc/$service/$service.conf is the usual thing and also read by default > > by oslo.config . The conf.d directory delivered by a package would be > > completly empty. So nothing to cleanup there. > > > > [2] > > > https://github.com/rdo-packages/neutron-distgit/blob/rpm-master/neutron-server.service > > > > > > > > [0] > https://github.com/openstack/puppet-horizon/blob/master/manifests/wsgi/apache.pp#L115-L128 > > > [1] > https://github.com/openstack/puppet-tripleo/blob/master/manifests/ui.pp#L94-L107 > > > > > > > > > > > So starting nova-api would be: > > > > nova-api --config-file /usr/share/nova/nova-dist.conf > > > > --config-file /etc/nova/nova.conf > > > > --config-dir /etc/nova/conf.d/common/ > > > > --config-dir /etc/nova/conf.d/nova-api/ > > > > > > > > > > So from a puppet standpoint we actually go out of our way to default > > > to the python defaults and we may purge all values not explicitly set > > > via puppet. This would break our assumptions around this. I > > > personally do not agree with forcing the *-dist.conf into the loading > > > path as this may also cause issues with unwanted values being injected > > > by packagers. > > > > This is already happening in RDO+neutron. See [2]. So nothing new here. > > > > > The danger for people who use puppet is that we > > > currently expected some values to not be defined in the configuration > > > files thus falling back to the python defaults. If they now get > > > defined in service-dist.conf and we undefine it in service.conf > > > (because that's what we currently configure), the end user is now > > > going to get a value they did not expect or want. > > > > It's not about providing a complete config (which wouldn't work anyway) > > but setting for some values sane defaults. See [3]. > > > > [3] > > > https://github.com/rdo-packages/neutron-distgit/blob/rpm-master/neutron-dist.conf > > > > > > > > > > The order of command line switches (--config-file/--config-dir) is > > > > important here. Also --config-dir is ordering the files. So adding a > > > > config snippet to /etc/nova/conf.d/nova-api/ with > > > > e.g. [DEFAULT]bind_port would override the option from the previous > > > > configs (last found option wins). > > > > > > > > > > This gets complicated to follow and may lead to issues on the user > > > side when ordering is a problem or attempting to debug issues. I think > > > this can lead to more issues than it's solving. > > > > Most services print the complete config when running in debug mode. So > > getting th used config is not complicated. Also adding theses switches > > makes it more explicit when doing e.g. "ps awxu|grep nova-api" because > > you see then what Also knowing which files/dirs are used is just "ps > > awxu|grep $service". > > And afaik oslo.config already loads implicit config files if they are > > present. > > > > > Personally unless this structure is also followed by the deb > > > packaging, I'd prefer not to switch to this as it may lead to even > > > more fragmentation when it comes to trying to configure OpenStack > > > deployed via packages. Has this been requested by an end user to > > > solve a specific problem? What exactly is the problem that's trying > > > to be solved other than trying to allow for two of the same project's > > > services being configured in (currently) conflicting fashions? > > > > See my anwers above. It's not only about different configs for different > > service. > > > > Thanks for the feedback! > > > > Cheers, > > > > Tom > > > > __ > > 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 > > -- Andrew Woodward __ 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] [Fuel] Weekly meeting for 9/29 is canceled
The agenda [0] is empty again this week so the meeting is closed, see you again next week [0] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- Andrew Woodward Mirantis __ 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] [fuel] Meeting for today is canceled
We have nothing slated on the agenda [1] for today, so I'm calling it for the meeting. As usual, if you have anything to discuss, please raise it on the ML or in #fuel. [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- Andrew Woodward Mirantis __ 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] FFE request for Ceph RGW integration
Great to hear, nice work all. On Wed, Sep 14, 2016 at 7:56 AM Giulio Fidente <gfide...@redhat.com> wrote: > On 08/30/2016 06:40 PM, Giulio Fidente wrote: > > Together with Keith we're working on some patches to integrate (via > > puppet-ceph) the deployment of Ceph RGW in TripleO as a composable > > service which can optionally replace SwiftProxy > > > > > > Changes are tracked via blueprint at: > > > > https://blueprints.launchpad.net/tripleo/+spec/ceph-rgw-integration > > > > They should be tagged with the appropriate topic branch, so can be found > > with: > > > > https://review.openstack.org/#/q/topic:bp/ceph-rgw-integration,n,z > > > > > > There is also a [NO MERGE] change which we use to test the above in > > upstream CI: > > > > https://review.openstack.org/#/c/357182/ > > > > > > We'd like to formally request an FFE for this feature. > > > > Thanks for consideration, feedback, help and reviews :) > > a quick update, > > the last submission needed for this feature has been merged today, > thanks to all who helped > > from the RC release it will be possible to use ceph/rgw as a swift > drop-in replacement for those deploying ceph > -- > Giulio Fidente > GPG KEY: 08D733BA | IRC: gfidente > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [puppet] Creating a Cloudkitty Puppet module
Jinx! On Thu, Sep 1, 2016 at 12:09 PM Alex Schultz <aschu...@redhat.com> wrote: > On Thu, Sep 1, 2016 at 12:51 PM, Guillaume Espanel > <guillaume.espa...@objectif-libre.com> wrote: > > Hi! > > > > At the moment, I don't think theres a Puppet module for > > the Cloudkitty rating service. I'd like to start the development > > of this project. > > > > What are you thoughts on the matter? > > > > Sounds good. We've put together some documentation on where to start. > > http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html > > If you have any questions or need help, feel free to visit > #puppet-openstack on freenode. > > Thanks, > -Alex > > > -- > > Guillaume Espanel > > Objectif Libre www.objectif-libre.com > > Infrastructure et Formations Linux > > > > > __ > > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Meeting for Aug - 18 is canceled
The agenda [1] for today's meeting has no items, so I'm calling it for the meeting this week. Please review your action items from last meeting and update the ML if you haven't done so already romcheg to annouunce fuel2 promotion and old fuel CLI removal on ML akscram to send ML about moving cluster_upgrade extension gkibardin to follow up on ML about mcollective config issues xarses will update spec regarding release naming and summarize on ML [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] Puppet OpenStack Application Module
I'd like to propose the creation of a puppet module to make use of Puppet Application orchestrator. This would consist of a Puppet-4 compatible module that would define applications that would wrap the existing modules. This will allow for the establishment of a shared module that is capable of expressing OpenStack applications using the new language schematics in Puppet 4 [1] for multi-node application orchestration. I'd expect that initial testing env would consist of deploying a PE stack, and using docker containers as node primitives. This is necessary until a FOSS deployer component like [2] becomes stable, at which point we can switch to it and use the FOSS PM as well. Once the env is up, I plan to wrap p-o-i profiles to deploy the cloud and launch tempest for functional testing. [1] https://docs.puppet.com/pe/latest/app_orchestration_workflow.html [2] https://github.com/ripienaar/mcollective-choria -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Meeting for today 7/28 is caneled
The meeting agenda is empty for this week's meeting is empty so I'm calling it on the meeting. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Fuel meeting Canceled
Again the agenda [1] is empty again so I'm calling it on the meeting this week. [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] IRC meeting for Jul - 14
The meeting agenda is again empty, so I'm calling the meeting canceled. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Weekly meeting for July 7
There is no agenda on the meeting again this week so I am calling it canceled. Thanks -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Weekly meeting 6/30 Cancled
Nothing is on the agenda this week, so I'm calling to cancel the meeting. If you have anything to discuss. Please come chat in #fuel or add it to the agenda to discuss next week. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel][plugins][ovs]
You can track the fuel version supported by examining the metadata.yaml in the root of the plugin repo. Since there is no stable/7.0 tag the last point before metadata.yaml was changed to 8.0 is https://github.com/openstack/fuel-plugin-ovs/tree/3776734a7b93ac440aa7b2e730d743b8510aac25 You can try building from there but your on your own to get it to work. On Fri, Jun 24, 2016 at 10:33 AM Ankit Chilakapaty -X (achilaka - SRS CONSULTING INC at Cisco) <achil...@cisco.com> wrote: > Hello, > > > > I’m trying to install ovs with dpdk 2.4/2.2 plugin for openstack kilo > mirantis 7.0. I’m not sure if there is a compatible version for that on the > github openstack/fuel-plugin-ovs . If there is one, could you upload the > plugin. > > > > Thanks > > > > > > [image: banner11] > > > > *Ankit Chilakapaty* > > Engineer - IT > > achil...@cisco.com > > Tel: > > *Cisco Systems, Inc.* > > > > > United States > cisco.com > > > > [image: http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think > before you print. > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender by > reply email and delete all copies of this message. > > Please click here > <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for > Company Registration Information. > > > > > > > > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Merge IRC channels
There is also #fuel-devops I never liked having all the channels, so +1 On Fri, Jun 24, 2016 at 4:25 AM Anastasia Urlapova <aurlap...@mirantis.com> wrote: > Vova, > please don't forget merge #fuel-qa into a #fuel > > On Fri, Jun 24, 2016 at 1:55 PM, Vladimir Kozhukalov < > vkozhuka...@mirantis.com> wrote: > >> Nice. #fuel-infra is to merged as well. >> >> Vladimir Kozhukalov >> >> On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova < >> afedor...@mirantis.com> wrote: >> >>> And +1 for #fuel-infra >>> >>> As of now it will be more useful if infra issues related to project will >>> be visible for project developers. We don't have much infra-related traffic >>> on IRC for now, and we will be able to split again if we got it. >>> >>> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov < >>> vkozhuka...@mirantis.com> wrote: >>> >>>> Dear colleagues, >>>> >>>> We have a few IRC channels but the level of activity there is quite low. >>>> >>>> #fuel >>>> #fuel-dev >>>> #fuel-python >>>> #fuel-infra >>>> >>>> My suggestion is to merge all these channels into a single IRC channel >>>> #fuel. >>>> Other #fuel-* channels are to be deprecated. >>>> >>>> What do you think of this? >>>> >>>> >>>> Vladimir Kozhukalov >>>> >>>> >>>> __ >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Aleksandra Fedorova >>> Fuel CI Engineer >>> bookwar >>> >>> >>> __ >>> 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Weekly meeting for today canceled.
There is nothing in the agenda for the meeting today, so the meeting is canceled https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda . -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Meeting for May 5 Cancled
Due to the empty agenda, and many people on holiday this week, We will cancel today's meeting. Meetings will resume on May 12 with their regularly scheduled programming -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Release notes with reno
To follow up one of the points brought up in the fuel-plugins [1] session. We briefly discussed using reno [2]. The system appears to be quite clean and concise and will work for this need, and should work for general release notes. I'd propose that we start using reno to catalog changes to the plug-in interfaces and encourage usage elsewhere. I'd like to start a discussion about this further. [1] https://etherpad.openstack.org/p/austin-summit-fuel-plugins [2] http://docs.openstack.org/developer/reno/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [puppet] Austin summit sessions recap
On Tue, May 3, 2016 at 6:38 AM Emilien Macchi <emil...@redhat.com> wrote: > Here's a summary of Puppet OpenStack sessions [1] during Austin summit. > > * General feedback is excellent, things are stable, no major changes > are coming during the next cycle. > * We discussed about the work we want to do during Newton cycle [2]: > > Ubuntu 16.04 LTS > Make Puppet OpenStack modules working and gated on Ubuntu 16.04, > starting from Newton. > Keep stable/mitaka and before gated on Ubuntu 14.04 LTS. > > Release management with trailing cycle > The release model changed to: > http://governance.openstack.org/reference/tags/release_cycle-trailing.html > We'll start producing milestones within a cycle, continue efforts on > tarballs and investigate package builds (rpm, etc). > We spoke some about marking point releases more often. On stable it sounded like everyone was in favor for this to be automated. I didn't catch how we wanted to handle dev milestones > > Move documentation out from Wiki > See [3]. > > puppet-pacemaker unification > Mirantis & Red Hat to continue collaboration on merging efforts on > puppet-pacemaker module: https://review.openstack.org/#/c/296440/) > So both Fuel & TripleO will use the same Puppet module to deploy Pacemaker. > > CI stabilization > We're supporting 18 months old releases, so we will continue all > efforts to stabilize our CI and make it robust so it does not break > every morning. Does this make it the last 3 releases + dev = 4 or the last 2 + dev? Since -3 technically falls off when the next dev cycle starts > > Containers > Most of containers deployments have common bits (user/group > management, config files management, etc). > We decided that we would add the common bits in our modules, so they > can be used by people deploying OpenStack in containers. See [4]. > > [1] https://etherpad.openstack.org/p/newton-design-puppet > [2] https://etherpad.openstack.org/p/newton-puppet-project-status > [3] https://etherpad.openstack.org/p/newton-puppet-docs > [4] https://etherpad.openstack.org/p/newton-puppet-multinode-containers > > > As a retrospective, we've noticed that we had a quiet agenda & > sessions this time, without critical things. It is a sign for our > group things are now very stable and we did an excellent job to be at > this point. > Thanks for everyone who attended our sessions, feel free to add more > things that I might have missed, or any questions. > -- > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [all] cross-project deployment tool meeting
Please include me, I'm in GMT-7, so UTC 1600 is the earliest I can participate. On Tue, Apr 26, 2016 at 11:55 AM Jan Klare <j.kl...@cloudbau.de> wrote: > Hi, > > i just wanted to follow up on this session ( > https://etherpad.openstack.org/p/newton-deployment-tools-discussion) were > we talked about a cross-project meeting for deployment tools. I would love > to see something like that happen and it would be great if we can find a > specific date (maybe monthly) to do something like that. If you are > interested in going to such a meeting, please reply to this mail with a > suggestion when you could join such a meeting. > > Cheers, > Jan (OpenStack Chef) > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Weekly meeting canceled for 4/28
We discussed in the meeting next week that, we will cancel the next week's IRC meeting due to summit activities. The meeting will resume its regular schedule on May-5 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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][ceph] Puppet-ceph is now a formal member of puppet-openstack
It's been a while since we started the puppet-ceph module on stackforge as a friend of OpenStack. Since then Ceph's usage in OpenStack has increased greatly and we have both the puppet-openstack deployment scenarios as well as check-trippleo running against the module. We've been receiving leadership from the puppet-openstack team for a while now and our small core team has struggled to keep up. As such we have added the puppet-openstack cores to the review ACL's in gerrit and have been formally added to the puppet-openstack project in governance. [1] I thank the puppet-openstack team for their support and, I am glad to see the module move under their leadership. [1] https://review.openstack.org/300191 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [all] Newton Summit: cross-project session for deployment tools projects
An obvious +1 from me as well On Fri, Apr 1, 2016 at 10:25 AM Paul Belanger <pabelan...@redhat.com> wrote: > On Thu, Mar 31, 2016 at 05:40:53PM -0400, Emilien Macchi wrote: > > Hi, > > > > OpenStack big tent has different projects for deployments: Puppet, > > Chef, Ansible, Kolla, TripleO, (...) but we still have some topics in > > common. > > I propose we use the Cross-project day to meet and talk about our > > common topics: CI, doc, release, backward compatibility management, > > etc. > > > > Feel free to look at the proposed session and comment: > > https://etherpad.openstack.org/p/newton-cross-project-sessions > > > > Thanks, > > -- > > Emilien Macchi > I'm intereted in this too! > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel][ConfigDB] Separating node and cluster serialized data
One of the problems we've faced with trying to plug-in ConfigDB is trying to separate the cluster attributes from the node attributes in the serialized output (ie astute.yaml) I started talking with Alex S about how we could separate them after astute.yaml is prepared trying to ensure which was which we came back uncertain that the results would be accurate. So I figured I'd go back to the source and see if there was a way to know which keys belonged where. It turns out that we could solve the problem in a simpler and more precise way than cutting them back apart later. Looking over the deployment_serializers.py [1] the serialized data follows a simple work flow iterate over every node in cluster if node is customized: serialized_data = node.replaced_deployment_data else: serialized_data = dict_merge( serialize_node(node), get_common_attrs(cluster)) Taking this into mind, we can simply construct an extension to expose these as an APIs so that we can consume them as a task in the deployment graph. Cluster: We can simply expose DeploymentMultinodeSerializer().get_common_attrs(cluster) This would then be plumbed to the cluster level in ConfigDB Node: if a Node has customized data, then we can return that at the node level, this continues to work at the same as native since it most likely has Cluster merged into it. otherwise we can return the serialized node with whichever of the first 'role' the node has We would expose DeploymentMultinodeSerializer().serialize_node(node, objects.Node.all_roles(node)[0]) for our usage, we don't need to worry about the normal node role combination as the data only influences 'role' and 'fail_if_error' attributes, both are not consumed in the library. https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L93-L121 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [release][puppet] Puppet OpenStack 8.0.0 release (mitaka)
Absolutely fantastic. Great job Emilien and the Puppet-Openstack team. We've made great progress cycle over cycle, and now have closed our release before most of the projects we support. On Mon, Mar 28, 2016 at 3:55 PM Emilien Macchi <emil...@redhat.com> wrote: > Puppet OpenStack team has the immense pleasure to announce the release > of 24 Puppet modules. > > Some highlights and major features: > > Keystone: > * Federation with Mellon support > * Support for multiple LDAP backends > * Usage of keystone-manage bootstrap > > Neutron: > * Support of LBaaSv2 > * More SDN integrations: OpenDayLight, PlugGrid, Midonet > * Use modern parameters for Nova notifications > > Nova: > * Manage Nova API database > * Nova cells support with host aggregates > * Remove EC2 support > * Provider to manage security groups and rules > > Glance: > * Multi-backend support > * Glare API support > > Cinder: > * Block Device backend support > * Allow to deploy Cinder API v3 > > General features: > * IPv6 deployment support > * CI continues to have more use-cases coverage > > New stable modules: > * puppet-mistral > * puppet-zaqar > > > Detailed Release notes: > > http://docs.openstack.org/releasenotes/puppet-aodh > http://docs.openstack.org/releasenotes/puppet-ceilometer > http://docs.openstack.org/releasenotes/puppet-cinder > http://docs.openstack.org/releasenotes/puppet-designate > http://docs.openstack.org/releasenotes/puppet-glance > http://docs.openstack.org/releasenotes/puppet-gnocchi > http://docs.openstack.org/releasenotes/puppet-heat > http://docs.openstack.org/releasenotes/puppet-horizon > http://docs.openstack.org/releasenotes/puppet-ironic > http://docs.openstack.org/releasenotes/puppet-keystone > http://docs.openstack.org/releasenotes/puppet-manila > http://docs.openstack.org/releasenotes/puppet-mistral > http://docs.openstack.org/releasenotes/puppet-murano > http://docs.openstack.org/releasenotes/puppet-neutron > http://docs.openstack.org/releasenotes/puppet-nova > http://docs.openstack.org/releasenotes/puppet-openstack_extras > http://docs.openstack.org/releasenotes/puppet-openstacklib > http://docs.openstack.org/releasenotes/puppet-openstack_spec_helper > http://docs.openstack.org/releasenotes/puppet-sahara > http://docs.openstack.org/releasenotes/puppet-swift > http://docs.openstack.org/releasenotes/puppet-tempest > http://docs.openstack.org/releasenotes/puppet-trove > http://docs.openstack.org/releasenotes/puppet-vswitch > http://docs.openstack.org/releasenotes/puppet-zaqar > > > Big kudos to the team and also our friends from OpenStack Infra, RDO, > UCA, and Tempest! > -- > Emilien Macchi on behalf of Puppet OpenStack team > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Where the FU(EL) did my puppet files go?
With the merging of last bits of changes of fuel-openstack-tasks[1],
fuel-remove-conflict-openstack, and
fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3] a lot of
the files structure relating to tasks has changed in fuel-library.
[1] https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks
[2]
https://blueprints.launchpad.net/fuel/+spec/fuel-remove-conflict-openstack
[3]
https://blueprints.launchpad.net/fuel/+spec/fuel-refactor-osnailyfacter-for-puppet-master-compatibility
With fuel-remove-conflict-openstack:
You will now see that we are heavy into removing the ::openstack:: module
from fuel-library, manifests logic that was here has been refactored into
the task. Some stubs where left and you should expect more cleanup and
removal in Newton
With fuel-refactor-osnailyfacter-for-puppet-master-compatibility:
We now have separated the task entry point from the most of the puppet in
the task. Given any task the entry point is an include stub, while the
meaty puppet is in a corresponding class.
if we had an example task:
osnailyfacter/moduler/globals/globals.pp
the guts will have moved to:
osnailyfacter/manifests/globals/globals.pp
and will live in a class
class osnailyfacter::globals::globals {
}
and the task entry 'osnailyfacter/moduler/globals/globals.pp' will contain
include ::osnailyfacter::globals::globals
And finally, with fuel-openstack-tasks:
We have moved task definitions (tasks.yaml), entry-points, manifests,
etc... related to installing openstack from osnailyfacter to
openstack_tasks. This also includes the Puppetfile definitions for
puppet-openstack modules. They will remain in fuel-library module in
Mitaka, and will most likely become their own module in Newton. In addtion
to them being moved, we have also left stubs for the old entry points
(updated to the new include location) in osnailyfacter, they will be
removed in Newton.
for example:
osnailyfacter/manifests/roles/*
osnailyfacter/modular/roles/*
moved to:
openstack_tasks/manifests/roles/*
openstack_tasks/examples/roles/*
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
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] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack
I've mocked up the change to implementation using the already landed changes to ceph as an example https://review.openstack.org/295571 On Mon, Mar 21, 2016 at 3:44 PM Andrew Woodward <xar...@gmail.com> wrote: > We had originally planned for the FFEs for both fuel-openstack-tasks[1] > and fuel-remove-conflict-openstack to [2] to close on 3/20, This would have > placed them before changes that conflict with > fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088297.html > [2] > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088298.html > [3] > http://lists.openstack.org/pipermail/openstack-dev/2016-March/089028.html > > However we found this morning that the changes from [2], and more of issue > [1] will result in further issues such as [4], where as the task files > move, any task that explicitly relied on it, now no longer is in the same > path. > > [4] https://review.openstack.org/#/c/295170/ > > Due to this newly identified issue with backwards comparability. It > appears that [4] shows that we have plugins using interfaces that we don't > have formal coverage for so If we introduce this set of changes, we will > cause breakage for plugins that use fuel's current tasks. > > From a deprecation standpoint we don't have a way to deal with this, > unless fuel-openstack-tasks [1] lands after > fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. In this > case we can take advantage of the class include stubs, leaving a copy in > the old location (osnailyfacter/modular/roles/compute.pp) pointing to the > new include location (include openstack_tasks::roles::compute) and adding a > warning for deprecation. The tasks includes in the new location > openstack_tasks/examples/roles/compute.pp would simply include the updated > class location w/o the warning. > > This would take care of [1] and it's review [5] > > [5] https://review.openstack.org/283332 > > This still leaves [2] un-addressed, we still have 3 open CR for it: > > [6] Compute https://review.openstack.org/285567 > [7] Cinder https://review.openstack.org/294736 > [8] Swift https://review.openstack.org/294979 > > Compute [6] is in good shape, while Cinder [7] and Swift [8] are not. For > these do we want to continue to land them, if so what do we want to do > about the now deprecated openstack:: tasks? We could leave them in place > with a warning since we would not be using them > > -- > > -- > > Andrew Woodward > > Mirantis > > Fuel Community Ambassador > > Ceph Community > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack
We had originally planned for the FFEs for both fuel-openstack-tasks[1] and fuel-remove-conflict-openstack to [2] to close on 3/20, This would have placed them before changes that conflict with fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088297.html [2] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088298.html [3] http://lists.openstack.org/pipermail/openstack-dev/2016-March/089028.html However we found this morning that the changes from [2], and more of issue [1] will result in further issues such as [4], where as the task files move, any task that explicitly relied on it, now no longer is in the same path. [4] https://review.openstack.org/#/c/295170/ Due to this newly identified issue with backwards comparability. It appears that [4] shows that we have plugins using interfaces that we don't have formal coverage for so If we introduce this set of changes, we will cause breakage for plugins that use fuel's current tasks. >From a deprecation standpoint we don't have a way to deal with this, unless fuel-openstack-tasks [1] lands after fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. In this case we can take advantage of the class include stubs, leaving a copy in the old location (osnailyfacter/modular/roles/compute.pp) pointing to the new include location (include openstack_tasks::roles::compute) and adding a warning for deprecation. The tasks includes in the new location openstack_tasks/examples/roles/compute.pp would simply include the updated class location w/o the warning. This would take care of [1] and it's review [5] [5] https://review.openstack.org/283332 This still leaves [2] un-addressed, we still have 3 open CR for it: [6] Compute https://review.openstack.org/285567 [7] Cinder https://review.openstack.org/294736 [8] Swift https://review.openstack.org/294979 Compute [6] is in good shape, while Cinder [7] and Swift [8] are not. For these do we want to continue to land them, if so what do we want to do about the now deprecated openstack:: tasks? We could leave them in place with a warning since we would not be using them -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] move puppet-pacemaker
gate. > >> > > > > > >> > > > > I propose to move the module to OpenStack so we'll use > >> > > > OpenStack Infra > >> > > > > benefits (Gerrit, Releases, Gating, etc). Another idea would > >> > > > be to > >> > > > gate > >> > > > > the module with TripleO HA jobs. > >> > > > > > >> > > > > The question is, under which umbrella put the module? > Puppet ? > >> > > > TripleO ? > >> > > > > > >> > > > > Or no umbrella, like puppet-ceph. <-- I like this idea > >> > > > > >> > > > > >> > > > I think the module not being under an umbrella makes sense. > >> > > > > >> > > > > >> > > > > > >> > > > > Any feedback is welcome, > >> > > > > > >> > > > > [1] https://github.com/redhat-openstack/puppet-pacemaker > >> > > > > >> > > > Seems like a module that would be useful outside of TripleO, > so > >> > > > it > >> > > > doesn't seem like it should live under that. Other than that > I > >> > > > don't > >> > > > have enough knowledge of the organization of the puppet > modules > >> > > > to > >> > > > comment. > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > __ > >> > > > OpenStack Development Mailing List (not for usage questions) > >> > > > Unsubscribe: > >> > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> > > > > >> > > > < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > >> > > > > >> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Juan Antonio Osorio R. > >> > > > e-mail: jaosor...@gmail.com <mailto: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 > >> > > > > >> > > > >> > > -- > >> > > 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 > >> > > Email had 1 attachment: > >> > > + signature.asc > >> > > 1k (application/pgp-signature) > >> > > >> > > >> > > __ > >> > 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 > > > > > > -- > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Getting rid of cluster status
On Tue, Mar 15, 2016 at 4:04 AM Roman Prykhodchenko <m...@romcheg.me> wrote: > Fuelers, > > I would like to continue the series of "Getting rid of …" emails. This > time I’d like to talk about statuses of clusters. > > The issues with that attribute is that it is not actually related to real > world very much and represents nothing. A few month ago I proposed to make > it more real-world-like [1] by replacing a simple string by an aggregated > value. However, after task based deployment was introduced even that > approach lost its connection to the real world. > > My idea is to get rid of that attribute from a cluster and start working > with status of every single node in it. Nevertheless, we only have tasks > that are executed on nodes now, so we cannot apply the "status" term to > them. What if we replace that with a sort of boolean value called > maintenance_mode (or similar) that we will use to tell if the node is > operational or not. After that we will be able to use an aggregated > property for cluster and check, if there are any nodes that are under a > progress of performing some tasks on them. > Yes, we still need an operations attribute, I'm not sure a bool is enough, but you are quite correct, setting the status of the cluster after operational == True based on the result of a specific node failing, is in practice invalid. At the same time, operational == True is not necessarily deployment succeeded, its more along the line of deployment validated, which may be further testing passing like ostf, or more manual in the operator wants to do more testing their own prior to changing the state. As we adventure in to the LCM flow, we actually need status of each component in addition of the general status of the cluster to determine the proper course of action the on the next operation. For example nova-compute if the cluster is not operational, then we can provision compute nodes, and have them enabled, or active in the scheduler automatically. However if the cluster is operational, a new compute node must be disabled, or otherwise blocked from the default scheduler until the node has received validation. In this case the interpretation of operational is quite simple For example ceph Here we care less about the status of the cluster (slightly, this example ignores ceph's impact on nova-compute), and more about the status of the service. In the case that we deploy ceph-osd's when their are not replica factor osd hosts online (3) the we can provision the OSD's similar to nova-compute, in that we can bring them all online and active and data could be placed to them immediately (more or less). but if the ceph status is operational, then we have to take a different action, the OSD's have to be brought in disabled, and gradually(probably by the operator) have their data weight increased so they don't clog the network with data peering which causes the clients may woes. > Thoughts, ideas? > > > References: > > 1. https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status > > > - romcheg > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Removing logs from Fuel Web UI and Nailgun
...@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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>> > >>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> -- >>>> Mike Scherbakov >>>> #mihgen >>>> >>>> >>>> >>>> __ >>>> 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 >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Bogdan Dobrelya, >>>> Irc #bogdando >>>> >>>> >>>> __ >>>> 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 >>>> >>> -- >>> Mike Scherbakov >>> #mihgen >>> >>> >>> __ >>> 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 >>> >>> >> >> >> -- >> Vitaly Kramskikh, >> Fuel UI Tech Lead, >> Mirantis, Inc. >> __ >> 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 >> > -- > Mike Scherbakov > #mihgen > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel][Fuel-Library] Fuel CI issues
Today we had a sync up call and discussed this. To summarize Attendees: Aleksandr Didenko Alex Schultz Andrew Woodward Alexey Shtokolov Bartek Kupidura Bogdan Dobrelya Denis Egorenko Ivan Berezovskiy Kyrylo Galanov Maksim Malchuk Matthew Mosesohn Max Yatsenko Oleg Gelbukh Oleksiy Molchanov Petr Zhurba Sergey Kolekonov Sergey Vasilenko Sergii Golovatiuk Stanislav Makar Stanislaw Bogatkin Vladimir Eremin Vladimir Kuklin Issue: moving to puppet-openstack on master has exposed fuel-library to breakage and there are many concerns about changes landing that can break it. Alex S. Proposed that we continue the course, and finish setting up Check voting on the relevant puppet-openstack modules - The participants agreed with this Action: Sergii G & Aleksandra Fedorova will propose needed changes to project-config to add tests Issue: closing the regressions gap until fuel-ci votes on puppet-openstack check It was proposed that we invent a system that holds back the versions nightly, and after completion of automated testing; It can automatically move it forward. Action: There was no consensus on this and should be discussed here further on this thread. On Sun, Mar 6, 2016 at 11:33 PM Dmitry Borodaenko <dborodae...@mirantis.com> wrote: > Aleksandra, > > Very good point on separating the concerns about integration tests for > Fuel as a whole and verifying commits to a single component such as > fuel-library. In theory, it could support the right balance between > stable CI and up-to-date code, but only if we resolve the two remaining > problems: one small and technical and the other large and social. > > You've already pointed out the first problem: update of fuel-library CI > environment is not yet fully automated, and so the environment is liable > to lag behind all involved components for days if not weeks. > > This by itself is simple enough, if labourous, to work around (update it > manually every day, or after every successful BVT), but still leaves us > with the problem of motivation. > > We've been discussing the CI duty for fuel-library integration with > puppet-openstack since more than a month ago [0], and it has > continuously failed to materialize. Within days of getting an action > item in that IRC meeting to arrange it, Andrew Maksimov has responded > privately that nobody in his team has time for this. And we all know > what "I don't have time" actually means [1]. Two weeks later, we were > ready to launch the integration and the question of CI duty came up > again [2], with the same result. > > [0] > http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-04-16.02.log.html#l-66 > [1] > http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-a-priority > [2] > http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-18-16.00.log.html#l-190 > > Here we are two more weeks later, the integration is on, and the first > reaction from fuel-library core reviewers is "we don't have time to deal > with this, turn it back off right now". And I'm not just summarizing > Vladimir's email, on Friday we had a long thread on an internal mailing > list with exactly this in the subject line (my apologies, but my disgust > at the fact that it was started behind closed doors drowns any qualms > about dragging it back into the open). > > After we change Fuel CI to use fixed, most recent to have passed BVT, > revisions of puppet-openstack modules, first thing that will happen is > that BVT on Fuel ISO will start failing again, while fuel-library CI > will continue to work. Without the pressure of failing commit > verification CI, fuel-library developers will have even less incentive > to keep fuel-library up to date with puppet-openstack (not to mention > pro-actively reviewing puppet-openstack commits to catch potential > regressions before they happen), and very soon Fuel QA team will get fed > up with not having a stable ISO for the swarm test, and will demand that > we go back to using fixed puppet-openstack revisions for the ISO, too. > > Both here and on the internal thread, many technical and organizational > concerns were raised, and I'll get to them in a bit, but a concern > without the will to resolve it is only an excuse, we won't get far if we > don't want to make it work. > > So why don't fuel-library developers want to spend time on > puppet-openstack integration? > > I see two dimensions to this problem. On one axis, there's the > cost/benefit balance: how much work does it take, and what do we gain > from doing it? On the other is the question of who benefits and who > carries the costs? > > Without tracking HEAD of puppet-openstack in fuel-library, the primary > cost is carried by puppet-openstack developers who maintain the upstr
[openstack-dev] [Fuel] FFE Tracking
As FF quickly approaches (March 2) we have started posting feature freeze exception requests. If you would like to request an exception for your feature, please request one in accordance with the guidelines [0], and include your estimate for completion and risk at that time of completion. Also please add your feature to the fuel meeting agenda [1] and we will review all of the outstanding FFE requests on this Thursdays IRC meeting. [0] https://wiki.openstack.org/wiki/FeatureFreeze [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel][FFE] Remove conflicting openstack module parts
I'd like to request a feature freeze exception for the Remove conflicting openstack module parts feature [0] This is necessary to make the feature Decouple Fuel and OpenStack tasks feature useful [1] , some of the patches are ready for review and some still need to be written [2] We need 2 - 3 weeks after FF to finish this feature. Risk of not delivering it after 3 weeks is low. [0] https://blueprints.launchpad.net/fuel/+spec/fuel-remove-conflict-openstack [1] https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks [2] https://review.openstack.org/#/q/topic:bp/fuel-remove-conflict-openstack,n,z -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel][FFE] Decouple Fuel and OpenStack tasks
I'd like to request a feature freeze exception for Decouple Fuel and OpenStack tasks feature [0]. While the code change [1] is ready and usually passing CI we have too much churn in the tasks currently which puts the patch set in conflict constantly so it has to be rebased multiple times a day. We need more review and feedback on the change, and a quiet period to merge it [0] https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks [1] https://review.openstack.org/#/c/283332/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Supporting multiple Openstack versions
; versioned serializers for supported releases, which know how to convert
>> the only latest existing data to any of its supported previous versions.
>> - Decoupling we do by putting modules with its compositions to different
>> versioned /etc/puppet subdirectories. I'm not sure how do we decouple
>> Nailgun serializers though.
>> - Complexity is how we compose those modules / write logic of serializers.
>> - Duplication is puppet classes (and providers) with slightly different
>> call parameters from a version to version. Sometimes even not backwards
>> compatible. Probably same to the serializers?
>>
>> So, we're going to *increase complexity* by introducing
>> super-compositions for multi OpenStack releases. Not sure about what to
>> happen to the serializers, any volunteers to clarify an impact?. And the
>> Rules "allow" us to do so only in order to decrease either coupling or
>> shared state, which is not the case, AFAICT. Modules with compositions
>> are separated well by OpenStack versions, nothing to decrease. Might
>> that change to decrease a shared state? I'm not sure if it even applies
>> here. Puppet versioning shares nothing. Only Nailgun folks may know the
>> answer.
>>
>>
> I don't think we have to increase complexity if we properly structure
> fuel-library. I think we could also structure it in a way that can be
> tested in an automated fashion. I think we can come up with a set of rules
> for tasks and how to implement a new task that can reduce complexity and
> actually allow for code reuse. If you take a look at our tasks today there
> is actually an excessive amount of duplication between tasks[0][1] around
> variable and configuration gathering before we even call the upstream
> OpenStack modules. The tasks we have today are basically just undocumented
> freeform puppet that can only be fully tested via multiple deployment tests
> because of the lack of decent test coverage. Additionally, we have no real
> way of testing deprecation between releases today because there's no formal
> api contract for modular tasks themselves.
>
> I would be interested in investigating a restructure of the tasks that
> might go something like
> 1) Restructure fuel-library tasks into a configuration
> generation/formatting method (extracting data from hiera/globals/etc) and
> the actual configuration application logic
> 2) For the configuration gathering items that we traditionally load up at
> the top of our tasks, we could investigate leveraging hiera for providing
> data to classes or structure into an osnailyfacter::config:: class.
> 2) Move the actual configuration application logic into an
> osnailyfacter::task:: method with a proper documented api contract
> with deprecation policy. These classes could use something like
> create_resources(...) to dynamically load the classes with the provided
> parameters to support the class api changes between upstream module
> versions.
> 3) Add release specific overrides into
> osnailyfacter::task where :: could be
> automatically included based on something like hiera('openstack_version')
>
> There are a few added benefits of restructuring the tasks into traditional
> puppet classes.
> 1) If we need to support any sort of traditional puppet master LCM for
> nodes, by moving the tasks into specific class we can actually just
> leverage our already written task code to ensure configurations.
> 2) Testability around idempotency as we can write beaker tests to be able
> to test deployment tasks for idempotency and deployment without having to
> stand up all the other pieces of fuel. Similar to the Puppet OpenStack's
> puppet-openstack-integration[2] module.
> 3) Better defined separation and containment of release specific items so
> when we are moving forward. It's much easier to remove n-X release as we
> could just 'find deployment/puppet/osnailyfacter/manifests/ -name 'kilo.pp'
> -delete'
>
> That being said, this would be a lot of work but it's mostly taking what
> we have today and reorganizing it rather than having to write things from
> scratch and providing some policy rules around structure of tasks. I think
> in the long run we could benefit by being able to test fuel-library tasks
> with existing tools rather than continually having to rely on noop or
> actual deployment tests with nailgun/astute/isos/etc. This is just a
> starting point for a conversation and I think we should have a serious
> discussion about this topic and not just dismiss it because it's hard or
> might add complexity.
>
>
> Thanks,
> -Alex
>
> [0]
> https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/glance/glance.pp#L3-L99
> [
Re: [openstack-dev] [fuel] Supporting multiple Openstack versions
On Wed, Feb 17, 2016 at 9:29 AM Bogdan Dobrelya <bdobre...@mirantis.com> wrote: > > So we'll have tons of conditionals in composition layer, right? Even if > > some puppet-openstack class have just one new parameter in new release, > > then we'll have to write a conditional and duplicate class declaration. > Or > > write complex parameters hash definitions/merges and use > > create_resources(). The more releases we want to support the more > > complicated composition layer will become. That won't make contribution > to > > fuel-library easier and even can greatly reduce development speed. Also > are > > we going to add new features to stable releases using this workflow with > > single composition layer? > > As I can see from an example composition [0], such code would be an > unmaintainable burden for development and QA process. Next imagine a > case for incompatible *providers* like network transformations - shall > we put multiple if/case to the ruby providers as well?.. > No, part of the point of reusing the current serializers from nailgun and the current composition layer / fuel-library is exactly to avoid this kind of issue. The other point is to take advantage of new features in the new version of Fuel The conditions needed in the composition layer are only to the underlying puppet-openstack modules, which would be rolled back to version that matches the openstack versions [a] [a] https://github.com/xarses/fuel-library/blob/9-Kilo/deployment/Puppetfile > > That is not a way to go for a composition, sorry. While the idea may be > doable, I agree, but perhaps another way. > Given the requirements to be able to use new features in fuel, with an older version of OpenStack, what alternative would you propose? > > (tl;dr) > By the way, this reminded me "The wrong abstraction" [1] article and > discussion. I agree with the author and believe one should not group > code (here it is versioned puppet modules & compositions) in a way which > introduces abstractions (here a super-composition) with multiple > if/else/case and hardcoded things to switch the execution flow based on > version of things. Just keep code as is - partially duplicated by > different releases in separate directories with separate modules and > composition layers and think of better solutions please. > > There is also a nice comment: "...try to optimize my code around > reducing state, coupling, complexity and code, in that order". I > understood that like a set of "golden rules": > - Make it coupled more tight to decrease (shared) state > - Make it more complex to decrease coupling > - Make it duplicated to decrease complexity (e.g. abstractions) > > (tl;dr, I mean it) > So, bringing those here. > - The shared state is perhaps the Nailgun's world view of all data and > versioned serializers for supported releases, which know how to convert > the only latest existing data to any of its supported previous versions. > - Decoupling we do by putting modules with its compositions to different > versioned /etc/puppet subdirectories. I'm not sure how do we decouple > Nailgun serializers though. > - Complexity is how we compose those modules / write logic of serializers. > - Duplication is puppet classes (and providers) with slightly different > call parameters from a version to version. Sometimes even not backwards > compatible. Probably same to the serializers? > > So, we're going to *increase complexity* by introducing > super-compositions for multi OpenStack releases. Not sure about what to > happen to the serializers, any volunteers to clarify an impact?. And the > Rules "allow" us to do so only in order to decrease either coupling or > shared state, which is not the case, AFAICT. Modules with compositions > are separated well by OpenStack versions, nothing to decrease. Might > that change to decrease a shared state? I'm not sure if it even applies > here. Puppet versioning shares nothing. Only Nailgun folks may know the > answer. > > [0] > > https://review.openstack.org/#/c/281084/1/deployment/puppet/ceph/manifests/nova_compute.pp > [1] https://news.ycombinator.com/item?id=11032296 > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Supporting multiple Openstack versions
On Wed, Feb 17, 2016 at 8:38 AM Aleksandr Didenko <adide...@mirantis.com> wrote: > > This requires the loss of all of the features in the newer version of > fuel since it relies on the older version of the serialized data from > nailgun. > > Yes. But isn't it how "stable" branches are supposed to work? Introducing > new features into "stable" branches will make them not so "stable", right? > Even if these new features are introduced in composition layer or > configuration data. just an example: network transformations in astute.yaml > that are being translated into actual network configuration. > I think you may be confusing the OpenStack version fuel deploys and fuel its self. This is about keeping around older version(s) of OpenStack (most often the most recent from master) and not dropping it during the development process. This would allow for better switching during development (ie when we need to move the default forward) and if we don't drop until after the release, would allow for the usage of multiple versions of openstack. > Yes, this is, in part, about taking advantage of new fuel features on > stable openstack releases, we are almost always behind and the previous > release(s) supported this already. > > Introducing new features to stable releases will require full cycle of > testing. So, basically, it will affect the whole development process. > This is not about introducing features to a stable fuel release, its about taking advantage of fuel features with a older openstack release, the only cycle we are working on is fuel. We are almost always one or more releases behind openstack in supporting features in openstack, this would rarely create an issue where the version of openstack doesn't support what fuel is doing Our development process already moves us through this process, when we develop the next version of fuel, we stay on the same version of openstack as the previous fuel release. We only cut forward very late in the cycle. So we can simply support both through the end of the release cycle and then decide if we are doping it in beginning of the next cycle > > In addtion we currently don't allow for new clusters to be deployed this > way. > > We can remove this restriction. Nailgun is able to serialize data for > previous releases because that's how it supports adding new nodes to older > environments after upgrade, so it should not be a problem. > > Regards, > Alex > > On Fri, Feb 12, 2016 at 10:19 PM, Andrew Woodward <xar...@gmail.com> > wrote: > >> >> >> On Thu, Feb 11, 2016 at 1:03 AM Aleksandr Didenko <adide...@mirantis.com> >> wrote: >> >>> Hi, >>> >>> >>> > So what is open? The composition layer. >>> >>> We can have different composition layers for every release and it's >>> already implemented in releases - separate puppet modules/manifests dir for >>> every release. >>> >> >> This requires the loss of all of the features in the newer version of >> fuel since it relies on the older version of the serialized data from >> nailgun. In addtion we currently don't allow for new clusters to be >> deployed this way. >> >> >>> >>> > Currently, we just abandon support for previous versions in the >>> composition layer and leave them to only be monuments in the >>> stable/ series branches for maintenance. If we instead started >>> making changes (forwards or backwards that) change the calls based on the >>> openstack version [5] then we would be able to change the calls based on >>> then needs of that release, and the puppet-openstack modules we are working >>> with. >>> >>> So we'll have tons of conditionals in composition layer, right? Even if >>> some puppet-openstack class have just one new parameter in new release, >>> then we'll have to write a conditional and duplicate class declaration. Or >>> write complex parameters hash definitions/merges and use >>> create_resources(). The more releases we want to support the more >>> complicated composition layer will become. That won't make contribution to >>> fuel-library easier and even can greatly reduce development speed. Also are >>> we going to add new features to stable releases using this workflow with >>> single composition layer? >>> >>> Yes, we need conditionals in the composition layer, we already need >> these to no jam the gate when we switch between stable and master, we might >> as well maintain them properly so that we can start running multiple >> versions >> >> Yes, this is, in part, about taking advant
Re: [openstack-dev] [fuel] Supporting multiple Openstack versions
t CI, infra (required HW), acceptance > testing, etc impact? > On average, two openstack releases would be supported the version that this fuel is being developed for, and the prior stable openstack release. There is an abnormal exception for Kilo. For 9 I would propose Kilo and Mitaka if we want to keep it to just two. ISO size, only one release should be bundled on the ISO, the other can exist on the external package repos. the default release should be included by default We would want to add parameter to pick this for during build if someone wanted the other version For the normal workflow (as an extension of how we function currently anyway). We would gate the fuel cycle on the stable release and have a non-voting basic test on master version. We would run regular BVT on both. When we are ready to switch to the master release because of RC availability or other high stability, then we would flip this. Stable would become basic non-voting test and "master" (at this point new stable) would get the gate > > Regards, > Alex > > > > On Thu, Feb 11, 2016 at 6:57 AM, Andrew Woodward <xar...@gmail.com> wrote: > >> Right now master (targeting 9.0) is still deploying liberty and there is >> active work going on to support both Kilo and Mitaka. On the review queue >> are changes that would make fuel-library in-compatible with the prior >> (liberty) openstack release. However I think if we extend a little bit of >> effort we can keep some semblance of "support" while creating a pattern for >> the Kilo support to continue to use. At the same time this pattern can help >> us test parallel versions as we move through openstack releases and should >> reduce occurrences of our CI freeze/merge parties >> >> What is this magic pattern? Well its already present, and all be it not >> designed for this I think we could quickly make it work. We use the release >> fixture already present in fuel. Originally designed to work for upgrades, >> we could reuse this within the same fuel release to control various aspects >> needed to deploy a separate openstack version. >> >> What we need to support multiple OpenStack versions: >> 1) Packge repo's that contain the relevant bits. CHECK, this can be >> toggled with a new release [1][2] >> 2) can point to different Puppet modules CHECK, also in toggled release >> [3] >> 3) Composition layer that supports calls to different puppet-openstack >> modules, WIP, it still needs work, but can be done [4] >> >> So what is open? The composition layer. >> >> Currently, we just abandon support for previous versions in the >> composition layer and leave them to only be monuments in the >> stable/ series branches for maintenance. If we instead started >> making changes (forwards or backwards that) change the calls based on the >> openstack version [5] then we would be able to change the calls based on >> then needs of that release, and the puppet-openstack modules we are working >> with. >> >> Given that we most of the time we would be supporting the previous >> release (liberty) (which we should avoid dropping until after dev releases) >> and the currently under development release (Mitaka), this will give us >> some magical powers. >> >> Testing master while keeping stable. Given the ability to conditional >> what source of openstack bits, which versions of manifests we can start >> testing both master and keep health on stable. This would help accelerate >> both fuel development and deploying and testing development versions of >> openstack >> >> Deploying stable and upgrading later. Again given the ability to deploy >> multiple OpenStack versions within the same Fuel version, teams focused on >> upgrades can take advantage of the latest enhancements in fuel to work the >> upgrade process more easily, as an added benefit this would eventually lead >> to better support for end user upgrades too. >> >> Deploying older versions, in the odd case that we need to take advantage >> of older OpenStack releases like in the case of Kilo with a newer version >> of Fuel we can easily maintain that version too as we can keep the older >> cases around in the composition layer with out adding much burden on the >> other components. >> >> [1] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1957 >> [2] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1906 >> >> [3] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1371 >> >> [4] htt
[openstack-dev] [fuel] Supporting multiple Openstack versions
Right now master (targeting 9.0) is still deploying liberty and there is active work going on to support both Kilo and Mitaka. On the review queue are changes that would make fuel-library in-compatible with the prior (liberty) openstack release. However I think if we extend a little bit of effort we can keep some semblance of "support" while creating a pattern for the Kilo support to continue to use. At the same time this pattern can help us test parallel versions as we move through openstack releases and should reduce occurrences of our CI freeze/merge parties What is this magic pattern? Well its already present, and all be it not designed for this I think we could quickly make it work. We use the release fixture already present in fuel. Originally designed to work for upgrades, we could reuse this within the same fuel release to control various aspects needed to deploy a separate openstack version. What we need to support multiple OpenStack versions: 1) Packge repo's that contain the relevant bits. CHECK, this can be toggled with a new release [1][2] 2) can point to different Puppet modules CHECK, also in toggled release [3] 3) Composition layer that supports calls to different puppet-openstack modules, WIP, it still needs work, but can be done [4] So what is open? The composition layer. Currently, we just abandon support for previous versions in the composition layer and leave them to only be monuments in the stable/ series branches for maintenance. If we instead started making changes (forwards or backwards that) change the calls based on the openstack version [5] then we would be able to change the calls based on then needs of that release, and the puppet-openstack modules we are working with. Given that we most of the time we would be supporting the previous release (liberty) (which we should avoid dropping until after dev releases) and the currently under development release (Mitaka), this will give us some magical powers. Testing master while keeping stable. Given the ability to conditional what source of openstack bits, which versions of manifests we can start testing both master and keep health on stable. This would help accelerate both fuel development and deploying and testing development versions of openstack Deploying stable and upgrading later. Again given the ability to deploy multiple OpenStack versions within the same Fuel version, teams focused on upgrades can take advantage of the latest enhancements in fuel to work the upgrade process more easily, as an added benefit this would eventually lead to better support for end user upgrades too. Deploying older versions, in the odd case that we need to take advantage of older OpenStack releases like in the case of Kilo with a newer version of Fuel we can easily maintain that version too as we can keep the older cases around in the composition layer with out adding much burden on the other components. [1] https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1957 [2] https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1906 [3] https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1371 [4] https://github.com/xarses/fuel-library/tree/9-Kilo [5] https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1948 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Fuel Community ISO 8.0
Was a bug ever filed for this? It's still not on the landing page On Thu, Feb 4, 2016 at 4:19 AM Ivan Kolodyazhny <e...@e0ne.info> wrote: > Thanks, Igor. > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Thu, Feb 4, 2016 at 1:21 PM, Igor Belikov <ibeli...@mirantis.com> > wrote: > >> Hi Ivan, >> >> I think this counts as a bug in our community page, thanks for noticing. >> You can get 8.0 Community ISO using links in status dashboard on >> https://ci.fuel-infra.org >> -- >> Igor Belikov >> Fuel CI Engineer >> ibeli...@mirantis.com >> >> On 04 Feb 2016, at 13:53, Ivan Kolodyazhny <e...@e0ne.info> wrote: >> >> Hi team, >> >> I've tried to download Fuel Community ISO 8.0 from [1] and failed. We've >> got 2 options there: the latest stable (7.0) and nightly build (9.0). Where >> can I download 8.0 build? >> >> [1] https://www.fuel-infra.org/#fuelget >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> __ >> 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel][Plugins] Multi release packages
th best regards, > > Stan. > > > > __ > > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?
Unless we hope to gain some insight and specific testing by installing the ISO on a bare-metal node (like UEFI), I'd propose that we stop testing things that are well tested elsewhere (a given ISO produces a working fuel master) and just focus on what we want to test in this environment. Along this line, we cold a) keep fuel masternode as a VM that is set up with access to the networks with the BM nodes. We have a good set of tools to build the master node in a VM already we can just re-use time b) use cobbler to control PXE based ISO boot/install, then either create new profiles in cobbler for various fuel nodes with different ISO or replace the single download link. (Make sure you transfer the image over HTTP as TFTP will be slow for such size. We have some tools and knowledge around using cobbler as this is effectively what fuel does its self. c) fuel on fuel, as an extension of b, we can just use cobbler on an existing fuel node to provision another fuel node, either from ISO or even it's own repo's (we just need to send a kickstart) d) you can find servers with good BMC or DRAC that we can issue remote mount commands to the virtual cd-rom e) consider using live-cd approach (long implmentation). I've been asked about supporting this in product where we start an environment with live-cd, the master node may make it's own home and then it can be moved off the live-cd when it's ready On Tue, Feb 9, 2016 at 10:25 AM Pavlo Shchelokovskyy < pshchelokovs...@mirantis.com> wrote: > Hi, > > Ironic also supports running it as standalone service, w/o > Keystone/Glance/Neutron/Nova etc integration, deploying images from HTTP > links. Could that be an option too? > > BTW, there is already an official project under OpenStack Baremetal > program called Bifrost [0] that, quoting, "automates the task of deploying > a base image onto a set of known hardware using Ironic" by installing and > configuring Ironic in standalone mode. > > [0] https://github.com/openstack/bifrost > > Cheers, > > > On Tue, Feb 9, 2016 at 6:46 PM Dennis Dmitriev <ddmitr...@mirantis.com> > wrote: > >> Hi all! >> >> To run system tests on CI on a daily basis using baremetal servers >> instead of VMs, Fuel admin node also should be bootstrapped. >> >> There is no a simple way to mount an ISO with Fuel as a CDROM or USB >> device to a baremetal server, so we choose the provisioning with PXE. > > It could be done in different ways: >> >> - Configure a libvirt bridge as dnsmasq/tftp server for admin/PXE network. >> Benefits: no additional services to be configured. >> Doubts: ISO should be mounted on the CI host (via fusefs?); a HTTP >> or NFS server for basic provisioning should be started in the admin/PXE >> network (on the CI host); >> >> - Start a VM that is connected to admin/PXE network, and configure >> dnsmasq/tftp there. >> Benefits: no additional configuration on the CI host should be >> performed >> Doubts: starting the PXE service becomes a little complicated >> >> - Use Ironic for manage baremetal nodes. >> Benefits: good support for different hardware, support for >> provisioning from ISO 'out of the box'. >> Doubts: support for Ironic cannot be implemented in short terms, >> and there should be performed additional investigations. >> >> My question is: what other benefits or doubts I missed for first two >> ways? Is there other ways to provision baremetal with Fuel that can be >> automated in short terms? >> >> Thanks for any suggestions! >> >> >> -- >> Regards, >> Dennis Dmitriev >> QA Engineer, >> Mirantis Inc. http://www.mirantis.com >> e-mail/jabber: dis.x...@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 >> > -- > Dr. Pavlo Shchelokovskyy > Senior Software Engineer > Mirantis Inc > www.mirantis.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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel][Plugins] Tasks ordering between plugins
Simon, you should use the deployment_tasks.yaml interface (which will likely eventually move to '*/tasks.yaml' (to mimic library) This uses the same task system as granular deploy. you can set task ordering between known tasks and roles names, in the case that they are not registered they will simply be ignored. The result will be that the engine will parse out the precise location for tasks to run in the graph (you can run outside of the post-deployment with them). In most cases, you will not need to specify precise ordering between the plugins. I know there is the odd case that two components need to modify the same parts, there are a couple of ways we can work this out, but it ultimately will come down to a case-by case until we solidify the config-db workflow On Wed, Jan 27, 2016 at 5:45 AM Simon Pasquier <spasqu...@mirantis.com> wrote: > Hi, > > I see that tasks.yaml is going to be deprecated in the future MOS versions > [1]. I've got one question regarding the ordering of tasks between > different plugins. > With tasks.yaml, it was possible to coordinate the execution of tasks > between plugins without prior knowledge of which plugins were installed [2]. > For example, lets say we have 2 plugins: A and B. The plugins may or may > not be installed in the same environment and the tasks execution should be: > 1. Run task X for plugin A (if installed). > 2. Run task Y for plugin B (if installed). > 3. Run task Z for plugin A (if installed). > > Right now, we can set task priorities like: > > # tasks.yaml for plugin A > - role: ['*'] > stage: post_deployment/1000 > type: puppet > parameters: > puppet_manifest: puppet/manifests/task_X.pp > puppet_modules: puppet/modules > > - role: ['*'] > stage: post_deployment/3000 > type: puppet > parameters: > puppet_manifest: puppet/manifests/task_Z.pp > puppet_modules: puppet/modules > > # tasks.yaml for plugin B > - role: ['*'] > stage: post_deployment/2000 > type: puppet > parameters: > puppet_manifest: puppet/manifests/task_Y.pp > puppet_modules: puppet/modules > > How would it be handled without tasks.yaml? > > Regards, > Simon > > [1] https://review.openstack.org/#/c/271417/ > [2] https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Wipe of the nodes' disks
On Tue, Dec 29, 2015 at 5:35 AM Sergii Golovatiuk <sgolovat...@mirantis.com> wrote: > Hi, > > Let me comment inline. > > > On Mon, Dec 28, 2015 at 7:06 PM, Andrew Woodward <xar...@gmail.com> wrote: > >> In order to ensure that LVM can be configured as desired, its necessary >> to purge them and then reboot the node, otherwise the partitioning commands >> will most likely fail on the next attempt as they will be initialized >> before we can start partitioning the node. Hence, when a node is removed >> from the environment, it is supposed to have this data destroyed. Since >> it's a running system, the most effective way was to blast the first 1Mb of >> each partition. (with out many more reboots) >> >> As to the fallback to SSH, there are two times we use this process, with >> the node reboot (after cobbler/IBP finishes), and with the wipe as we are >> discussing here. These are for the odd occurrences of the nodes failing to >> restart after the MCO command. I don't think anyone has had much success >> trying to figure out why this occurs, but I've seen nodes get stuck in >> provisioning and remove in multiple environments using 6.1 where they >> managed to break the SSH Fallback. It would occur around 1/20 nodes >> seemingly randomly. So with the SSH fallback I nearly never see the failure >> in node reboot. >> > > If we talk about 6.1-7.0 release there shouldn't be any problems with mco > reboot. SSH fallback must be deprecated at all. > As I noted, I've see several 6.1 deployments where it was needed, I'd consider it still very much in use. In other cases it might be necessary to attempt to deal with a node who's MCO agent is dead, IMO they should be kept. >> > >> > >> > >> On Thu, Dec 24, 2015 at 6:28 AM Alex Schultz <aschu...@mirantis.com> >> wrote: >> >>> On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov >>> <asvechni...@mirantis.com> wrote: >>> > Hi, >>> > We have faced the issue that nodes' disks are wiped after stop >>> deployment. >>> > It occurs due to the logic of nodes removing (this is old logic and >>> it's not >>> > actual already as I understand). This logic contains step which calls >>> > erase_node[0], also there is another method with wipe of disks [1]. >>> AFAIK it >>> > was needed for smooth cobbler provision and ensure that nodes will not >>> be >>> > booted from disk when it shouldn't. Instead of cobbler we use IBP from >>> > fuel-agent where current partition table is wiped before provision >>> stage. >>> > And use disks wiping for insurance that nodes will not booted from disk >>> > doesn't seem good solution. I want to propose not to wipe disks and >>> simply >>> > unset bootable flag from node disks. >>> >> > Disks must be wiped as boot flag doesn't guarantee anything. If bootlag is > not set, BIOS will ignore ignore the device in boot-order. More over, 2 > partitions may have bootflag or operator may set to skip boot-order in BIOS. > > > >>> > Please share your thoughts. Perhaps some other components use the fact >>> that >>> > disks are wiped after node removing or stop deployment. If it's so, >>> then >>> > please tell about it. >>> > >>> > [0] >>> > >>> https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137 >>> > [1] >>> > >>> https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb >>> > >>> >>> I thought the erase_node[0] mcollective action was the process that >>> cleared a node's disks after their removal from an environment. When >>> do we use the ssh_erase_nodes? Is it a fall back mechanism if the >>> mcollective fails? My understanding on the history is based around >>> needing to have the partitions and data wiped so that the LVM groups >>> and other partition information does not interfere with the >>> installation process the next time the node is provisioned. That >>> might have been a side effect of cobbler and we should test if it's >>> still an issue for IBP. >>> >> > Since we do not use classical provision anymore, we have mco connection > all the time. During IBP we have it as part of bootstrap, after reboot, mco > is still present so all actions should be done via mco. > > >> >>> >>> Thanks, >>> -Alex >>> >>
Re: [openstack-dev] [Fuel] Wipe of the nodes' disks
In order to ensure that LVM can be configured as desired, its necessary to purge them and then reboot the node, otherwise the partitioning commands will most likely fail on the next attempt as they will be initialized before we can start partitioning the node. Hence, when a node is removed from the environment, it is supposed to have this data destroyed. Since it's a running system, the most effective way was to blast the first 1Mb of each partition. (with out many more reboots) As to the fallback to SSH, there are two times we use this process, with the node reboot (after cobbler/IBP finishes), and with the wipe as we are discussing here. These are for the odd occurrences of the nodes failing to restart after the MCO command. I don't think anyone has had much success trying to figure out why this occurs, but I've seen nodes get stuck in provisioning and remove in multiple environments using 6.1 where they managed to break the SSH Fallback. It would occur around 1/20 nodes seemingly randomly. So with the SSH fallback I nearly never see the failure in node reboot On Thu, Dec 24, 2015 at 6:28 AM Alex Schultz <aschu...@mirantis.com> wrote: > On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov > <asvechni...@mirantis.com> wrote: > > Hi, > > We have faced the issue that nodes' disks are wiped after stop > deployment. > > It occurs due to the logic of nodes removing (this is old logic and it's > not > > actual already as I understand). This logic contains step which calls > > erase_node[0], also there is another method with wipe of disks [1]. > AFAIK it > > was needed for smooth cobbler provision and ensure that nodes will not be > > booted from disk when it shouldn't. Instead of cobbler we use IBP from > > fuel-agent where current partition table is wiped before provision stage. > > And use disks wiping for insurance that nodes will not booted from disk > > doesn't seem good solution. I want to propose not to wipe disks and > simply > > unset bootable flag from node disks. > > > > Please share your thoughts. Perhaps some other components use the fact > that > > disks are wiped after node removing or stop deployment. If it's so, then > > please tell about it. > > > > [0] > > > https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137 > > [1] > > > https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb > > > > I thought the erase_node[0] mcollective action was the process that > cleared a node's disks after their removal from an environment. When > do we use the ssh_erase_nodes? Is it a fall back mechanism if the > mcollective fails? My understanding on the history is based around > needing to have the partitions and data wiped so that the LVM groups > and other partition information does not interfere with the > installation process the next time the node is provisioned. That > might have been a side effect of cobbler and we should test if it's > still an issue for IBP. > > > Thanks, > -Alex > > [0] > https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb > > > Best regards, > > Svechnikov Artur > > > > > __ > > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] RabbitMQ in dedicated network
On Mon, Dec 28, 2015 at 1:13 AM Bogdan Dobrelya <bdobre...@mirantis.com> wrote: > On 23.12.2015 18:50, Matthew Mosesohn wrote: > > I agree. As far as I remember, rabbit needs fqdns to work and map > > correctly. I think it means we should disable the ability to move the > > internal messaging network role in order to fix this bug until we can > > add extra dns entries per network role (or at least addr) > > For DNS resolve, we could use SRV [0] records perhaps. > Although, nodes rely on /etc/hosts instead, AFAIK. > > So we could as well do net-template-based FQDNs instead, like > messaging-node*-domain.local 1.2.3.4 > corosync-node*-domain.local 5.6.7.8 > database-node*-domain.local 9.10.11.12 > > and rely on *these* FQDNS instead. > This is probably going to be the best way to work out this issue since we can move all of these services around as it is. I would attempt to remove the node identifier if possible so the names aren't wrong if the service is moved between nodes. > [0] https://en.wikipedia.org/wiki/SRV_record > > > > > On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <amaksi...@mirantis.com > > <mailto:amaksi...@mirantis.com>> wrote: > > > > Hi Kirill, > > > > I don't think we can give up on using fqdn node names for RabbitMQ > > because we need to support TLS in the future. > > > > Thanks, > > Andrey Maximov > > Fuel Project Manager > > > > On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov > > <kgala...@mirantis.com <mailto:kgala...@mirantis.com>> wrote: > > > > Hello, > > > > I would like to start discussion regarding the issue we have > > discovered recently [1]. > > > > In a nutshell, if RabbitMQ is configured to run in separate > > mgmt/messaging network it fails on building cluster. > > While RabbitMQ is managed by Pacemaker and OCF script, the > > cluster is built using FQDN. Apparently, FQDN resolves to admin > > network which is different in this particular case. > > As a result, RabbitMQ on secondary controller node fails to join > > to primary controller node. > > > > I can suggest two ways to tackle the issue: one is pretty > > simple, while other is not. > > > > The first way is to accept by design using admin network for > > RabbitMQ internal communication between controller nodes. > > > > The second way is to dig into pacemaker > > and RabbitMQ reconfiguration. Since it requires to refuse from > > using common fqdn/node names, this approach can be argued. > > > > > > -- > > [1] https://bugs.launchpad.net/fuel/+bug/1528707 > > > > Best regards, > > Kyrylo > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > < > http://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://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 > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Spec policy
We've been developing following the spec and blueprint approach for a while
and have even been firm with requiring "blueprint or bug" on commit
messages for a while now. However we have been more than neglecting the
specification ('spec') process. Quite often we see that a spec languishes
on review, sometimes its not reviewed, others it's not updated by the
other. In the end, its common that code lands in the component prior to the
spec being completed and merged its self. Furthermore this results in late
management of the blueprints in launchpad.
I propose that we start enforcing the implied spec requirement. At the same
time, we should be managing the blueprint status along with the spec so
that reviewers can quickly identify the status of the blueprint. Lastly, we
will need to clarify the role of the spec on the wiki as it's currently not
clear.
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
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] [Fuel] Meeting Schedule for Dec / Jan and Holidays
As we discussed in the meeting today, the normal meeting schedule of every Thursday overlaps with a number of holiday times Dec 24, Christmas Eve Dec 31, New Years Eve Jan 7, Russian Orthodox Christmas day // Part of New Years rest We agreed for the following schedule. Dec 24 will be moved to Dec 23. Dec 31 is canceled. Jan 7 is canceled. Jan 14, return to our normal schedule. For the Dec 23rd meeting, I will try look to see if there is an opening in the #openstack-meeting* rooms for us in our regular time slot, otherwise we will conduct the meeting on #fuel-dev -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel][plugins]Security problem in Fuel 7.0
I'd have to say that this is expected behavior. I'm not sure what you would hope to prohibit when these kinds of things are necessary for the deployment. We also can't prohibit this from being done in a plugin, this is what the plugin verification is supposed to help combat. If you just go download a random puppet manifest // script // etc... from the internet, how do you ensure that it didn't install a root-kit. On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin <ekore...@mirantis.com> wrote: > As far as I know this feature is planned for the next releases. > > But I think the main problem is: it's not obvious that just by installing > a plugin, even without enabling the plugin in Fuel user could break or > somehow alter already existing environments. It could be done by malicious > attacker who could compromise plugin or just unintentionally with some bug > in the plugin code. > > Unfortunately, by installing some plugin a user jeopardizes his existing > environments. And I think we should at least document these risks. > > > On 07.12.2015 19:52, Javeria Khan wrote: > > My two cents. It would be useful to have a role that could execute on the > Fuel Master host itself rather than a container. > > -- > Javeria > On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" <m...@romcheg.me> wrote: > >> Alexey, >> >> thank you for bringing this up. IMO discussing security problems is >> better to be done in a special kind of Launchpad bugs. >> >> - romcheg >> >> >> > 7 груд. 2015 р. о 17:36 Alexey Elagin <aela...@mirantis.com> >> написав(ла): >> > >> > Hello all, >> > >> > We have a security problem in Fuel 7.0. It's related to plugin >> > development and allows to execute code in mcollective docker container >> > on Fuel master node. Any fuel plugin may contains a yaml file with >> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is >> > an ability to run some code on node with role "master". It's also >> > possible to connect to any target node via ssh without a password from >> > within the container. >> > >> > As i understood, it was made to simplify some deployment cases. I see >> > some steps for resolving this situation: >> > 1. Fuel team should disallow >> > execution of any puppet manifests or bash code on nodes with master >> > role. >> > 2. Append the Fuel documentation. Notify users about this >> > security issue. >> > >> > What do you think about it? What deployment cases which require >> > execution of code on role "master" do you know? >> > >> > -- >> > Best regards, >> > Alexey >> > Deployment Engineer >> > Mirantis, Inc >> > Cell: +7 (968) 880 2288 >> > Skype: shikelbober >> > Slack: aelagin >> > mailto:aela...@mirantis.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 >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > Eugene Korekin > Partner Enablement Team Deployment Engineer > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel][plugins]Security problem in Fuel 7.0
Guys, we can not create any limitations on plugins ability to do things that we allow with the 'core' system. We need to be lees strict and more flexible with the plugin framework not constrict it randomly because there is a way to execute dangerous code. We are in the business of buiding, deploying, maintaining and erasing nodes. Everything we do, want to do, and want other to do is 'dangerous' we need to limit a users risk with verification of plugins not creating rules that limit functions plugins have access to. On Mon, Dec 7, 2015 at 11:36 AM Oleg Gelbukh <ogelb...@mirantis.com> wrote: > +1 to Eugene here. Eventually we will need to more strictly define Plugins > framework and SDK and limit possible actions to the set of supported ones. > This is required not only for security and/or stability reasons, but for > upgrade purposes as well. > > On the other hand, we need to retain certain flexibility of deployment. > That could be achieved by turning the 'core' components into pluggable > options, and reducing the 'core' to the set of replaceable plugins shipped > with the reference architecture. This will eliminate the need for many of > the hack used nowadays in plugins to override default behaviours. > > -- > Best regards, > Oleg Gelbukh > > On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin <ekore...@mirantis.com> > wrote: > >> Stas, >> >> I fear that often even developer of a code cannot verify his own code >> completely, let alone some third-party validation teams. Does the ability >> to strictly limit plugin actions by the list of intended environments looks >> nonviable to you? >> >> >> >> On 07.12.2015 20:38, Stanislaw Bogatkin wrote: >> >> +1 to Andrew. Plugins created for run some code and plugin verification >> is the source of trust there. >> >> On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward <xar...@gmail.com> wrote: >> >>> I'd have to say that this is expected behavior. I'm not sure what you >>> would hope to prohibit when these kinds of things are necessary for the >>> deployment. We also can't prohibit this from being done in a plugin, this >>> is what the plugin verification is supposed to help combat. If you just go >>> download a random puppet manifest // script // etc... from the internet, >>> how do you ensure that it didn't install a root-kit. >>> >>> On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin <ekore...@mirantis.com> >>> wrote: >>> >>>> As far as I know this feature is planned for the next releases. >>>> >>>> But I think the main problem is: it's not obvious that just by >>>> installing a plugin, even without enabling the plugin in Fuel user could >>>> break or somehow alter already existing environments. It could be done by >>>> malicious attacker who could compromise plugin or just unintentionally with >>>> some bug in the plugin code. >>>> >>>> Unfortunately, by installing some plugin a user jeopardizes his >>>> existing environments. And I think we should at least document these risks. >>>> >>>> >>>> On 07.12.2015 19:52, Javeria Khan wrote: >>>> >>>> My two cents. It would be useful to have a role that could execute on >>>> the Fuel Master host itself rather than a container. >>>> >>>> -- >>>> Javeria >>>> On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" < <m...@romcheg.me> >>>> m...@romcheg.me> wrote: >>>> >>>>> Alexey, >>>>> >>>>> thank you for bringing this up. IMO discussing security problems is >>>>> better to be done in a special kind of Launchpad bugs. >>>>> >>>>> - romcheg >>>>> >>>>> >>>>> > 7 груд. 2015 р. о 17:36 Alexey Elagin <aela...@mirantis.com> >>>>> написав(ла): >>>>> > >>>>> > Hello all, >>>>> > >>>>> > We have a security problem in Fuel 7.0. It's related to plugin >>>>> > development and allows to execute code in mcollective docker >>>>> container >>>>> > on Fuel master node. Any fuel plugin may contains a yaml file with >>>>> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is >>>>> > an ability to run some code on node with role "master". It's also >>>>> > possible to connect to any target node via ssh without a password >>>>> from >>&g
Re: [openstack-dev] [Fuel] Patch size limit
eviewGuidelines >> > [3] >> > >> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg07831.html >> > [4] http://docs.openstack.org/infra/manual/developers.html#peer-review >> > >> > >> > Best regards, >> > Andrey Tykhonov (tkhno) >> > >> > >> > >> __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://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://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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [puppet] [release] Puppet OpenStack 7.0.0 Liberty (_independent)
Fantastic to hear, good work guys. On Thu, Nov 26, 2015, 3:01 PM David Moreau Simard <d...@redhat.com> wrote: > Awesome ! > > Congratulations to everyone involved in the release of the most > popular deloyment method [1] :) > The new acceptance and integration tests make this rock solid, too ! > > [1]: > http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up > > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Thu, Nov 26, 2015 at 9:12 AM, Emilien Macchi <emil...@redhat.com> > wrote: > > Puppet OpenStack community is very proud to announce the release of 22 > > modules: > > > > puppet-aodh 7.0.0 > > puppet-ceilometer 7.0.0 > > puppet-cinder 7.0.0 > > puppet-designate 7.0.0 > > puppet-glance 7.0.0 > > puppet-gnocchi 7.0.0 > > puppet-heat 7.0.0 > > puppet-horizon 7.0.0 > > puppet-ironic 7.0.0 > > puppet-keystone 7.0.0 > > puppet-manila 7.0.0 > > puppet-murano 7.0.0 > > puppet-neutron 7.0.0 > > puppet-nova 7.0.0 > > puppet-openstacklib 7.0.0 > > puppet-openstack_extras 7.0.0 > > puppet-sahara 7.0.0 > > puppet-swift 7.0.0 > > puppet-tempest 7.0.0 > > puppet-trove 7.0.0 > > puppet-tuskar 7.0.0 > > puppet-vswitch 3.0.0 > > > > For more details about the release, you can visit: > > https://wiki.openstack.org/wiki/Puppet/releases > > https://forge.puppetlabs.com/openstack > > > > Here are some interesting numbers [1]: > > > > Contributors during Kilo cycle: 91 > > Contributors during Liberty cycle: 108 > > > > Commits during Kilo cycle: 730 > > Commits during Liberty cycle: 1201 > > > > LOC during Kilo cycle: 67104 > > LOC during Liberty cycle: 93448 > > > > [1] Sources: http://stackalytics.openstack.org > > > > Thank you to the Puppet OpenStack community to make it happen, > > Also big kudos to other teams, specially OpenStack Infra, Tempest and > > Packaging folks who never hesitate to help us. > > -- > > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Getting rid of Docker containers on the Fuel master node
IMO, removing the docker containers is a mistake v.s. fixing them and using them properly. They provide an isolation that is necessary (and that we mangle) to make services portable and scaleable. We really should sit down and document how we really want all of the services to interact before we rip the containers out. I agree, the way we use containers now still is quite wrong, and brings us some negative value, but I'm not sold on stripping them out now just because they no longer bring the same upgrades value as before. My opinion aside, we are rushing into this far to late in the feature cycle. Prior to moving forward with this, we need a good QA plan, the spec is quite light on that and must receive review and approval from QA. This needs to include an actual testing plan. >From the implementation side, we are pushing up against the FF deadline. We need to document what our time objectives are for this and when we will no longer consider this for 8.0. Lastly, for those that are +1 on the thread here, please review and comment on the spec, It's received almost no attention for something with such a large impact. On Tue, Nov 24, 2015 at 4:58 PM Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > The status is as follows: > > 1) Fuel-main [1] and fuel-library [2] patches can deploy the master node > w/o docker containers > 2) I've not built experimental ISO yet (have been testing and debugging > manually) > 3) There are still some flaws (need better formatting, etc.) > 4) Plan for tomorrow is to build experimental ISO and to begin fixing > system tests and fix the spec. > > [1] https://review.openstack.org/#/c/248649 > [2] https://review.openstack.org/#/c/248650 > > Vladimir Kozhukalov > > On Mon, Nov 23, 2015 at 7:51 PM, Vladimir Kozhukalov < > vkozhuka...@mirantis.com> wrote: > >> Colleagues, >> >> I've started working on the change. Here are two patches (fuel-main [1] >> and fuel-library [2]). They are not ready to review (still does not work >> and under active development). Changes are not going to be huge. Here is a >> spec [3]. Will keep the status up to date in this ML thread. >> >> >> [1] https://review.openstack.org/#/c/248649 >> [2] https://review.openstack.org/#/c/248650 >> [3] https://review.openstack.org/#/c/248814 >> >> >> Vladimir Kozhukalov >> >> On Mon, Nov 23, 2015 at 3:35 PM, Aleksandr Maretskiy < >> amarets...@mirantis.com> wrote: >> >>> >>> >>> On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya <bdobre...@mirantis.com >>> > wrote: >>> >>>> On 23.11.2015 12:47, Aleksandr Maretskiy wrote: >>>> > Hi all, >>>> > >>>> > as you know, Rally runs inside docker on Fuel master node, so docker >>>> > removal (good improvement) is a problem for Rally users. >>>> > >>>> > To solve this, I'm planning to make native Rally installation on Fuel >>>> > master node that is running on CentOS 7, >>>> > and then make a step-by-step instruction how to make this >>>> installation. >>>> > >>>> > So I hope docker removal will not make issues for Rally users. >>>> >>>> I believe the most backwards compatible scenario is to keep the docker >>>> installed while removing the fuel-* docker things back to the host OS. >>>> So nothing would prevent user from pulling and running whichever docker >>>> containers he wants to put on the Fuel master node. Makes sense? >>>> >>>> >>> Sounds good >>> >>> >>> __ >>> 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [ceph] Puppet Ceph CI
I think I have a good lead on the recent failures in openstack / swift / radosgw integration component that we have since disabled. It looks like there is a oslo.config version upgrade conflict in the Juno repo we where using for CentOS. I think moving to Kilo will help sort this out, but at the same time I think it would be prudent to separate the Ceph v.s. OpenStack integration into separate jobs so that we have a better idea of which is a problem. If there is census for this, I'd need some direction / help, as well as set them up as non-voting for now. Looking into this I also found that the only place that we do integration any of the cephx logic was in the same test so we will need to create a component for it in the ceph integration as well as use it in the OpenStack side. Lastly un-winding the integration failure seemed overly complex. Is there a way that we can correlate the test status inside the job at a high level besides the entire job passed / failed without breaking them into separate jobs? -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Number of IP addresses in a public network
//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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Andrey Danin > ada...@mirantis.com > skype: gcon.monolake > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Add Fuel to OpenStack projects: status update
; to fully align our CI with OpenStack Infra. > > > > [2] > http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2015-11-10.log.html#t2015-11-10T21:03:34 > > > > Still, I believe that making this a hard requirement for Fuel's > > acceptance into Big Tent would be one step too far down a slippery slope > > into a whole new vat of worms. Objective inclusion criteria such as > > Project Requirements and Project Testing Interface are there to protect > > OpenStack contributors from real and perceived favouritism. Declaring, > > especially selectively, that meeting these criteria may be insufficient, > > takes all the objectivity out of them. Fortunately, Jim did not insist > > on making progress with Fuel multi-node tests a hard requirement and > > confirmed that he will not block our proposal based on that. He still > > wants us to finish setting up gates, though, fair is fair. > > > > Finally, the odd one out was the objection from Dean Troyer: "re Fuel, > > I'm just not convinced it fits OpenStack's mission... we generally have > > stayed away from being a distro". It was quickly dismissed by other > > participants, but Dean still abstained, putting us one more vote short > > of approval. I think this serves to illustrate that many prominent > > members of OpenStack community still view Fuel as an OpenStack > > distribution, even after the two years we've spent establishing Fuel as > > a toolset for deployment and operation of OpenStack environments, > > decoupled from whatever Linux and OpenStack distributions you choose to > > deploy with it. I can only hope that Fuel is accepted into Big Tent and > > more distributions are encouraged to use it, so that this particular > > confusion is finally laid to rest. > > > > Some of you may be surprised by how much scrutiny Fuel is facing when > > compared to smaller and younger projects. In a way, Fuel is a victim of > > its own success: we've got so many components and such an extensive and > > diverse CI coverage that bringing all that into compliance with The > > OpenStack Way is really that much more work than it is for a typical new > > project with just one git repo and a handful of unit test jobs. Don't be > > discouraged by this additional delay: Fuel is big and has a lot of value > > to bring into OpenStack on many levels, Technical Committee is > > appreciative of that and supportive of our efforts, additional scrutiny > > is there because they want to get this right. Lets prove that their > > trust in us is not misplaced. > > > > -- > > Dmitry Borodaenko > > > > > __ > > 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 > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [puppet] [ceph] puppet-ceph working session
Thanks, I've added it to the puppet-code session etherpad. https://etherpad.openstack.org/p/HND-puppet-code On Wed, Oct 28, 2015 at 12:00 PM Emilien Macchi <emilien.mac...@gmail.com> wrote: > > > On 10/28/2015 11:09 AM, Andrew Woodward wrote: > > For those of you interested at the summit, I'd like to get together at > > some point and discuss / resolve issues on CI, and then talk about > > release and possible roadmap. > > > > Let's pick a time so that we can meet together on this. > > Good idea, I suggest we meet in the Puppet work sessions, so we get > attention from the team. > > Thanks, > > Emilien > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [ceph] puppet-ceph working session
For those of you interested at the summit, I'd like to get together at some point and discuss / resolve issues on CI, and then talk about release and possible roadmap. Let's pick a time so that we can meet together on this. Andrew __ 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] [Fuel] Assigning VIPs on network config serialization
__ > > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins
We have already discussed this to be a result of describing data driven testing, untill this spec is completed there is little sense to remove all of these since fuel-qa is 100% required to operate this way. In the interim we should just specify the appropriate SME with the MAINTAINERS file. On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <sgolovat...@mirantis.com> wrote: > Tests should be in plugin > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier <spasqu...@mirantis.com> > wrote: > >> Hello Alexey, >> >> On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin <aela...@mirantis.com> >> wrote: >> >>> Hello Simon! >>> >>> We are going to remove plugins' functional tests from fuel-qa because >>> this tests don't use for our plugins CI process. >>> >> >> And where are the existing tests going to be stored then? >> >> Thanks, >> Simon >> >> >>> >>> >>> __ >>> 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] FW: [Fuel] 8.0 Region name support / Multi-DC
ed to comment here. >>> >>> >>> >>> Regarding specifying region names in UI, is it possible to specify >>> region names in API? And (apologies for my ignorance on this one) what is >>> the relative equivalence to environments in Fuel (e.g. 1 environment : many >>> regions, 1 environment == 1 region)? >>> >>> >>> >>> *From:* Roman Sokolkov [mailto:rsokol...@mirantis.com] >>> *Sent:* Friday, October 02, 2015 5:26 PM >>> *To:* OpenStack Development Mailing List (not for usage questions) < >>> openstack-dev@lists.openstack.org> >>> *Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC >>> >>> >>> >>> Folks, >>> >>> >>> >>> i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC >>> support. >>> >>> >>> >>> My ask is about tiny(but useful) feature: give user ability to *specify >>> Region name in UI.* >>> >>> >>> >>> Region name is already in every puppet module, so we just need to add >>> this to UI. >>> >>> >>> >>> Do we have smth already? >>> >>> >>> >>> More general question: What are our plans in regards Multi-DC? >>> >>> >>> >>> Thanks >>> >>> >>> >>> -- >>> >>> Roman Sokolkov, >>> >>> Deployment Engineer, >>> >>> Mirantis, Inc. >>> Skype rsokolkov, >>> rsokol...@mirantis.com >>> >>> -- >>> >>> Chris Clason >>> >>> Director of Architecture >>> >>> ccla...@mirantis.com >>> >>> Mobile: +1.408.409.0295 >>> >>> >>> __ >>> 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 >>> >>> >> >> >> -- >> Roman Sokolkov, >> Deployment Engineer, >> Mirantis, Inc. >> Skype rsokolkov, >> rsokol...@mirantis.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 >> >> > > > -- > Adam Heczko > Security Engineer @ Mirantis Inc. > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Problems with mcollective offline nodes
[ Was: Re: [openstack-dev] OpenStack-dev Digest, Vol 41, Issue 49] Santosh Parihar, This implies that the nodes are (in order of most to least likely): a) currently offline b) un-accessible from the fuel master node c) the mcollective agent is not running on them d) rabbitmq on the fuel node (rabbitmq container) is not functioning properly Fuel uses mcollective (MCO) to issue commands to remote nodes. You can start by pining the nodes, from the CLI you can issue `fuel node` and it will show the nodes id, and IP address. From there you can use `mco ping` to determine if mcollective can talk to the nodes. From there you can triage individual nodes connectivity, or restart them. Alternately you can investigate and restart the mcollective and or rabbitmq containers. We are also on IRC #Fuel on irc.freenode.net. We have alot of the European folks on around when you posted this message so you can drop a line in there if you would like to get some more interactive help. - Andrew Fuel Community. On Mon, Oct 5, 2015 at 1:55 AM santosh parihar <santosh.parih...@gmail.com> wrote: > Topic - Fuel > > Hi, > > My deployment is failing beacuse of following reason : > > Verification failed. > Method verify_networks. Network verification not avaliable because nodes > ["3", "4", "6", "7"] not avaliable via mcollective. Inspect Astute logs for > the details > > anybody can help here ? > > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [puppet] [infra] split integration jobs
Emillien, What image is being used to spawn the image? We see 300 sec as a good timeout time in fuel with a cirros image. The time can usually be substantially cut if the image is of any size using ceph for ephemeral... On Wed, Sep 30, 2015 at 4:37 PM Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2015-09-30 17:14:27 -0400 (-0400), Emilien Macchi wrote: > [...] > > I like #3 but we are going to consume more CI resources (that's why I > > put [infra] tag). > [...] > > I don't think adding one more job is going to put a strain on our > available resources. In fact it consumes just about as much to run a > single job twice as long since we're constrained on the number of > running instances in our providers (ignoring for a moment the > spin-up/tear-down overhead incurred per job which, if you're > talking about long-running jobs anyway, is less wasteful than it is > for lots of very quick jobs). The number of puppet changes and > number of jobs currently run on each is considerably lower than a > lot of our other teams as well. > -- > Jeremy Stanley > > __ > 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [puppet] Moving puppet-ceph to the Openstack big tent
[I'm cross posting this to the other Ceph threads to ensure that it's seen] We've discussed this on Monday on IRC and again in the puppet-openstack IRC meeting. The current census is that we will move from the deprecated stackforge organization and will be moved to the openstack one. At this time we will not be perusing membership as a formal OpenStack project. This will allow puppet-ceph to retain the tight relationship with OpenStack community and tools for the time being. On Mon, Sep 28, 2015 at 8:32 AM David Moreau Simard <d...@redhat.com> wrote: > Hi, > > puppet-ceph currently lives in stackforge [1] which is being retired > [2]. puppet-ceph is also mirrored on the Ceph Github organization [3]. > This version of the puppet-ceph module was created from scratch and > not as a fork of the (then) upstream puppet-ceph by Enovance [4]. > Today, the version by Enovance is no longer officially maintained > since Red Hat has adopted the new release. > > Being an Openstack project under Stackforge or Openstack brings a lot > of benefits but it's not black and white, there are cons too. > > It provides us with the tools, the processes and the frameworks to > review and test each contribution to ensure we ship a module that is > stable and is held to the highest standards. > But it also means that: > - We forego some level of ownership back to the Openstack foundation, > it's technical committee and the Puppet Openstack PTL. > - puppet-ceph contributors will also be required to sign the > Contributors License Agreement and jump through the Gerrit hoops [5] > which can make contributing to the project harder. > > We have put tremendous efforts into creating a quality module and as > such it was the first puppet module in the stackforge organization to > implement not only unit tests but also integration tests with third > party CI. > Integration testing for other puppet modules are just now starting to > take shape by using the Openstack CI inrastructure. > > In the context of Openstack, RDO already ships with a mean to install > Ceph with this very module and Fuel will be adopting it soon as well. > This means the module will benefit from real world experience and > improvements by the Openstack community and packagers. > This will help further reinforce that not only Ceph is the best > unified storage solution for Openstack but that we have means to > deploy it in the real world easily. > > We all know that Ceph is also deployed outside of this context and > this is why the core reviewers make sure that contributions remain > generic and usable outside of this use case. > > Today, the core members of the project discussed whether or not we > should move puppet-ceph to the Openstack big tent and we had a > consensus approving the move. > We would also like to hear the thoughts of the community on this topic. > > Please let us know what you think. > > Thanks, > > [1]: https://github.com/stackforge/puppet-ceph > [2]: https://review.openstack.org/#/c/192016/ > [3]: https://github.com/ceph/puppet-ceph > [4]: https://github.com/redhat-cip/puppet-ceph > [5]: https://wiki.openstack.org/wiki/How_To_Contribute > > David Moreau Simard > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Weekly IRC meeting 9/24
As a reminder, the weekly IRC meeting is scheduled for 16:00 UTC Tomorrow in #openstack-meeting-alt Please review meeting agenda and update if there is something you wish to discuss. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Meeting 8/6
Please note the IRC meeting is scheduled for 16:00 UTC Tomorrow in #openstack-meeting-alt Please review meeting agenda and update if there is something you wish to discuss. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Meeting 7/30
Please note the IRC meeting is scheduled for 16:00 UTC (about 1 hour from now) in #openstack-meeting-alt Please review meeting agenda and update if there is something you wish to discuss. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [puppet] Parameters possible default value
On Thu, Jul 30, 2015 at 3:36 AM Sebastien Badia sba...@redhat.com wrote:
On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
Sorry, I forgot to finish this up and send it out.
#--SNIP--
def absent_default(
$value,
$default,
$unset_when_default = true,
){
if ( $value == $default ) and $unset_when_default {
# I cant think of a way to deal with this in a define so lets pretend
# we can re-use this with multiple providers like we could if this
was
# in the actual provider.
keystone_config {$name: ensure = absent,}
} else {
keystone_config {$name: value = $value,}
}
}
# Usage:
absent_default{'DEFAULT/foo': default = 'bar', value = $foo }
Hi,
Hum, but you want to add this definition in all our modules, or directly in
openstacklib?
I only mocked it up in a puppet define, because its easier for me (my ruby
is terrible) It should be done by adding these kinds of extra providers to
the inifile provider override that Yanis proposed.
In case of openstacklib, in which manner do you define the
component_config
resource? (eg, generic def, but specialized resource).
#--SNIP--
(I threw this together and haven't tried to run it yet, so It might not
run
verbatim, I will create a test project with it to show it working)
So In the long-term we should be able to add some new functionality to
the
inifile provider to simply just do this for us. We can add the 'default'
and 'unset_when_default' parameter so that we can use them straight w/o a
wrapping function (but the warping function could be used too). This
would
give us the defaults (I have an idea on that too that I will try to put
into the prototype) that should allow us to have something that looks
quite
clean, but is highly functional
Keystone_config{unset_when_default = true} #probably flatly enabled in
our inifile provider for the module
keystone_config {'DEFAULT/foo': value = 'bar', default = 'bar'}
I'm not sure to see the difference with the Yanis solution here¹, and not
sure
to see the link between the define resource and the type/provider resource.
This adds on to Yanis' solution so that we can authoritatively understand
what the default value is, and how it should be treated (instead of hoping
some magic word doesn't conflict)
Seb
¹https://review.openstack.org/#/c/202574/
--
Sebastien Badia
__
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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
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] [fuel] OS_SERVICE_TOKEN usage in Fuel
IIRC the puppet modules, and even the heat domain create script make use of the token straight from the config file. It not being present could cause problems for some of the manifests. We would need to ensure that their usage is minimized or removed. On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi Oleksiy, Good catch. Also OSTF should get endpoints from hiera as some plugins may override the initial deployment settings. There may be cases when keystone is detached by plugin. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov omolcha...@mirantis.com wrote: Hello all, We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619. I guess not all of us have an access to this bug, so to be short: # A shared secret that can be used to bootstrap Keystone. # This token does not represent a user, and carries no # explicit authorization. To disable in production (highly # recommended), remove AdminTokenAuthMiddleware from your # paste application pipelines (for example, in keystone- # paste.ini). (string value) After removing this and testing we found out that OSTF fails because it uses admin token. What do you think if we create ostf user like for workloads, but with wider permissions? BR, Oleksiy. __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] OS_SERVICE_TOKEN usage in Fuel
It's literally how radosgw goes about verifying users, it has no scheme of using a user or working with auth-tokens. It would have to fixed in the ceph-radosgw codebase. PKI tokens (which we don't use) rely on this less, but its still used. On Tue, Jul 28, 2015 at 2:16 PM Sergii Golovatiuk sgolovat...@mirantis.com wrote: Why can't radosgw use own own credentials? If it's technical debt we need to put it on plate to address in next release. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 28, 2015 at 10:21 PM, Andrew Woodward xar...@gmail.com wrote: Keystone authtoken is also used by radosgw to validate users On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward awoodw...@mirantis.com wrote: IIRC the puppet modules, and even the heat domain create script make use of the token straight from the config file. It not being present could cause problems for some of the manifests. We would need to ensure that their usage is minimized or removed. On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi Oleksiy, Good catch. Also OSTF should get endpoints from hiera as some plugins may override the initial deployment settings. There may be cases when keystone is detached by plugin. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov omolcha...@mirantis.com wrote: Hello all, We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619. I guess not all of us have an access to this bug, so to be short: # A shared secret that can be used to bootstrap Keystone. # This token does not represent a user, and carries no # explicit authorization. To disable in production (highly # recommended), remove AdminTokenAuthMiddleware from your # paste application pipelines (for example, in keystone- # paste.ini). (string value) After removing this and testing we found out that OSTF fails because it uses admin token. What do you think if we create ostf user like for workloads, but with wider permissions? BR, Oleksiy. __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] OS_SERVICE_TOKEN usage in Fuel
Keystone authtoken is also used by radosgw to validate users On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward awoodw...@mirantis.com wrote: IIRC the puppet modules, and even the heat domain create script make use of the token straight from the config file. It not being present could cause problems for some of the manifests. We would need to ensure that their usage is minimized or removed. On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi Oleksiy, Good catch. Also OSTF should get endpoints from hiera as some plugins may override the initial deployment settings. There may be cases when keystone is detached by plugin. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov omolcha...@mirantis.com wrote: Hello all, We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619. I guess not all of us have an access to this bug, so to be short: # A shared secret that can be used to bootstrap Keystone. # This token does not represent a user, and carries no # explicit authorization. To disable in production (highly # recommended), remove AdminTokenAuthMiddleware from your # paste application pipelines (for example, in keystone- # paste.ini). (string value) After removing this and testing we found out that OSTF fails because it uses admin token. What do you think if we create ostf user like for workloads, but with wider permissions? BR, Oleksiy. __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Fuel plugin as docker containers images
I'm still confused are you wanting to add a container to the master node, or a deployed env? For the master node, the latest fuel-plugin-builder allows for post-install scripts, you could load a container image from here For nodes in a deployed ENV, there is no formal target to support containers, you would need to install the container manager and containers yourself. However I would note that not packaging the applications dependencies because it's in a container is not a good practice as it quickly becomes very difficult to work with versioning and updates. It may be acceptable for a dev build of the plugin, but should be avoided in validated versions of the plugin. The container its self should also be contained within a package so that it's versioning can be tracked with operator familiar tools. Lastly, containers with python are quite large, so if you can get the versioning to work I'd avoid putting it into a container all together as you will end up with 150-300mb container mostly just because of python. On Tue, Jul 28, 2015 at 7:26 AM Konstantin Danilov kdani...@mirantis.com wrote: Evgene, I'm sure you understand this, but just to be clear - now FUEL uses containers on master node, not on cluster nodes. I'm asking about plugin containers on cluster nodes. Yep, there a particular example - VSM (Intel ceph management tool). It requires a set of packages, like python2.6, old django, etc, which I would rather not install on master node directly. Thanks On Tue, Jul 28, 2015 at 10:47 AM, Evgeniy L e...@mirantis.com wrote: Hi Konstantin, I'm not sure if we track such feature anywhere. But one of the reasons to use containers on the master was to deliver plugin specific containers, so they don't intersect and don't break Fuel master dependencies. Do you have some specific use case for that? Thanks, On Mon, Jul 27, 2015 at 4:58 PM, Konstantin Danilov kdani...@mirantis.com wrote: Hi, Is there a plans to allow plugin to be delivered as docker container images? Thanks -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.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 -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [puppet] Parameters possible default value
Sorry, I forgot to finish this up and send it out.
#--SNIP--
def absent_default(
$value,
$default,
$unset_when_default = true,
){
if ( $value == $default ) and $unset_when_default {
# I cant think of a way to deal with this in a define so lets pretend
# we can re-use this with multiple providers like we could if this was
# in the actual provider.
keystone_config {$name: ensure = absent,}
} else {
keystone_config {$name: value = $value,}
}
}
# Usage:
absent_default{'DEFAULT/foo': default = 'bar', value = $foo }
#--SNIP--
(I threw this together and haven't tried to run it yet, so It might not run
verbatim, I will create a test project with it to show it working)
So In the long-term we should be able to add some new functionality to the
inifile provider to simply just do this for us. We can add the 'default'
and 'unset_when_default' parameter so that we can use them straight w/o a
wrapping function (but the warping function could be used too). This would
give us the defaults (I have an idea on that too that I will try to put
into the prototype) that should allow us to have something that looks quite
clean, but is highly functional
Keystone_config{unset_when_default = true} #probably flatly enabled in
our inifile provider for the module
keystone_config {'DEFAULT/foo': value = 'bar', default = 'bar'}
On Mon, Jul 27, 2015 at 3:06 AM Yanis Guenane yguen...@redhat.com wrote:
On 07/20/2015 10:07 AM, Martin Mágr wrote:
Hey Yanis
On 07/17/2015 10:56 AM, Yanis Guenane wrote:
Hello everyone,
if set the value would have been set else it would default to upstream
default.
But Mathieu raised a fair point here[2] is that an empty string for some
settings is a valid value, and hence we can't rely on
it.
Since the beginning we are trying to avoid the use of a magic string,
but
I am starting to run out of idea here.
Does someone has an idea on which sane value the default could be ?
How about '*config_default*'? Or whatever similar which says you want
the default value, but will potentially never be value of any parameter.
Regards,
Martin
Thanks in advance,
[1] https://review.openstack.org/#/c/202488
[2] https://review.openstack.org/#/c/202574
--
Yanis Guenane
__
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
Following on the thread, and following the discussion that took place
during last week meeting[1],
The patchset[2] and the example[3] have been updated not to ensure
absent for a nil string due to its valid usage in some cases,
but to ensure absent when 'SERVICE DEFAULT' is specified. Based on the
community feedback this string
isn't used across any component.
During the meeting xarses had an alternative idea, if once mocked up you
could send a follow-up mail in this
thread so we can grasp the idea.
@Mathieu: if the new approach is ok with you, could you please review
your -2 on that patchset
Thanks in advance for your feedbacks,
[1]
http://eavesdrop.openstack.org/meetings/puppet/2015/puppet.2015-07-21-14.59.log.html
[2] https://review.openstack.org/#/c/202574/
[3] https://review.openstack.org/#/c/202513/
--
Yanis Guenane
__
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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
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] [fuel] FF Exception request for Templates for Networking feature
-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 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 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] FFE requests and status
Current FFE request status: FFE for bug/1475759 ceph generators - PENDING Approval FF Exception request for Fernet tokens support. - DECLINED FF Exception request for Custom node attributes feature - APPROVED, MERGED FF Exception request for Templates for Networking feature - APPROVED FF Exception for LP-1464656 fix (update ceph PG calculation algorithm) - PENDING Approval FF Exception request for Env Upgrade feature - APPROVED FF Exception request for Deploy nova-compute (VCDriver) feature - PENDING Approval On Thu, Jul 23, 2015 at 12:17 PM Mike Scherbakov mscherba...@mirantis.com wrote: Thanks Andrew. I'd like to add that after there is an announcement about FF, all core reviewers should stop getting patches into master which are parts of features or extensions. We expect only bugfixes. If there is anything else, we need to be very transparent about it, and have them in public place like here. In the past, we had a practice when developers would continue to work on enhancements instead of bugs, and cores would support it. And in fact, FF moves to SCF - and we have to slip our release. Let's not do this again. On Thu, Jul 23, 2015 at 11:56 AM Andrew Woodward xar...@gmail.com wrote: In case you missed it, feature freeze is today and in the rush to merge things, you may have had issues with getting everything landed. For those that are not familiar with the process, to request a feature freeze exception (FFE): * You will need to raise the request to the ML here and in such message - Include [Fuel] FFE request + feature name in the subject - Document what is outstanding (Link to CR's), what's their state - Link to blueprint - Document impact of outstanding changes - Document how long you expect before it can lang * You will also need to get two of the cores in the repo(s) impacted by outstanding reviews to sponsor reviewing the outstanding CR's * Finally PTL will approve each FFE request. Please do not ask for a FFE in this thread I will update this thread with approved FFE's as they occur -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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 -- Mike Scherbakov #mihgen __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Acting PTL for Fuel - Dmitry Borodaenko
I'd like to point out as part of our on-going effort to more formally align with the openstack governance practices, Dmitry Borodaenko has taken up the reins as PTL for fuel as this aligns with his current leadership role in the project. We have agreed that we will open for nominations and voting After HCF (towards the end of the 7.0 release cycle in September) -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] FF Exception for LP-1464656 fix (update ceph PG calculation algorithm)
+1 for FFE Given how borken pg_num calculations are now, this is essential to the ceph story and there is no point in testing ceph at scale with out it. The only work-around for not having this is to delete all of the pools by hand after deployment and calculate the values by hand, and re-create the pools by hand. The story from that alone makes it high on the UX scale, which means we might as well fix it as a bug. The scope of impact is limited to only ceph, the testing plan needs more detail, and we are still comming to turns with some of the data format to process between nailgun calculating and puppet consuming. We would need about 1.2 week to get these landed. On Fri, Jul 24, 2015 at 3:51 AM Konstantin Danilov kdani...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for [1] fix. It requires changes in fuel-web [2], fuel-library [3] and in UI. [2] and [3] are already tested, I'm fixing UT now. BP - [4] Code has backward-compatibility mode. I need one more week to finish it. Also I'm asking someone to be an assigned code-reviewer for this ticket to speed-up review process. Thanks [1] https://bugs.launchpad.net/fuel/+bug/1464656 [2] https://review.openstack.org/#/c/204814 [3] https://review.openstack.org/#/c/204811 [4] https://review.openstack.org/#/c/203062 -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] FFE for bug/1475759 ceph generators
I'm writing to ask for a FFE for landing the ceph generators. It finally received core-reviewers attention late on Wednesday and Thursday and is ready to merge now. I'm only asking for FFE because reviewers are calling this a feature. Possible impact, none. This is not used by anything yet and should be merged. [1] https://bugs.launchpad.net/fuel/+bug/1475759 [2] https://review.openstack.org/#/c/203270/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] version.yaml in the context of packages
Vladimir, I agree that the content of this file nearly completely depreciated, but slightly disagree with removing it entirely. I think the data should be moved from a single static file like you see here, to something that reads the data from the underlying packages and can still show all of the information in one place (/api/version). So we can, and should do away with this file but we need the data in the api response, and saved in the diag snapshot. So my comments below are about possibly keeping these around, but not in the file On Fri, Jul 24, 2015 at 10:25 AM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1 astute_sha: b1f37a988e097175cbbd14338286017b46b584c3 fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4 fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39 Let's go through this file. 1) *feature_groups* - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. This should just be expressed as a value in the DB, it never made sense to store this in a file since it's runtime state 2) *production* - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. there is no longer not docker, so just drop it. 3) *release *- It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. 4) *openstack_version *- It is just an extraction from openstack.yaml [2]. 5) *api *- It is 1.0 currently. And we still don't have other versions of API. Frankly, it contradicts to the common practice to make several different versions available at the same time. And a user should be able to ask API which versions are currently available. 6) *build_number *and *build_id *- These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. These are useful to track which iso the issue occurred in and if my iso or another might have the issue. I find it the attributes I use the most in this data. Again is un-related to packages so it should only be copied off the iso for development reasons 7) *X_sha* - This does not even require any explanation. It should be rpm -qa instead. We need this information. It can easily be replaced with the identifier from the package, but it still needs to describe source. We need to know exactly which commit was the head. It's solved many other hard to find problems that we added it for in the first place I am raising this topic, because it is kind of blocker for switching to package based upgrades. Our current upgrade script assumes we have this file version.yaml in the tarball and we put this new file instead of old one during upgrade. But this file could not be packaged into rpm because it can only be built together with ISO. [1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml Vladimir Kozhukalov __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
On Fri, Jul 24, 2015 at 2:12 AM Evgeniy L e...@mirantis.com wrote:
Hi Andrew,
I don't agree with you, user should be able to name the node any way he
wants why there should be a constraint which is related to some internal id
in Nailgun database? For example if he deleted node-5 and then he wants
to replace this node with another one, he can and should be able to provide
for this replacement node hostname node-5, even if node's id in the
database
is 6.
No, its easier to just change the node id in the database to 5 if that is
what they want. We own the namespace 'node-node.id' schema. If they want
to use that schema then they have to update node.id in the database. We
have multiple areas in the code where we do special things based on the ID
of the node (like primary member of role). If they wanted to replace the
node and get the old host-name back then there is a very high chance that
the expect it to continue to have these special functions applied to them
I don't know why we want to create a custom conflict resolution scheme here
when we can reasonably say its not allowed.
There are things we have to check now which increases the complication when
we allow this.
A) As a pre-requisite to setting any hostname, we must now generate all of
the hostnames so that we can check if there is a node-node.id conflict.
B) After (A) and we find that there are no conflicts we can now set the
host name
C) New node is added to the cluster with id that now conflicts with the
node.id format for this name (higher or lower is possible) how do we want
to generate new nodes hostname. We dont want to fail the deployment because
of it so we have to resort to some weird naming scheme like discussed here.
But what happens if user doesn't want that ugly name if we do this
automatically then they could end up with some ugly name that they then
have to erase the node before they can change.
Seems like a waste of time to me. We can avoid this all by simply asking
the user to change the node.id in the database so that this complicated
stuff can be avoided
Thanks,
On Fri, Jul 24, 2015 at 2:36 AM, Andrew Woodward xar...@gmail.com wrote:
On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev fzhad...@mirantis.com
wrote:
Thanks for your answers.
Let me clarify some points:
Sure, we have to validate hostnames during node renaming. And sure we do
it. This issue appears when we already have node with name 'node-X' and new
node is created without providing custom name. I'll give you the example:
1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
with ID 4) ;
2. He renames it in 'node-5' (this name is correct and unique. OK)
3. He adds new node without providing custom hostname.
New node gets ID = 5 (it's primary key and increments automatically)
and default hostname 'node-5'. (Here we have a problem with uniqueness.)
It will be strange if we refuse to create node with default name if
somebody has renamed another node using this name.
About nodes hostnames. Actually we can't refuse to use custom hostnames
in format 'node-{#}' because it is one of the main use cases. So we need to
find the solution which accepts such renaming.
How is this a main use case? This is exactly what we should not support.
If they want the node to have 'node-5' as it's hostname we need them to be
node.id = 5 (IE the node id in the DB is 5) They would not need custom
node naming in this case.
2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:
Hi guys,
@Sergii, it looks like you misunderstood something. `node-uuid` is not
a general use case. It's only about conflicting nodes, and I'm sure
everyone's going to change such a hostname in order to avoid
confusion.
@Andrew,
a) Database refuses hostnames that break unique constraint, sot it'll
work out-of-box.
b) I like this idea. I think refusing `node-id` where `id` is not
actually a node id is good idea. It solves our problem.
Thanks,
Igor
On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
node-uuid is very terrible from UX perspective of view. Ask support
people
if they are comfortable to ssh such nodes or telling the name in phone
conversation with customer. If we cannot validate FQDN of hostname I
would
slip this feature to next release where we can pay more attention to
details.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev fzhad...@mirantis.com wrote:
Thanks for your answers.
Let me clarify some points:
Sure, we have to validate hostnames during node renaming. And sure we do
it. This issue appears when we already have node with name 'node-X' and new
node is created without providing custom name. I'll give you the example:
1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
with ID 4) ;
2. He renames it in 'node-5' (this name is correct and unique. OK)
3. He adds new node without providing custom hostname.
New node gets ID = 5 (it's primary key and increments automatically)
and default hostname 'node-5'. (Here we have a problem with uniqueness.)
It will be strange if we refuse to create node with default name if
somebody has renamed another node using this name.
About nodes hostnames. Actually we can't refuse to use custom hostnames in
format 'node-{#}' because it is one of the main use cases. So we need to
find the solution which accepts such renaming.
How is this a main use case? This is exactly what we should not support. If
they want the node to have 'node-5' as it's hostname we need them to be
node.id = 5 (IE the node id in the DB is 5) They would not need custom node
naming in this case.
2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:
Hi guys,
@Sergii, it looks like you misunderstood something. `node-uuid` is not
a general use case. It's only about conflicting nodes, and I'm sure
everyone's going to change such a hostname in order to avoid
confusion.
@Andrew,
a) Database refuses hostnames that break unique constraint, sot it'll
work out-of-box.
b) I like this idea. I think refusing `node-id` where `id` is not
actually a node id is good idea. It solves our problem.
Thanks,
Igor
On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
node-uuid is very terrible from UX perspective of view. Ask support
people
if they are comfortable to ssh such nodes or telling the name in phone
conversation with customer. If we cannot validate FQDN of hostname I
would
slip this feature to next release where we can pay more attention to
details.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
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
--
Kind Regards,
Fedor Zhadaev
Junior Software Engineer, Mirantis Inc.
Skype: zhadaevfm
E-mail: fzhad...@mirantis.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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
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] [fuel][puppet] Module Sync for Murano and Sahara
Denis, Now that I have better understanding of the history of the commit, I understand that this was the best way through. The Sahara and Murano team's effort was invaluable in getting these fixed up and in a good state. I apologize that I have raised this as an issue. I was very concerned with the commits before knowing theses details, It was necessary to get the clarification. Let me clarify what I understand now was going on with them. Sahara. A )Fuel had a number of better parts of the fork. there where two commits [1][2] proposed to puppet-sahara from Fuel that where not merged that reflected the better side of Fuel's fork. B) The Sahara sync commit [3] into fuel represented upstream puppet-sahara C) The Adapt commit [4] contained the two commits listed prior in A, kilo support, stuff we needed to ensure it worked in fuel and Noop tests. [1] https://review.openstack.org/#/c/198744/ [2] https://review.openstack.org/#/c/192721/ [3] https://review.openstack.org/#/c/202045 [4] https://review.openstack.org/#/c/202195/ Murano D) Fuel has effectively the only usable Murano module E) The Adapt commit [5] represented * a major over hall of the code quality to make it suitable to propose upstream * fixes necessary to support kilo * cleanup for modular * Noop tests [5] https://review.openstack.org/#/c/203731/ With the improved clarity of what was going on, it made it much easier understand what I was reviewing and I'm glad of the current state. Here are my thoughts on what we can do better next time: * The commit and CR messages where not sufficient to understand entirely what was going on with the commits and how it was tested. * Separate out some of the changes into a commit chain to reduce the scope of each CR so that its easier to review. * For large reviews like this, we should let more reviewers know whats going on the ML early. These showed up on my radar late and of course, I freaked out. On Wed, Jul 22, 2015 at 6:51 AM Denis Egorenko degore...@mirantis.com wrote: Hi Andrew! Sahara already merged. All CI tests were succeeded, also was built custom iso [1] and ran bvt tests [2], which also were succeeded and we got +1 from QA team. For Murano we will do the same: resolve all comments, build custom iso, run custom bvt and wait +1 from Fuel CI and QA team. [1] http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_7.0_iso/562/ [2] http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/7.0.custom.ubuntu.bvt_2/131/ 2015-07-22 0:41 GMT+03:00 Andrew Woodward xar...@gmail.com: I was looped into reviewing the sync commits for Murano and Sahara. Both are in terrible shape and risk feature freeze at this point. We need feed back from the authors here. What is actually required for Kilo support (if any)from the Murano and Sahara modules? What will happen if these slip the release. What can you do to simplify the review scope. The most we can reasonably review is 500 LOC in any short time (and that's pushing it). Synopsis: murano [1] is -2, this can't be merged; there is a adapt commit with out any sync commit. The only way we will accept the fork method is a sync from upstream +adapt as documented in [2] also it's neigh impossible to review something this large with out the separation. -2 There is no upstream repo with content, so where did this even come from? We are/where the authority for murano at present so I'm baffled as to where this came from. Possible way through: A) Split sync from adapt, hopefully the adapt is small enough to to review. B)Make only changes necessary for kilo support. Sahara [3][4] This is a RED flah here, I'm not even sure to call it -1, -2 or something entirely else. I had with Serg M, This is a sync of upstream, plus the code on review from fuel that is not merged into puppet-sahara. I'm going to say that our fork is in much better shape at this moment, and we should just let it be. We shouldn't sync this until the upstream code is landed. Possible way through: C) The two outstanding commits inside the adapt commit need to be pulled out. They should be proposed right on top of the sync commit and should apply cleanly. I would prefer to see them as separate commits so they can be compared to the source more accurately. This should bring the adapt to something that could be reviewed. D) propose only the changes necessary to get kilo support. [1] https://review.openstack.org/#/c/203731/ [2] https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Adding_new_puppet_modules_to_fuel-library [3] https://review.openstack.org/#/c/202045 [4] https://review.openstack.org/#/c/202195/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org
[openstack-dev] [Fuel] FFE requests and status
In case you missed it, feature freeze is today and in the rush to merge things, you may have had issues with getting everything landed. For those that are not familiar with the process, to request a feature freeze exception (FFE): * You will need to raise the request to the ML here and in such message - Include [Fuel] FFE request + feature name in the subject - Document what is outstanding (Link to CR's), what's their state - Link to blueprint - Document impact of outstanding changes - Document how long you expect before it can lang * You will also need to get two of the cores in the repo(s) impacted by outstanding reviews to sponsor reviewing the outstanding CR's * Finally PTL will approve each FFE request. Please do not ask for a FFE in this thread I will update this thread with approved FFE's as they occur -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Meeting 7/23
Yep, forgot to include the topics i referred to Topics not covered in todays meeting, but requested in the agenda * ubuntu based bootstrap has been merged, needs thorough testing (kozhukalov) * Let's switch keystone under Apache right after FF (adidenko) * Separate services from controller status (mattymo) * (?) update iso build process(rpm\deb\repositories\nailgun pinning\IBP) (azvyagintsev) (didn't appear in a meeting) * (?) status of upgrade module = package (azvyagintsev) (didn't appear in a meeting) * Enable deployment through Packer and Vagrant, and/or publish vagrant boxes and Vagrantfiles for standard deployments locally (crimi) (didn't appear in a meeting) On Thu, Jul 23, 2015 at 11:10 AM Andrew Woodward xar...@gmail.com wrote: Today's meeting was a little hectic, if you have a topic on the agenda, ensure you are present and ready to speak, or move your topic lower in the agenda. When possible, pre-type you main points of discussion and copy and paste it into the channel when your topic comes up. This tends to save a bit of time and allows us to move through the topics more quickly. The minutes [2] are available and the following topics where missed. Please raise them in the ML if they should be discussed prior to the next meeting. [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda [2] http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-23-16.00.html -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Meeting 7/23
Today's meeting was a little hectic, if you have a topic on the agenda, ensure you are present and ready to speak, or move your topic lower in the agenda. When possible, pre-type you main points of discussion and copy and paste it into the channel when your topic comes up. This tends to save a bit of time and allows us to move through the topics more quickly. The minutes [2] are available and the following topics where missed. Please raise them in the ML if they should be discussed prior to the next meeting. [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda [2] http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-23-16.00.html -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] Question about unique default hostname for node
On Tue, Jul 21, 2015 at 5:38 AM Fedor Zhadaev fzhad...@mirantis.com wrote:
Hi all,
The next issue was found during implementation
https://blueprints.launchpad.net/fuel/+spec/node-naming :
User may change node hostname to any another, including default-like
'node-{№}', where № may be bigger than maximum nodeID existing at that
moment.
Later when node with ID == № will be created it's default name
'node-{ID}' will break hostnames uniqueness.
To avoid this now it was decided to generate in such situation another
default hostname.
The current solution is to generate hostname '*node-{UUID}*'. It works,
but may look terribly.
There are a few another possible solutions:
- Use '*node-{ID}-{#}*' format, where *{#} *we'll chose in loop till
the first unique.
- Use some unique value, shorter than UUID (for example - number of
microseconds from current timestamp)
I think the only solution here is to a) ensure that every hostname is
unique or refuse to update the value b)In cases that the user wants to use
our format, the only allowed format is node-{ID} where ID must be equal to
this nodes ID. we don't need to come up with some scheme to rescue the
format. We do however need some value/method that will make it reset back
to the default.
Please share you opinion - what is better?
Also you can propose your own solutions.
--
Kind Regards,
Fedor Zhadaev
Junior Software Engineer, Mirantis Inc.
Skype: zhadaevfm
E-mail: fzhad...@mirantis.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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
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] [fuel] NodeGroups vs network-templates and static routes
Ya, that makes sense now that you mention it. We will still need node groups to act as partitioning for the rack values On Mon, Jul 20, 2015 at 1:44 AM Sergey Vasilenko svasile...@mirantis.com wrote: On Thu, Jul 16, 2015 at 10:53 PM, Andrew Woodward xar...@gmail.com wrote: Regardless of computing all the routes, we need to compute same role, but multi-segement routes. In this case I see that nodegroups becomes redundant. It's only value is that it may be a simpler interface then templates but it imposes the old network topology which I could see people wanting to get away from. I do not agree with unnecessary node groups. Yes, move route calculation is a good idea and I think we should implement it. But removing node groups... When we will implement multi-rack feature we will need some abstraction for store rack-specific attributes. Node groups are seems appropriate for this role. /sv __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel][CI] Fuel-web CI is broken
I found this after noon that fuel-web CI was broken due to the recent release of oslo.config and oslo.utils 2.0.0 [1] I attempted to muck around with the pinning of the requirements.txt and had initial success with it [2] but later found that it's failing the test_check_requirements_conflicts task. I'm at a loss on how to properly fix the requirements for pbr here. I've also started another commit to get fuel web off of the old namespace [4] [1] https://bugs.launchpad.net/fuel/+bug/1476399 [2] https://review.openstack.org/#/c/203824 [3] https://ci.fuel-infra.org/job/verify-fuel-web/2626/testReport/nailgun.test.unit/test_requirements/test_check_requirements_conflicts/ [4] https://review.openstack.org/#/c/203847/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
) 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 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 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Fantastic, do we have some way to validate that the module was pulled in properly as part of fuel-library CI? On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com wrote: Hey All, I've figured it out without having to modify the fuel-main build code. I've updated the fuel-library spec with a build action that invokes the script to pull down external modules. Please take some time to review the two reviews out there for this change to see if there are any issues with the way it is implemented. https://review.openstack.org/#/c/202763/ https://review.openstack.org/#/c/202767/ This is a first step towards being able to pull in unmodified external puppet modules. Thanks, -Alex On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com wrote: On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Keep in minde we agreeded to a deadline to get this sorted and in shape to land by EOD monday or we will have to retain the old, and crappy fork method. If possible please work out how this needs to work as early as possible so Alex can continue. Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make it either conditional ( test -f ./path/additional_build_script.sh bash ./path/additional_build_script.sh ) or as additional parameter to function and add it in fuel-library call [1] Regards, Alex [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Alex, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Right. That is what I'm going for. The issue I need help with is the best way to execute this as part of the build process. From what i understand of the build process is that we are using git archive for all pieces so I'm not sure how to wedge in an extra script execution to do the module fetch. The creation of the script isn't the issue, the issue is how can I properly run it as part of the build process. Regards, Alex Thanks, -Alex On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com wrote: Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from this being a complete solution is the ability to run librarian-puppet as part of our build process for the fuel-library. I've looked into the fuel-main build scripts and I think it's over my head to figure this out just by looking. Can anyone explain to me or assist me in how I could go about
[openstack-dev] [fuel] NodeGroups vs network-templates and static routes
In 6.0 we added nodegroups as part of the multiple-cluster-networks features. With these you can add additional sets of networks with so that the nodes can exist on different network segments. When these are used you will also need to set the gateway for each of your networks. When you do this, you get routes set up between the matching network names across the nodegroups. For example network.yaml that looks like (shortened) networks: - cidr: 172.16.0.0/24 gateway: 172.16.0.1 group_id: 2 id: 6 - cidr: 172.16.10.0/24 gateway: 172.16.10.1 group_id: 3 id: 9 Will result in mappings like this in a nodes yaml (in nodegroup 2) network_scheme: endpoints: br-ex: IP: - 172.16.0.4/24 routes: - net: 172.16.10.0/24 via: 172.16.0.1 With the introduction of templates we may no longer need nodegroups. They served two functions. 1) They allowed us to create additional networks. 2) They created additional routes between networks of the same name. Comparing with what is in templates, #1 is taken care of, but what about #2? I think that we need the routes configured anyway. Nodes with the same network role should have a route for it when it crosses network segments. This would have traditionally been separated by nodegroups. but it now can be coded with templates. In this case (such as the yaml above) we must have routes for the nodes to communicate on the correct interface. Since we need code for routes between segments of the same network role, it might behoove ourselves to compute (maybe not use when they are the local interface). This serves two functions, it allows us to visualize the routing topology instead of just relying on the default route. Secondly when we get to using a routing protocol it gives us the data necessary to validate the routing protocol with what we expected. Regardless of computing all the routes, we need to compute same role, but multi-segement routes. In this case I see that nodegroups becomes redundant. It's only value is that it may be a simpler interface then templates but it imposes the old network topology which I could see people wanting to get away from. -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Meeting July 16
Meeting minutes are available at http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-16-16.00.html On Wed, Jul 15, 2015 at 3:36 PM Andrew Woodward xar...@gmail.com wrote: Please note the IRC meeting is scheduled for 16:00 UTC in #openstack-meeting-alt Please review meeting agenda and update if there is something you wish to discuss. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] New Criteria for UX bugs
I've updated the documentation on the wiki with this criteria https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Confirm_and_triage_bugs On Tue, Jul 14, 2015 at 4:22 PM Mike Scherbakov mscherba...@mirantis.com wrote: Sounds good to start, we can always adjust later if needed. I actually changed one doc bug priority already using this criteria. On Fri, Jul 10, 2015 at 5:42 AM Jay Pipes jaypi...@gmail.com wrote: On 07/09/2015 06:14 PM, Andrew Woodward wrote: We often have bugs which create really poor User eXperience (UX) but our current bug priority criteria prevent nearly all of them from being higher than medium (as they nearly always have workarounds). We need to identify what should qualify as a critical, or high UX defect so that they can receive appropriate attention. We discussed what this may look like on the IRC meeting, the general idea here is that the complexity of effort to work around the UX issue should be related to the priority. Critical: requires massive effort to work around, including [un|under] documented commands and edits to config files High: requires modification of config files, interfaces that users aren't expected to use (ie the API when it's _intended_ to work in the CLI / UI (exclusive of interfaces that are intended to only be available via API) or requires custom node yaml (again except when it should exclusively be available) Medium: Straight forward commands in the CLI Above criteria look excellent to me, thanks Andrew! -jay __ 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 -- Mike Scherbakov #mihgen __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Meeting July 16
Please note the IRC meeting is scheduled for 16:00 UTC in #openstack-meeting-alt Please review meeting agenda and update if there is something you wish to discuss. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [fuel] Deprecation and backwards compaibility Policy
Using lazy census here, I will update the wiki with this process. On Mon, Jun 29, 2015 at 4:22 PM Andrew Woodward xar...@gmail.com wrote: Some recent specs have proposed changing some of the API's by either removing parts, or changing them in non-backwards way. Additionally there are some proposals that are light on details of their impact to already supported components. I propose that deprecation and backwards compatibility should be maintained for at least one release before removing support for the previous implementation. This would result in a process such as A - A2,B - B R1 - R2- R3 Where A is the initial implementation A2 is the depricated A interface that likely converts to B back to A B is the new feature R[1,2,3] Releases incrementing. This would require that the interface A is documented in the release notes of R2 as being marked for removal. The A interface can then be removed in R3. This will allow for a reasonable time for down-stream users to learn that the interface they may be using is going away and they can adapt to the new interface before it's the only interface available. -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] wrong network for keystone endpoint in 6.1 ?
The is the expected, although security conservative approach to admin
endpoints in fuel, it does pretty much block all actions in keystone other
then auth from outside the cluster. It pre-dates me, and fuel 3.0.1; my
understanding of the intent here is that we don't want a compromise to
result in all kinds of accounts being created.
On Thu, Jul 9, 2015 at 3:35 PM Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
Hi Daniel,
answer is no - actually there is no strong dependency between public and
internal/admin endpoints. In your case keystone client ask keystone on
address 10.52.71.39 (which, I think, was provided by system
variable OS_AUTH_URL), auth on it and then keystone give endpoints list to
client. Client selected admin endpoint from this list (192.168.20.3
address) and tried to get information you asked. It's a normal behavior.
So, in Fuel by default we have 3 different endpoints for keystone - public
on public VIP, port 5000; internal on management VIP, port 5000, admin on
management VIP, port 35357.
On Thu, Jul 9, 2015 at 4:59 PM, Daniel Comnea comnea.d...@gmail.com
wrote:
Hi,
I'm running Fuel 6.1 and i've seen an interesting behavior which i think
match bug [1]
Basically the adminUrl publicUrl part of keystone endpoint are
different
And the result of that is that you can't run keystone cli - i.e
create/list tenants etc
keystone --debug tenant-list
/usr/local/lib/python2.7/site-packages/keystoneclient/shell.py:65:
DeprecationWarning: The keystone CLI is deprecated in favor of python-
openstackclient. For a Python library, continue using python-keys
toneclient.
'python-keystoneclient.', DeprecationWarning)
DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
http://10.20.71.39:5000/v2.0/tokens
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP
connection (1): 10.52.71.39
DEBUG:requests.packages.urllib3.connectionpool:POST /v2.0/tokens
HTTP/1.1 200 3709
DEBUG:keystoneclient.session:REQ: curl -g -i -X GET
http://192.168.20.3:35357/v2.0/tenants -H User-Agent: python-
keystoneclient -H Accept: application/json -H X-Auth-Token:
{SHA1}cc918b89c2dca563edda43e01964b1f1979c552b
shouldn't adminURL = publicURL = br-ex for keystone?
Dani
[1] https://bugs.launchpad.net/fuel/+bug/1441855
__
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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
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] Supporting two openstack releases in the same puppet release
It has come to my attention that we spend an enormous amount of time in Fuel when switching between OpenStack releases. A good amount of this seems to be due to a chicken and the egg problem. We cant deploy updated packages with out updated manifests, and we we cant update (in that CI won't pass) the manifests without updated packages. In order to accommodate this we either have to set up a new separate set of CI pipelines for both or freeze various parts of CI, merging patch sets that can't pass until everything is in and working, or some monstrous combination of both. This has become quite the time sink for everyone involved and there must be a better way to accommodate switching between releases. Thinking about this I wonder how much easier this process could be if the manifests supported two releases at once. I propose that we consider supporting both the dev release, and the prior release (as stable and default for option precedence). We would need to come up with some option versioning scheme in which we can identify options which are only relevant to the specific release (I'm not yet sure what sure what this would look line) This seems like it would be most of the need to support multiple versions at once. But why should we go through this effort? Yes this would become complicated to set up, however I cant imagine that other folks are not having a similar issues. * Moving to a two version system should nearly reduce the impact of switching to nearly none (given you have packages) * It should also help accelerate our releases of puppet-openstack, since devs can switch between versions more easily * It should help our release support story since non-option changes will automatically hit dev and (current) stable manifests at the same time * This can also help the current stable release process, instead of branching, we can simply tag the first stable release and maintain it in the master branch, only pushing it out when we drop it to shift the dev/stable versions * While not a direct benefit to puppet-openstack, this would help simplify fuel running CI on master openstack and master puppet-openstack which will help with our efforts in puppet-openstack So next steps Lets discuss the proposal in general (good idea / bad idea). I'd like to hash out what this versioned interface may need to look like, that way I can take up attempting to make this work in a single module so we can vet/discuss any issues more thoroughly. -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] [Fuel] New Criteria for UX bugs
We often have bugs which create really poor User eXperience (UX) but our current bug priority criteria prevent nearly all of them from being higher than medium (as they nearly always have workarounds). We need to identify what should qualify as a critical, or high UX defect so that they can receive appropriate attention. We discussed what this may look like on the IRC meeting, the general idea here is that the complexity of effort to work around the UX issue should be related to the priority. Critical: requires massive effort to work around, including [un|under] documented commands and edits to config files High: requires modification of config files, interfaces that users aren't expected to use (ie the API when it's _intended_ to work in the CLI / UI (exclusive of interfaces that are intended to only be available via API) or requires custom node yaml (again except when it should exclusively be available) Medium: Straight forward commands in the CLI Lets get some feed back on these items, and then I will update the wiki with the results. -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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
