The physical function is the one with the real PCI config space, so as
long as the host controls it then there should be minimal risk from the
guests since they have limited access via the virtual functions--typically
mostly just message-passing to the physical function.
As long as its a
On 16 January 2014 03:31, Alan Kavanagh alan.kavan...@ericsson.com wrote:
Hi fellow OpenStackers
Does anyone have any recommendations on open source tools for disk
erasure/data destruction software. I have so far looked at DBAN and disk
scrubber and was wondering if ironic team have some
On 16 January 2014 14:51, John Griffith john.griff...@solidfire.com wrote:
On Wed, Jan 15, 2014 at 6:41 PM, Michael Still mi...@stillhq.com wrote:
John -- I agree with you entirely here. My concern is more that I
think the CI tests need to run more frequently than weekly.
Completely agree,
On 16/01/14 17:32 -0500, Doug Hellmann wrote:
On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec openst...@nemebean.com wrote:
On 2014-01-16 13:48, John Griffith wrote:
Hey Everyone,
A review came up today that cherry-picked a specific commit to OSLO
Incubator, without
On 16/01/14 00:28, Clint Byrum wrote:
Excerpts from James Slagle's message of 2014-01-15 05:07:08 -0800:
I'll start by laying out how I see editing or updating nodes working
in TripleO without Tuskar:
To do my initial deployment:
1. I build a set of images for my deployment for different
Hi all,
Huge +1 for periodic syncs for two reasons:
1) it makes syncs smaller and thus easier
2) code in oslo-incubator often contains important bug fixes (e.g.
incorrect usage of eventlet TLS we found in Nova a few months ago)
Thanks,
Roman
On Fri, Jan 17, 2014 at 10:15 AM, Flavio Percoco
Hello Juilen,
I forwarded your mail to the correct mailing list. Please do not use the qa list
any longer.
I am happy that you are interested in stress tests. All the tests in
tempest/stress/actions are more or less deprecated. So what you should use
instead is the stress decorator (e.g.
On Thu, Jan 16 2014, John Griffith wrote:
As it turns out I've received a bit of push back on this, so it seems
maybe I'm being unreasonable, or that I'm mistaken in my understanding
of the process here. To me it seems like a complete and total waste
to have an oslo-incubator and common libs
Hi guys
I have another question about erasing all data from disk.
When using dd from /dev/zero could set bytes to zero from LBA0 on a disk.
But dd a whole disk will cost very very long time and the custom way is to
dd key data on the disk, for example the first 512B as MBR. But this is not
Hi,
Ceilometer's tests creates some data which could not be deleted.
For example: after creation new instance, ceilometer creates new meters for
this instance and there is no possibility to delete them. Even after
instance deletion they would not be deleted.
Should we take attention to this?
++ for generic PUT for both ‘cancel’ and ‘refresh-status’, Andrew. Thanks!
Regards,
Alexander Ignatov
On 17 Jan 2014, at 06:19, Andrey Lazarev alaza...@mirantis.com wrote:
My 5 cents:
--
REMOVE - @rest.put('/node-group-templates/node_group_template_id') - Not
Implemented
REMOVE -
Hello Marc,
Thanks for your answer.
At the moment I'm willing to spend some time on this kind of scenario so I will
see how to use the stress decorator inside a scenario test.
Does this means that all stress tests available in tempest/stress should be
ported as scenario tests with this
On Fri, Jan 17 2014, Dmitry Iakunchikov wrote:
Ceilometer's tests creates some data which could not be deleted.
For example: after creation new instance, ceilometer creates new meters for
this instance and there is no possibility to delete them. Even after
instance deletion they would not be
Hi all,
first part of the negative test framework is ready for review:
https://review.openstack.org/#/c/64733/
Please have a look.
Regards
Marc and David
DEUTSCHE TELEKOM AG
Digital Business Unit, Cloud Services (PI)
Marc Koderer
Cloud Technology Software Developer
T-Online-Allee 1, 64211
Hi guys,
I would ask in another way.
Ceilometer has a mechanism to add a sample through POST. So it looks not
consistent not to allow user to delete a sample.
IMHO, insertion and deletion through REST looks a little bit hacky: user
always has an ability to fake data collected from OpenStack
On 17 January 2014 01:16, Chris Friesen chris.frie...@windriver.com wrote:
On 01/16/2014 05:12 PM, CARVER, PAUL wrote:
Jumping back to an earlier part of the discussion, it occurs to me
that this has broader implications. There's some discussion going on
under the heading of Neutron with
On 17 January 2014 09:12, Robert Collins robe...@robertcollins.net wrote:
The physical function is the one with the real PCI config space, so as
long as the host controls it then there should be minimal risk from the
guests since they have limited access via the virtual
On Fri, Jan 17 2014, Nadya Privalova wrote:
I would ask in another way.
Ceilometer has a mechanism to add a sample through POST. So it looks not
consistent not to allow user to delete a sample.
IMHO, insertion and deletion through REST looks a little bit hacky: user
always has an ability to
Hi,
In my opinion it would be better to let the user to define a ttl value for
his/her own samples. I do not see the use case, where it is needed to delete
samples, also if the user is able to randomly delete some data, then the
statistics functions will not generate a valid output for that
For now in Fuel we keep samples forever
In case if we will use time_to_live, how long we should keep this data?
2014/1/17 Julien Danjou jul...@danjou.info
On Fri, Jan 17 2014, Nadya Privalova wrote:
I would ask in another way.
Ceilometer has a mechanism to add a sample through POST. So
On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum cl...@fewbar.com wrote:
Note that tripleo-incubator is special and should not be released. It
is intentionally kept unfrozen and unreleased to make sure there is no
illusion of stability.
I think it would be nice if we could point people at a
On 01/16/2014 10:56 PM, Matthew Treinish wrote:
Hi everyone,
With some recent changes made to Tempest compatibility with nosetests is going
away. We've started using newer features that nose just doesn't support. One
example of this is that we've started using testscenarios and we're planning
Hi all,
I've been looking at Neutron default LBaaS provider using haproxy, and while
it's working nicely, it seems to have several shortcomings in terms of
scalability and high availability. The Libra project seems to offer a more
robust alternative, at least for scaling. The haproxy
Hi Julien,
most of the cases in tempest/stress are already covered by exiting tests in /api
or /scenario. The only thing that is missing is the decorator on them.
BTW here is the Etherpad from the summit talk that we had:
https://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests
It
On Thu, 2014-01-16 at 20:59 -0800, Clint Byrum wrote:
Excerpts from Jay Pipes's message of 2014-01-12 11:40:41 -0800:
On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:
So, it's not as simple as it may initially seem :)
Ah, I should have been clearer in my statement - my
On 17/01/2014 08:19, Robert Collins wrote:
On 16 January 2014 03:31, Alan Kavanagh alan.kavan...@ericsson.com wrote:
Hi fellow OpenStackers
Does anyone have any recommendations on open source tools for disk
erasure/data destruction software. I have so far looked at DBAN and disk
scrubber
Hi,
Once we configure Interface of compute node for local_ip, then it can be used
for both IPv4 and IPv6 as well based on the deployment network.
Regards,
Balaji.P
From: Nir Yechiel [mailto:nyech...@redhat.com]
Sent: Thursday, January 16, 2014 9:28 PM
To: OpenStack Development Mailing List
On Fri, 2014-01-17 at 06:59 +, Gao, Fengqian wrote:
Hi, Jay,
Thanks for your reply.
According to you review comments, I rebase my code, please see my comments
for your questions.
For the issue that ensure there is at least one unique column in the sort
keys if pagination is used, I
Hi Marc,
The Etherpad you provided was helpful to know the current state of the stress
tests.
I admit that I have some difficulties to understand how I can run a single test
built with the @stresstest decorator (even not a beginner in Python, I still
have things to learn on this technology
To be clear - the changes that Yunhong describes below are not part of the
extensible-resource-tracking blueprint. Extensible-resource-tracking has the
more modest aim to provide plugins to track additional resource data.
Paul.
-Original Message-
From: Jiang, Yunhong
Sure Steve, that would be awesome!
The only blocker for now is that there are still happening some changes
based on feedback of what is doable / what is not. So right when we get
more confident on stable(-ish) version (or at least I'll try to sort out
widgets which should stay how they are),
Yunhong,
Thank you for bringing that up on the live migration support. In addition
to the two solutions you mentioned, Irena has a different solution. Let me
put all the them here again:
1. network xml/group based solution.
In this solution, each host that supports a provider
On Fri, Jan 17, 2014 at 08:32:19AM -0500, David Kranz wrote:
On 01/16/2014 10:56 PM, Matthew Treinish wrote:
Hi everyone,
With some recent changes made to Tempest compatibility with nosetests is
going
away. We've started using newer features that nose just doesn't support. One
example of
On 01/17/2014 03:28 AM, mar...@redhat.com wrote:
On 16/01/14 00:28, Clint Byrum wrote:
Excerpts from James Slagle's message of 2014-01-15 05:07:08 -0800:
I'll start by laying out how I see editing or updating nodes working
in TripleO without Tuskar:
To do my initial deployment:
1. I build
On 01/17/2014 09:06 AM, Koderer, Marc wrote:
Hi Julien,
most of the cases in tempest/stress are already covered by exiting tests in /api
or /scenario. The only thing that is missing is the decorator on them.
BTW here is the Etherpad from the summit talk that we had:
Keeping them separate is awesome for *us* but really, really, really
sucks for users trying to use the system.
I agree. Keeping them separate trades user usability for developer
usability, I think user usability is a better thing to strive for.
I don't understand how multiple independent
On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote:
Hi all,
I've been looking at Neutron default LBaaS provider using haproxy, and while
it's working nicely, it seems to have several shortcomings in terms of
scalability and high availability. The Libra project seems to offer a more
Thanks everyone for attending our weekly meeting :)
Meeting minutes are:
Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-17-15.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-17-15.00.txt
Log:
It seems we have two target audiences here. Developers who work on
OpenStack and developers who write apps to use it. In the long run I think
we need to optimize for both of these groups.
If we want developers to write applications to use OpenStack in python we
likely need a common python SDK.
On 17 Jan 2014, at 16:10, Jay Pipes jaypi...@gmail.com wrote:
On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote:
Hi all,
I've been looking at Neutron default LBaaS provider using haproxy, and while
it's working nicely, it seems to have several shortcomings in terms of
scalability
On Fri, Jan 17, 2014 at 1:15 AM, Flavio Percoco fla...@redhat.com wrote:
On 16/01/14 17:32 -0500, Doug Hellmann wrote:
On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec openst...@nemebean.com wrote:
On 2014-01-16 13:48, John Griffith wrote:
Hey Everyone,
A review came up today
Hey, so I think my criteria would be:
- low chance of user confusion
- little or no overhead for dev until we're more broadly ready for
long term support
So - if you want to make an incubator release branch thats fine with me but:
- please make sure the docs in the branch and trunk explain the
On Jan 16, 2014, at 9:41 PM, Jiang, Yunhong yunhong.ji...@intel.com wrote:
I noticed the BP has been approved, but I really want to understand more on
the reason, can anyone provide me some hints?
In the BP, it states that “For resize, we need to confirm, as we want to give
end user an
On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins
robe...@robertcollins.net wrote:
On 16 January 2014 14:51, John Griffith john.griff...@solidfire.com wrote:
On Wed, Jan 15, 2014 at 6:41 PM, Michael Still mi...@stillhq.com wrote:
John -- I agree with you entirely here. My concern is more that I
Hi,
In Solum project we want to use Keystone trusts to work with other
OpenStack services on behalf of user. Trusts are long term entities and a
service should keep them for a long time.
I want to understand what are best practices for working with trusts and
storing them in a service?
What are
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft don...@stufft.io wrote:
On Jan 16, 2014, at 4:06 PM, Jesse Noller jesse.nol...@rackspace.com
wrote:
On Jan 16, 2014, at 2:22 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:
Since it’s pretty easy to get lost among all the opinions I’d like
On Thu, Jan 16, 2014 at 5:42 PM, Jesse Noller jesse.nol...@rackspace.comwrote:
On Jan 16, 2014, at 4:59 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:
On 16 Jan 2014, at 13:06, Jesse Noller jesse.nol...@rackspace.com
wrote:
Since it’s pretty easy to get lost among all the opinions
Hello All,
I just took a look at this blueprint and see that it doesn't have any priority.
Was there a discussion on priority? Any idea what, if any of this will make
it into Icehouse? Also, are there going to be any further design sessions on
it?
Thanks,
Travis
From: Georgy
Hi Georgy,
The following might help with some of the trust questions you have, if you
haven't looked at it already:
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md
As far as storage implementation, trust uses sql and
Because of a pip issue with netaddr on stable/grizzly devstack, all the
stable/havana changes for jobs that include grenade are currently
blocked. This is because of stevedore's version enforcement of netaddr
versions inside the cinder scheduler.
John, Chmouel, Dean, and I have got eyes on it,
Paul, thanks for clarification.
--jyh
-Original Message-
From: Murray, Paul (HP Cloud Services) [mailto:pmur...@hp.com]
Sent: Friday, January 17, 2014 7:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] how is resource
Robert, thanks for your long reply. Personally I'd prefer option 2/3 as it keep
Nova the only entity for PCI management.
Glad you are ok with Ian's proposal and we have solution to resolve the libvirt
network scenario in that framework.
Thanks
--jyh
-Original Message-
From: Robert
+1
Nova's get-password is corrently the only safe way from a security perspective
to handle guest passwords.
This feature needs to be mirrored in Horizon, otherwise most users will
continue to resort to unsafe solutions like the clear text admin_pass due to
lack of practical alternatives.
FYI
From: Light Reading [mailto:sen...@responses.lightreading.com]
Sent: January-17-14 2:20 PM
To: Alan Kavanagh
Subject: OpenStack Cloud Virtualization Implementation Strategies
If you have trouble viewing this email, read the online
Georgy,
For Solum, let's refrain from storing any secrets, whether they be passwords or
trusts, or tokens. I definitely don't want to be in the business of managing
how to secure them in an SQL database. I don't even want admin password
values to appear in the configuration files. I'd prefer
Hi Travis,
I think it will be discussed on the mini-summit which will be on Jan
27th-28th in Washington DC.
Here is an etherpad with the summit agenda:
https://etherpad.openstack.org/p/glance-mini-summit-agenda
I hope that after F2F discussion all BPs will have priority and assignment.
Thanks
FWIW, I believe Nova is looking at using JSON Schema as well, since they
need to handle API extensions. This came up during a design session at the
HK summit.
On 1/12/14, 5:33 PM, Jamie Lennox jamielen...@redhat.com wrote:
I would prefer not to have keystone using yet another framework from the
On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote:
On 17 Jan 2014, at 16:10, Jay Pipes jaypi...@gmail.com wrote:
On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote:
Hi all,
I've been looking at Neutron default LBaaS provider using haproxy, and
while it's working nicely,
Hi Adrian,
Barbican looks good for this purpose. I will do a prototype with it.
Thanks
Georgy
On Fri, Jan 17, 2014 at 11:43 AM, Adrian Otto adrian.o...@rackspace.comwrote:
Georgy,
For Solum, let's refrain from storing any secrets, whether they be
passwords or trusts, or tokens. I
tl;dr: You're right, it would be useful. Points on what is blocking it
below:
Excerpts from James Slagle's message of 2014-01-17 05:18:01 -0800:
On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum cl...@fewbar.com wrote:
Note that tripleo-incubator is special and should not be released. It
is
Hi Rob
Then apart from the disk eraser and reinstalling the blade from scratch
everytime it is returned from lease, and ensure network isolation, what are the
other many concerns you are worried about for sharing the bare metal then?
Would really like to know what the other major issues are
Andrew, Jay and all,
Thank you for bringing this topic up. Incidentally, just a month ago at
OpenStack Israel I spoke to Monty and other HP folks about getting the
Libra initiatives integrated into LBaaS. I am happy that this discussion
is now happening on the mailing list.
I remember the
On Thu, 2014-01-16 at 15:37 +, Sullivan, Jon Paul wrote:
From: Jay Pipes [mailto:jaypi...@gmail.com]
On Thu, 2014-01-16 at 10:39 +, Sullivan, Jon Paul wrote:
From: Kyle Mestery [mailto:mest...@siliconloons.com]
FYI, here [1] are the meeting logs from today’s meeting.
On Fri, 2014-01-17 at 09:39 -0800, Vishvananda Ishaya wrote:
On Jan 16, 2014, at 9:41 PM, Jiang, Yunhong yunhong.ji...@intel.com
wrote:
I noticed the BP has been approved, but I really want to understand
more on the reason, can anyone provide me some hints?
In the BP, it states
On Thu, 2014-01-16 at 00:22 +0800, Jay Lau wrote:
Greeting,
In compute/manager.py, there is a periodic task named as
update_available_resource(), it will update resource for each compute
periodically.
@periodic_task.periodic_task
def update_available_resource(self, context):
On Fri, Jan 17, 2014 at 12:35 PM, Alan Kavanagh
alan.kavan...@ericsson.comwrote:
Hi Rob
Then apart from the disk eraser and reinstalling the blade from scratch
everytime it is returned from lease, and ensure network isolation, what are
the other many concerns you are worried about for
Yunhong,
I'm hoping that these comments can be directly addressed:
a practical deployment scenario that requires arbitrary attributes.
detailed design on the following (that also take into account the
introduction of predefined attributes):
* PCI stats report since the
Hi Alexander,
Reading your post got me to thinking. What if we modified the ssh driver so
it used the libvirt api. Just off the top of my head some thing along the
lines of changing the ssh driver to issue python-libvirt commands would
work. As an example:
shh user@host python -c \import
Jay Pipes jaypi...@gmail.com wrote on 01/17/2014 04:32:55 PM:
From: Jay Pipes jaypi...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date: 01/17/2014 04:37 PM
Subject: Re: [openstack-dev] [neutron] [third-party-testing]
Henry, thank you very much for your reply. To try to tie together our
discussion here with what's in the launchpad bug report I opened
(https://bugs.launchpad.net/neutron/+bug/1269926), here is the method used
to create the network. I'm creating the network via a UI, which does a
rest api POST
Hi,
Here are e-mail threads which keeps the history of LBaaS decisions:
LBaaS IIRC meeting minutes:
http://lists.openstack.org/pipermail/openstack-dev/2012-August/000390.html
LBaaS e-mail discussion:
http://lists.openstack.org/pipermail/openstack-dev/2012-August/000785.html
As you see there was
On Fri, 2014-01-17 at 22:30 +, Robert Li (baoli) wrote:
Yunhong,
I'm hoping that these comments can be directly addressed:
a practical deployment scenario that requires arbitrary
attributes.
I'm just strongly against to support only one attributes (your PCI
group) for scheduling
On 01/17/2014 04:20 PM, Devananda van der Veen wrote:
tl;dr, We should not be recycling bare metal nodes between untrusted
tenants at this time. There's a broader discussion about firmware
security going on, which, I think, will take a while for the hardware
vendors to really address.
What
On 17 Jan 2014, at 10:04, Jonathan LaCour jonathan-li...@cleverdevil.org
wrote:
pip install openstack
That would be awesome :)
Renat Akhmerov
@ Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 18 January 2014 09:09, Clint Byrum cl...@fewbar.com wrote:
tl;dr: You're right, it would be useful. Points on what is blocking it
below:
I'll address the bigger points here below, but for the record, I think
setup-endpoints and register-endpoint are stable enough now that they
should just
On 18 January 2014 06:42, John Griffith john.griff...@solidfire.com wrote:
On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins
robe...@robertcollins.net wrote:
Maybe this is going a bit sideways, but my point was that making a
first step of getting periodic runs on vendor gear and publicly
On Fri, Jan 17, 2014 at 3:21 PM, Chris Friesen
chris.frie...@windriver.comwrote:
On 01/17/2014 04:20 PM, Devananda van der Veen wrote:
tl;dr, We should not be recycling bare metal nodes between untrusted
tenants at this time. There's a broader discussion about firmware
security going on,
On Fri, Jan 17, 2014 at 6:24 PM, Robert Collins
robe...@robertcollins.net wrote:
On 18 January 2014 06:42, John Griffith john.griff...@solidfire.com wrote:
On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins
robe...@robertcollins.net wrote:
Maybe this is going a bit sideways, but my point was
I would like to gauge interest in a new project named Diesel.
https://wiki.openstack.org/wiki/Diesel
If you are already familiar with Savanna, the best way to describe it is:
Savanna is to map reduce applications as Diesel is to web applications.
The mission of Diesel is to allow OpenStack
Yeah - it appears that even if you clear a -1 the countdown clock still keeps
ticking, one of my reviews[0] just expired this morning. I'll bring it
up at the IPv6 meeting to restore any patches in our topic that are currently
abandoned so that you can clear them.
[0]
Hi Rob - there seems be overlap with project Solum. Can you please outline high
level differences between Diesel and Solum?
Raj
Sent from my iPad
On Jan 18, 2014, at 9:06 AM, Raymond, Rob rob.raym...@hp.com wrote:
I would like to gauge interest in a new project named Diesel.
Outlook Web MUA, forgive the top post. :-(
While a single import line that brings all the good stuff in at one shot is
very convenient for the creation of an application, it would muddy the security
picture *substantially* for the exact type of developer\customer that you would
be targeting
Please discuss this with the Solum team before proceeding. This sounds like a
complete overlap with the app deployment portion of Solum. It would make much
more sense to combine efforts than to run this as two projects.
--
Adrian
Original message
From: Rajesh Ramchandani
Hi Raj
As I see it, Solum is a set of utilities aimed at developers to use
OpenStack clouds but will not be part of OpenStack proper.
While Diesel is meant to be a service that is provided by an OpenStack
cloud (and at some point becoming part of OpenStack itself). It defines a
contract and
On 18 January 2014 12:21, Chris Friesen chris.frie...@windriver.com wrote:
On 01/17/2014 04:20 PM, Devananda van der Veen wrote:
tl;dr, We should not be recycling bare metal nodes between untrusted
tenants at this time. There's a broader discussion about firmware
security going on, which, I
On 17 January 2014 06:39, Mark Washenberger
mark.washenber...@markwash.net wrote:
There's a few more items here that are needed for glance to be able to work
with requests (which we really really want).
1) Support for 100-expect-continue is probably going to be required in
glance as well as
I can't see any reason that all of these situations can't be met.
We can finally take the openstack pypi namespace, move keystoneclient -
openstack.keystone and similar for the other projects. Have them all based upon
openstack.base and probably an openstack.transport for transport.
For the
On 17 January 2014 06:57, Mark Washenberger
mark.washenber...@markwash.net wrote:
Just throwing this out there because it seems relevant to client design.
As we've been looking at porting clients to using v2 of the Images API, its
seems more and more to me that including the *server* version
On 17 January 2014 08:03, Alexei Kornienko alexei.kornie...@gmail.com wrote:
Hello Joe,
2)Another option would be to follow waterfall process and create a solid
library interface before including it to all client projects. However such
approach this period can take unknown amount of time and
On 17 January 2014 09:22, Renat Akhmerov rakhme...@mirantis.com wrote:
Since it’s pretty easy to get lost among all the opinions I’d like to
clarify/ask a couple of things:
Keeping all the clients physically separate/combining them in to a single
library. Two things here:
In case of
On 18 January 2014 16:31, John Griffith john.griff...@solidfire.com wrote:
On Fri, Jan 17, 2014 at 6:24 PM, Robert Collins
robe...@robertcollins.net wrote:
Certainly - I totally agree that anything nothing. I was asking
about your statement of not having enough infra to get a handle on
what
91 matches
Mail list logo
