Re: [openstack-dev] [nova][infra][ci] bulk repeating a test job on a single review in parallel ?
This is some neat work. I like it. We have a graph of nodepool nodes in use in grafana[1]. Looking at a 30 day window, its pretty easy to tell that the weekends are low activity. Running big tests like this on a Saturday would be great. Of course, there won't be much infra support on that day. What we can do for running just the multinode migration test is create a new pipeline(maybe call it heavyload or something) and attach 100 copies of the test to that pipeline. Then you only need one gerrit change and you issue a 'check heavyload' comment on the review and it will run all 100 copies of the test. Gate-tempest-dsvm-multinode-live-migration-1, gate-tempest-dsvm-multinode-live-migration-2 ... and so on. I think this is better than reusing the experimental pipeline since people will try to check experimental on nova from time to time and probably don't expect to use 200 virtual machines. It's not a very clean suggestion, but it would work. Someone else might have a better idea. [1]http://grafana.openstack.org/dashboard/db/nodepool?panelId=4=1464741261723=1467333261724 -- Spencer Krum n...@spencerkrum.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
Re: [openstack-dev] [QA][Infra] Newton Code Sprint
I added a 'topics' section to the wiki. Infra has many contributors and many projects, it's valuable to know what we'll be focusing on at the sprint so people can know ahead of time if they should go. For me, I'm interested in hacking on infracloud and the hardening aspect of the puppet/ansible interaction. I know some other people want to hack on zuulv3. It's possible an etherpad is a better format for shaking out what topics people want to work on, which we can move to if people prefer. -- Spencer Krum n...@spencerkrum.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
Re: [openstack-dev] [fuel] [QA] running Fuel tests using nodepool
As a frequent tinc user I'd be interested to see the code you are using
to manage tinc into doing this. Is that code available somewhere?
On Tue, May 10, 2016, at 09:02 AM, Monty Taylor wrote:
> On 05/10/2016 08:54 AM, Vladimir Eremin wrote:
> > Hi,
> >
> > I've investigated status of nodepool multi node testing and fuel-qa
> > approaches, and I wanna share my opinion on moving Fuel testing on
> > OpenStack and nodepool.
>
> Awesome! This is a great writeup - and hopefully will be useful as we
> validate our theory that zuul v3 should provide a richer environment for
> doing complex things like fuel testing than the current multi-node work.
>
> > Our CI pipeline consists of next stages:
> >
> > 1. Artifact building and publishing
> > 2. QA jobs:
> > 2.1. Master node installation from ISO
> > 2.2. Slave nodes provisioning
> > 2.3. Software deployment
> > 2.4. Workload verification
> >
> > Current upstream nodepool limitations are pre-spwaned nodes, small
> > flavors and, only l3 connectivity. Also, we have no PXE booting and VLAN
> > trunking in OpenStack itself. So, the main problem with moving this
> > pipeline to nodepool is to emulate IT tasks: installation from ISO and
> > nodes provisioning.
> >
> > Actually the point is: to test Fuel and test rest of OpenStack
> > components against Fuel we mostly need to test stage artifact building,
> > deployment and verification. So we need to make Fuel installable from
> > packages and create overlay L2 networking. I've found no unsolvable
> > problems right now to check most of scenarios with this approach.
>
>
>
> > Besides artifact building step, there are next actions items to do to
> > run Fuel QA test:
> >
> > 1. Automate overlay networking setup. I've
> > used https://www.tinc-vpn.org/ as a L2 switching overlay, but OpenVPN
> > could be tool of choice. Action items:
> > - overlay networking setup should be integrated in fuel-devops
>
> There is overlay work in the multi-node stuff for devstack. I believe
> clarkb has a todo-list item to make that networking setup more general
> and more generally available. (it's currently done in devstack-gate
> script) I'm not sure if you saw that or if it's suitable for what you
> need? If not, it would be good to understand deficiencies.
>
> > 2. Automate Fuel master node codebase installation from packages,
> > including repo adding and deployment. Action items:
> > - installation should be integrated in fuel-devops or nodepool infra
> > - make bootstrap scripts working with more than one network on master
> > node ("Bringing down ALL network interfaces except...")
> > - fix iptables and ssh for underlay networking
>
> We've talked a few times about handling packages and repos of packages
> for patches that have not yet landed, but have done exactly zero work on
> it. Since you're a concrete use case, perhaps we can design things with
> you in mind.
>
> > 3. Automate Fuel slave node codebase installation and node enrollment.
> > Action items:
> > - nailgun-agent installation should be integrated in fuel-devops or
> > nodepool infra
> > - mcollective and ssh keys setup should be automated
> > - nailgun ang/or astute should be extended to allow pre-provisioned
> > nodes enrollment (I'm doing this part now)
> > - nailgun-agent and l23network should support overlay network interfaces
>
> Exciting. I look forward to working on this with you - there are fun
> problems in here. :)
>
>
> __
> 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
--
Spencer Krum
n...@spencerkrum.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
Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker
The module would also be welcome under the voxpupuli[0] namespace on github. We currently have a puppet-corosync[1] module, and there is some overlap there, but a pure pacemaker module would be a welcome addition. I'm not sure which I would prefer, just that VP is an option. For greater openstack integration, gerrit is the way to go. For greater participation from the wider puppet community, github is the way to go. Voxpupuli provides testing and releasing infrastructure. [0] https://voxpupuli.org/ [1] https://github.com/voxpupuli/puppet-corosync -- Spencer Krum n...@spencerkrum.com On Fri, Feb 12, 2016, at 09:44 AM, Emilien Macchi wrote: > Please look and vote: > https://review.openstack.org/279698 > > > Thanks for your feedback! > > On 02/10/2016 04:04 AM, Juan Antonio Osorio wrote: > > I like the idea of moving it to use the OpenStack infrastructure. > > > > On Wed, Feb 10, 2016 at 12:13 AM, Ben Nemec <openst...@nemebean.com > > <mailto:openst...@nemebean.com>> wrote: > > > > On 02/09/2016 08:05 AM, Emilien Macchi wrote: > > > Hi, > > > > > > TripleO is currently using puppet-pacemaker [1] which is a module > > hosted > > > & managed by Github. > > > The module was created and mainly maintained by Redhat. It tends to > > > break TripleO quite often since we don't have any 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
Re: [openstack-dev] Gerrit Upgrade 12/16
This is a gentle reminder that the downtime will be this Wednesday starting at 17:00 UTC. Thank you for your patience, Spencer -- Spencer Krum n...@spencerkrum.com On Tue, Dec 1, 2015, at 10:19 PM, Stefano Maffulli wrote: > On 12/01/2015 06:38 PM, Spencer Krum wrote: > > There is a thread beginning here: > > http://lists.openstack.org/pipermail/openstack-dev/2015-October/076962.html > > which covers what to expect from the new software. > > Nice! This is awesome: the new review panel lets you edit files on the > web interface. No more `git review -d` and subsequent commit to fix a > typo. I think this is huge for documentation and all sort of nitpicking > :) > > And while I'm at it, I respectfully bow to the infra team: keeping pace > with frequent software upgrades at this size is no small feat and a rare > accomplishment. Good job. > > /stef > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Mitaka Infra Sprint
Thanks josh -- Spencer Krum n...@spencerkrum.com On Wed, Dec 9, 2015, at 09:17 PM, Joshua Hesketh wrote: > Hi all, > As discussed during the infra-meeting on Tuesday[0], the infra team will be > holding a mid-cycle sprint to focus on infra-cloud[1]. > The sprint is an opportunity to get in a room and really work through as much > code and reviews as we can related to infra-cloud while having each other > near by to discuss blockers, technical challenges and enjoy company. > Information + RSVP:https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint > Dates:Mon. February 22nd at 9:00am to Thursday. February 25th > Location:HPE Fort Collins Colorado Office > Who:Anybody is welcome. Please put your name on the wiki page if you are > interested in attending. > If you have any questions please don't hesitate to ask. > Cheers,Josh + Infra team > [0] > http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-08-19.00.html[1] > > https://specs.openstack.org/openstack-infra/infra-specs/specs/infra-cloud.html > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack 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] Gerrit Upgrade 12/16
Hi All, The infra team will be taking gerrit offline for an upgrade on December 16th. We will start the operation at 17:00 UTC and will continue until about 21:00 UTC. This outage is to upgrade Gerrit to version 2.11. The IP address of Gerrit will not be changing. There is a thread beginning here: http://lists.openstack.org/pipermail/openstack-dev/2015-October/076962.html which covers what to expect from the new software. If you have questions about the Gerrit outage you are welcome to post a reply to this thread or find the infra team in the #openstack-infra irc channel on freenode. If you have questions about the version of Gerrit we are upgrading to please post a reply to the email thread linked above, or again you are welcome to ask in the #openstack-infra channel. -- Spencer Krum n...@spencerkrum.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
Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit
Thanks for the report Jim. I got excited about polygerrit and deployed it sortof... pointing at review-dev.o.o in case anyone wants to kick the tires. http://polygerrit.nibalizer.com/q/status:open After the gerrit upgrade next week we can point it at review.o.o. I think it would be good for infra to maintain a deploy of this software, even though it is immature right now. -- Spencer Krum n...@spencerkrum.com On Tue, Nov 10, 2015, at 05:18 AM, Markus Zoeller wrote: > David Pursehouse <david.purseho...@gmail.com> wrote on 11/10/2015 > 07:39:32 > AM: > > > From: David Pursehouse <david.purseho...@gmail.com> > > To: OpenStack Development Mailing List > <openstack-dev@lists.openstack.org> > > Cc: openstack-in...@lists.openstack.org > > Date: 11/10/2015 07:40 AM > > Subject: Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User > Summit > > [...] > > We're looking into the possibility of enabling only enough of the > > notedb to make hashtags work in 2.12. > > [...] > > +1 > > In case someone is wondering what these hashtags are, it's basically > Gerrits term for a folksonomy which usually uses the term "labels" or > "tags" (not git tags). This was previously discussed on the ML with [1]. > > [1] [openstack-dev] [infra][all] Reviews with a prio label?: > http://lists.openstack.org/pipermail/openstack-dev/2015-October/077532.html > > Regards, Markus Zoeller (markus_z) > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Infra] Gerrit downtime on November 18 2015
Hi, Gerrit will be unavailable for four hours starting at Wednesday, November 18 17:00 UTC and continuing until about 21:00 UTC. This outage is to upgrade Gerrit to version 2.11. The IP address of Gerrit will not be changing. There is a thread beginning here: http://lists.openstack.org/pipermail/openstack-dev/2015-October/076962.html which covers what to expect from the new software. If you have questions about the Gerrit outage you are welcome to post a reply to this thread or find the infra team in the #openstack-infra irc channel on freenode. If you have questions about the version of Gerrit we are upgrading to please post a reply to the email thread linked above, or again you are welcome to ask in the #openstack-infra channel. Thanks, Spencer -- Spencer Krum n...@spencerkrum.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
Re: [openstack-dev] [puppet] First Sprint proposal
It is also possible to use the openstack-infra asterisk server for voice chat. Historically this service has out-performed google hangout and bluejeans. It doesn't use video though. -- Spencer Krum n...@spencerkrum.com On Tue, Jul 14, 2015, at 09:09 AM, Emilien Macchi wrote: We decided during our weekly meeting that the Sprint will happen virtually on IRC on Wed 9/2 – Fri 9/4. We will use #openstack-sprint (freenode) IRC channel and Google Hangout / Bluejeans if needed. We made progress on defining an agenda: https://etherpad.openstack.org/p/puppet-liberty-mid-cycle Please have a look and feel free to add / complete the topics. See you there, On 07/13/2015 09:03 AM, Emilien Macchi wrote: I just closed the poll after one week. It will happen on Wed 9/2 – Fri 9/4. We'll work on the agenda during the following weeks. Best, On 07/06/2015 10:26 PM, Matt Fischer wrote: Operators mid-cycle is Aug 17-21 at a TBD location, I voted accordingly. Thanks. On Mon, Jul 6, 2015 at 12:09 PM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com wrote: On 07/06/2015 02:05 PM, Matt Fischer wrote: I think this is a great idea. I'd like to get a firm date on the operators mid-cycle before I vote though. If it overlaps, we can add more slots. Feel free to ping me on IRC for that, I'll update the doodle. Thanks, On Mon, Jul 6, 2015 at 11:31 AM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com mailto:emil...@redhat.com mailto:emil...@redhat.com wrote: Hi, I would like to organize our first sprint for contributing to our Puppet OpenStack modules. It will happen in Red Hat Montreal (Canada) office, during 3 days. If you're interested to participate, please find the slots that may work for you [1]. Any slot suggestion is welcome though. Also, please bring on the etherpad any topics we should work on together [2]. We will groom topics during a meeting and prepare the agenda before the sprint. [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle Regards, -- Emilien Macchi __ 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://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://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 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
Re: [openstack-dev] [infra][third-party] Common-CI Virtual Sprint
I'm in! -- Spencer Krum n...@spencerkrum.com On Thu, Jun 4, 2015, at 09:22 AM, Asselin, Ramy wrote: Hi, It was nice to meet many of you at the Vancouver Infra Working Session. Quite a bit of progress was made finding owners for some of the common-ci refactoring work [1] and puppet testing work. A few patches were proposed, reviewed, and some merged! As we continue the effort over the coming weeks, I thought it would be helpful to schedule a virtual sprint to complete the remaining tasks. GOAL: By the end of the sprint, we should be able to set up a 3rd party CI system using the same puppet components that the OpenStack infrastructure team is using in its production CI system. I proposed this in Tuesday's Infra meeting [1] there was general consensus that this would be valuable (if clear goals are documented) and that July 8 9 are good dates. (After the US Canada July 1st and 4th holidays, not on Tuesday, and not near a Liberty Milestone) I would like to get comments from a broader audience on the goals and dates. You can show interest by adding your name to the etherpad [3]. Thank you, Ramy irc: asselin [1] http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html [2] http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-02-19.01.html [3] https://etherpad.openstack.org/p/common-ci-sprint __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Distribution (in)dependent acceptance tests
For the puppet software itself, using the puppetlabs apt and yum repos is the standard installation procedure. The distribution provided versions are always to old, and the development effort has always been targeting the latest stable puppet release. For modules, I have always disagreed with packaging puppet modules by the operating system. Even library modules like inifile have too much volatility to be good candidates for packaging in a LTS distro. For openstack technology like puppet-keystone, the goal is to move to zuul-cloner (currently being driven by infra) so that the puppet modules can all share a gate test with each other. -- Spencer Krum n...@spencerkrum.com On Fri, May 22, 2015, at 05:21 PM, Gabriele Cerami wrote: Hi, why are current beaker-rspec tests installing puppet from puppetlabs instead of using a package from a distribution repo, like what is done for git ? More generally, spec_helper_acceptance.rb is setting up what it seems to be a distribution independent environment that is using a lot of external repos, and only in part the packages offered by the distributions. Generic dependencies (like puppet-inifile) and even specific dependencies (like puppet-keystone) are probably already offered by distribution packages. I think that doing this defeats in part the purpose of launching acceptance tests on different distributions, because a consistent part of the test environment remains always the same. -- Gabriele panda Cerami Software Engineer, Openstack CI Red Hat __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Moving forward with puppet-keystone CI (beaker tests)
Emillen, Do you see shelling out to openstackclient in the keystone test to verify that the keystone resources have been created? Do you see trying to hit the api from something like aviator? Ultimately I'd like to see us spin up an entire openstack in one test then hit it with tempest. It may be possible to use a very narrow version of tempest to validate just keystone. Thanks, Spencer On Wed, Apr 22, 2015 at 7:51 AM, Emilien Macchi emil...@redhat.com wrote: Hi, Some important work is being done on Keystone v3 API support in puppet-keystone. We've clearly seen there is a lack of review and I think we all worry about breaking something. Spencer I are working on beaker tests lately and the jobs are non-voting for now. I propose: * to review (and eventually merge) the beaker-tests patches [1] [2] for Keystone openstacklib. * to patch project-config [3] to make vote Beaker jobs in Puppet OpenStack gate for puppet-keystone puppet-openstacklib. Why voting? Because otherwise I'm not sure people will notice the failure and some patches will be merged while beaker is red. So we can have a good set of tests that will help us to detect some issues in the future. I don't think we will catch all mistakes we can do, but this is a good start. To vote this proposal, you can use the gerrit patches and let any feedback. Thanks, [1] puppet-keystone: https://review.openstack.org/#/c/155873/ [2] puppet-openstacklib: https://review.openstack.org/#/c/176098/ [3] project-config: https://review.openstack.org/176343 -- Emilien Macchi -- To unsubscribe from this group and stop receiving emails from it, send an email to puppet-openstack+unsubscr...@puppetlabs.com. -- Spencer Krum (619)-980-7820 __ 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] Key signing at the summit?
I would be excited to exchange key information at the summit. I do not have key fingerprint on my cards at this point, but I can do the old slip-of-paper method. I would be open to either organized fashion or ad-hoc. Thanks, Spencer On Mon, Oct 27, 2014 at 12:05 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-10-27 18:53:26 + (+), Marty Falatic (mfalatic) wrote: I'm relatively new to the keysigning *event* concept - can someone give a little more detail on this and where it comes into play? [...] The idea being that attendees prearrange a time, place and perhaps requisite fingerprint list to follow some process as a group, for example http://keysigning.org/methods/sassaman-projected -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Spencer Krum (619)-980-7820 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Puppet elements support
I would be happy to contribute to and help review this project.
On Sep 8, 2014 4:14 PM, Emilien Macchi emilien.mac...@enovance.com
wrote:
Hi TripleO community,
I would be really interested by helping to bring Puppet elements support
in TripleO.
So far I've seen this work:
https://github.com/agroup/tripleo-puppet-elements/tree/puppet_dev_heat
which is a very good bootstrap but really outdated.
After some discussion with Greg Haynes on IRC, we came up with the idea
to create a repo (that would be move in Stackforge or OpenStack git) and
push the bits from what has been done by HP folks with updates
improvements.
I started a basic repo
https://github.com/enovance/tripleo-puppet-elements that could be moved
right now on Stackforge to let the community start the work.
My proposal is:
* move this repo (or create a new one directly on
github/{stackforge,openstack?})
* push some bits from agroup original work.
* continue the contributions, updates improvements.
Any thoughts?
--
Emilien Macchi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] znc as a service (was Re: [nova] Is the BP approval process broken?)
Here is a docker image that will bring up subway. https://registry.hub.docker.com/u/nibalizer/subway/ On Wed, Sep 3, 2014 at 10:04 AM, Clark Boylan cboy...@sapwetik.org wrote: On Wed, Sep 3, 2014, at 07:26 AM, Ryan Brown wrote: On 09/03/2014 09:35 AM, Sylvain Bauza wrote: Re: ZNC as a service, I think it's OK provided the implementation is open-sourced with openstack-infra repo group, as for Gerrit, Zuul and others. The only problem I can see is how to provide IRC credentials to this, as I don't want to share my creds up to the service. -Sylvain There are more than just adoption (user trust) problems. An Open Source implementation wouldn't solve the liability concerns, because users would still have logs of their (potentially sensitive) credentials and conversations on servers run by OpenStack Infra. This is different from Gerrit/Zuul etc which just display code/changes and run/display tests on those public items. There isn't anything sensitive to be leaked there. Storing credentials and private messages is a different story, and would require much more security work than just storing code and test results. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev This doesn't solve the privacy issues, but subway [0] was built specifically to tackle the problem of making persistent IRC easy without needing to understand screen/tmux or znc/bip. Maybe we can sidestep the privacy concerns by providing scipts/puppet manifests/disk image builder elements/something that individuals or groups of people that have some form of trust between each other can use to easily spin up something like subway for persistent access. Unfortunately, this assumes that individuals or groups of people will have a way to run a persistent service on a server of some sort which may not always be the case. [0] https://github.com/thedjpetersen/subway Clark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Spencer Krum (619)-980-7820 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
