89ff4-cbde-482e-ad40-0696294ffdd1 - - - - -] Received a sync
request from an unknown host 'overcloud-novacompute-1.localdomain'.
Re-created its InstanceList.
Could this be the same bug for Queens, too?
Cody
__
Op
7;s true.
>
> Can someone clarify and then fix the comments or code?
>
Best I can tell from the Swift docs, they are the same. One creates
roles in Keystone and the other tells Swift which roles are important by
actually putting them in a config file.
--
Cody
signature.asc
Descrip
FALSE_VALUES = ['false', '0', 'off', 'no']
>
Good idea. I'd only add that we should convert 'true' and 'false' to
real booleans for Puppet's purposes since the Puppet language is now typed.
--
Cody
signature.asc
De
hat
use case into account when we do not support it either leaves us in a
place where we have to go full in on supporting them or put the modules
in a state that thoroughly frustrates and misleads users.
If we were going to put priority on which packaging systems to support
next; I'd prefer d
the old
"" pattern?
--
Cody
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack
Iury Gregory wrote:
> Hi Cody,
> If there is patches using $::os_service_default and they are blocked, I
> think the owner just need to request removal and continue the work.( I
> think )
>
Iury,
Now that the standard is $::os_service_default does it mean that current
change
Clayton O'Neill wrote:
> On Tue, Nov 17, 2015 at 4:38 PM, Cody Herriges <mailto:c...@puppetlabs.com>> wrote:
>
> Now that the standard is $::os_service_default does it mean that current
> changes up for review with parameters set to the string '
ould also just patch all our module Gemfiles temporarily to
handle the dependency.
--
Cody
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscrib
Cody Herriges wrote:
> Emilien Macchi wrote:
>> Because of [1], [2] and [3]: all beaker-rspec-dsvm-trusty jobs are broken.
>>
>> The only one option I see is to pin mime-types in beaker dependencies,
>> because beaker needs frog and frog needs mime-types.
>>
>&
st pupept-openstack modules on more Puppet
- Initial phase in of new style tests that handle beaker runs for old
style "foss" agent that is going to be stuck in the 3.8.x series and the
new style "agent" from PC1 for 4.x
Thanks,
-- Cody
Martin,
I see no reason this shouldn't just be pushed into puppetlabs-inifile. I
can't actually find a real "spec" for INI file and even the Wiki link[3]
calls out that there is no actual spec.
On Fri, Nov 27, 2015 at 5:04 AM, Martin Mágr wrote:
> Greetings,
>
> I've submitted patch to puppe
Cody Herriges wrote:
> Today we do unit testing against all kinds of puppet versions but
> beaker's acceptance testing is currently limited to the 3.8.x series.
> The is because we install "latest" Puppet from Puppet Labs repositories
> but do so using the old pack
error.
To ease into the API and manifest change you could basically combine the
glance and keystone example and use the ensure_resource function to
ensure a class resource type with the name
::openstacklib::openstackclient exists. That just puts you in the
situation where the first puppet-* mo
bowing out for as long as I did.
--
Cody
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
OPM
> will probably be easier recognizable.
The project's official name is in fact "Puppet OpenStack" so OPM would be kinda
confusing. I'd put my vote on POP because it is closer to the actual
definition of an acronym[1], which I generally find easier to remember o
through the process
of re-integrating and trying to ramp up my involvement in the community.
--
Cody
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing Li
Emilien Macchi wrote:
> I just noticed we have a second module written by Cody:
> https://github.com/ody/puppet-rally
>
> We might want to collaborate on that.
>
Yeah...I'd actually completely forgotten that existed until Emilien
mentioned it to me in IRC.
It was my resp
we're very lucky to have Alex part of our group and I would like
> to promote him core reviewer of all our modules.
>
> Team, please vote if you like the idea,
>
All positive here. +1.
--
Cody
signature.asc
Description: OpenPGP digital signature
_
me that has happened with identity_uri and auth_uri, e.g.
https://review.openstack.org/262799. If one has to simply define the
entire URI, they'll be able to properly decorate the IPv6 address.
--
Cody
signature.asc
Description: OpenPGP digital signature
_
te example of why it might
be a bad idea...pretty solidly against the transformation now.
To just provided more feedback to the user we could pass the
vncproxy_host value through a couple regexes and report a warning,
maybe? If not regex match IPv4 and not regex match brackets at
beginning an
ion X.x.x of a
> given module works with the same version of every other module, and this
> proposal would totally break that guarantee.
>
How does OpenStack solve this issue?
* Do they literally install several different versions of the same
python library?
* Does every project vendor oslo?
ssible
that I'll be finished by lunch but if not I'll join up tomorrow.
--
Cody
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
and implement
deprecations and the number one thing I learned is that it is really
time consuming. We'll need several people working on this if we want
them complete for every module by release time.
--
Cody
signature.asc
Description: OpenPG
ker. Thoughts?
>
> Let me add your attempt to make it work in puppet-cinder:
> https://review.openstack.org/#/c/224277
>
> I like the proposal, +1.
>
Hunter,
Do you off hand know what kind of overhead is generated by this?
--
Cody
signature.asc
Description: OpenPG
target parameters.
Another code example can be found in the package type.
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb#L268-L291.
--
Cody
signature.asc
Description: OpenPGP digital signature
__
nk the params pattern and inheritance can
obtain us the same goals. I also find this a valid us of inheritance
cross module namespaces but...only because all our modules must depend
on puppet-openstacklib.
http://paste.openstack.org/show/473655
--
Cody
signature.asc
Description: OpenPGP dig
e
> inherits in the classes. Just a thought.
>
That is a viable option. I can't recall which versions of puppet
support facts.d but if all that we support do we could even make it 100%
static and just put a file on disk with the contents
"servicedefault=''.
--
Cody
g it harder for someone to find and restore it.
>
In my opinion this will happen very infrequently.
--
Cody
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage
o all managed module
based on the above review on puppet-modulesync-configs. If there are no
objections to this, I'll clean up them and get them passing. In the
mean time I'll go through and just mark them all WIP.
--
Cody
signature.asc
Description: OpenPGP di
resubmit.
This of course resets all +1 and +2 and so preventing merge. Can I
please get two core post-meeting tomorrow to work with me to get them
merged?
Thanks,
--
Cody
signature.asc
Description: OpenPGP digital signature
sent on IRC during meetings & bug triage,
> he's always helpful. He has a very good understanding of Neutron &
> Puppet so I'm quite sure he would be a great addition.
>
> As usual, please vote!
+1 from me. Excited to continue seeing
e the cherry-picked changes.
https://review.openstack.org/#/c/366956/
https://review.openstack.org/#/c/366954/
https://review.openstack.org/#/c/366951/
https://review.openstack.org/#/c/366950/
https://review.openstack.org/#/c/366949/
--
many years of participation in both
communities. Looking forward to continuing to work with you in any role you
choose to take going forward.
--
Cody Herriges__
OpenStack Development Mailing List (not for usage questio
On September 9, 2016 at 10:15:09 AM, Emilien Macchi (emil...@redhat.com) wrote:
On Fri, Sep 9, 2016 at 1:12 PM, Cody Herriges wrote:
> On September 9, 2016 at 9:08:56 AM, Emilien Macchi (emil...@redhat.com)
> wrote:
>
> Hi,
>
> I wrote a little blog post about
l largely be for personal
reasons. I hope to get a more hobby like enjoyment out of the low level
practioner bits of OpenStack from here on out.
--
Cody Herriges
__
OpenStack Development Mailing List (not for usage questions)
U
y more nuanced. They're already using project groups
to provide a unified view (for all of OpenStack - which might be of dubious
value) but the trouble is that a project can only belong to one project
group.
For tripleo, you might want to look at having a launchpad admin create you
a project
Congratulations! Happy to see this important milestone. Awesome job!
On 6 Jun 2016 18:32, "Buckley, Tim Jason"
wrote:
> Hello all,
>
> I'd like to announce that StackViz will now be running at the end all
> tempest-dsvm jobs and saving visualization output to the log server.
>
> StackViz is a vis
loud/A-new-model-to-deliver-public-cloud/ba-p/6804409#.VqgUMF5VKlM
[2]
http://lists.openstack.org/pipermail/openstack-infra/2015-December/003554.html
[3] https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint
--
Cody A.W.
nt-delivery-network
[10]
http://stackalytics.com/?project_type=all&release=all&module=poppy&metric=commits
[11] https://github.com/openstack/poppy#features
Best regards,
Cody
--
Cody A.W. Somerville
_
On Wed, Feb 17, 2016 at 1:20 PM, Jay Pipes wrote:
> On 02/17/2016 09:30 AM, Doug Hellmann wrote:
>
>> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800:
>>
>>> On 02/16/2016 11:30 AM, Doug Hellmann wrote:
>>>
So I think the project team is doing everything we've asked. We
On Sat, Feb 6, 2016 at 2:14 AM, Cody A.W. Somerville <
cody.somervi...@gmail.com> wrote:
>
> I'd like to suggest we tightly scope this discussion and subsequent
> decision to Poppy exclusively. The reason for this is two fold. The first
> is so that a timely resol
touch and effort to appropriately show our appreciation.
--
Cody A.W. Somerville
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://l
pond with any comments or concerns.
>
> Thanks, Elizabeth, for all your work!
>
> -Jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack
it? Gerrit. If we were able to put up
Clippy on Gerrit for April Fools, maybe we could put something up to raise
awareness during the next election cycle? This could include linking people
to the election wiki page and reminding eligible folks to ensure they have
their correct e-mail address in Ger
On Fri, Oct 20, 2017 at 7:16 PM, Morgan Fainberg
wrote:
> Let me clarify a few things regarding the V2.0 removal:
>
> * This has been planned for years at this point. At one time (I am
> looking for the documentation, once I find it I'll include it on this
> thread) we worked with Nova and the TC
45 matches
Mail list logo
