[openstack-dev] [sahara] Newton doc review kickoff

[Elise Gafford]

Hi Saharans,

It's time to review our documentation again, in the time-honored tradition
of our people.

The etherpad to track this effort is here:
https://etherpad.openstack.org/p/sahara-doc-days

To assign a document to yourself to review, please add your IRC handle and
update the status of the review on the appropriate document's line.

Please do:
- Assign yourself documents on which you are a subject matter expert.
- Assign yourself documents that describe features on which you've made
recent changes.
- Fix any lines which do not conform to the 79-character limit.
- Accept my grammar nitpicking with charity. :)

I'll give us a few days (until Tuesday, let's say) to assign ourselves
before I'll start prodding people, at which point I'll begin bothering us
more actively.

Cheers,
Elise
__
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] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

[Elise Gafford]

Hearty +2. Telles has been working on Sahara for years, and has been a
consistent and incisive reviewer and code contributor.

Congratulations Telles; very well deserved!

- Elise

On Thu, Aug 11, 2016 at 11:37 AM, Vitaly Gridnev 
wrote:

> Hello core team,
>
> I'd like to nominate Telles Mota Vidal Nóbrega for core reviewer team.
> Let's vote with +2/-2 for his candidacy. Review/Commits stats can be found
> at [0].
>
> [0] http://stackalytics.com/?module=sahara-group_id=tellesmvn
>
> --
> Best Regards,
> Vitaly Gridnev,
> Project Technical Lead of OpenStack DataProcessing Program (Sahara)
> 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
>
>
__
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] [tc][all] Big tent? (Related to Plugins for all)

[Elise Gafford]

Hi all,

I agree with Vitaly that Sahara's actually tried very hard to be a good
OpenStack citizen in re: integration with other Big Tent components (Heat,
Barbican, Manila, Designate...) Frequently Saharans have decided to write
such integrations in large part because it's the right thing to do for
OpenStack as an ecosystem.

At the same time, I agree with the the concerns voiced on the thread:
Sahara, like other components, has shied away from making any of the above
integrations hard dependencies; they're always strategies. Especially for
core needs like controller-to-tenant messaging, if we were to integrate
Zaqar, in order to remain perfectly stable we'd need to double our test
matrix (as it simply must work and stacks may or may not validly run Zaqar
at this point.) Big tent services (including Sahara, Trove, and others
mentioned above) do seem to me to be trying very hard to avoid becoming
leaves of the dependency graph, which is a real pity for stability and
reuse across the stack. It's absolutely true that Zaqar integration (which
would be great!) requires a lot more activation energy in the Big Tent
model than it would in the Monolithic Stack model.

I've thought about the compete-or-collaborate dynamics here a lot, though,
and in the end I don't know that there's a better governance model than
what we have. "One defcore, One OpenStack" just won't cut it eventually
(and didn't.) Organic innovation and harmful competition seem to be a bit
joined at the hip, in OpenStack and in general (I wish it weren't so daily,
but). I think the Sahara team is doing the best we can to integrate other
services as soft dependencies, as time and CI labs allow, and hope to
deprecate the pre-integration single-task stuff as we all mature together.
I suspect other teams are doing the same, and see evidence to that effect
from time to time.

I'll admit that "dependencies and collaboration are hard, and people seem
to be doing their best within that" isn't a particularly exciting stance,
but it does seem to be very true to life. :)

Cheers,
Elise Gafford
OpenStack Sahara
Senior Software Engineer, Red Hat

On Fri, Jul 15, 2016 at 5:23 PM, Vitaly Gridnev <vgrid...@mirantis.com>
wrote:

> Hello,
>
> "Less project communication" and "projects not working together because of
> fear of adding dependencies" is not so true, I think. In my opinion, Big
> Tent projects are always open for integrating with each other, and we are
> doing great job for making integration points much stronger. Since you
> pointed out Sahara on your messages, I'll iterate with examples success
> stories of integration with other projects related to sahara.
>
> 1. Since kilo/liberty we did a great job of integrating with Heat for
> deploying infrastructure for clusters, and now have fully removed all
> places where we were relying on our own implementation of the engine for
> deploying clusters, instances and so on (code name direct engine.)
>
> 2. Since liberty/mitaka we are integrated with Barbican for improved
> secret storage solution, and now we’ve implemented that by using the
> castellan library.
>
> 3. Using manila shares for datasources;
>
> 4. Around liberty/mitaka sahara produced our CLI as an OpenStack Client
> plugin;
>
> 5. Now we are working on integrating with designate for dns purposes.
>
> The general problem of projects is resources that we have in our teams and
> current goals we are going to reach. For example, for sahara our current
> prio is really stable image generation, on making much more stable
> integration tests with really good coverage of deployment clusters, work on
> preparing baremetal clusters, and securing clusters.
>
> And finally let me clarify something regarding Zaqar for using remote
> operations. Sahara and Zaqar (correct me if i'm wrong) became integrated at
> almost the same time, so that means that sahara was not able to rely on
> Zaqar properly. And we are still open to integrating sahara with Zaqar for
> remote operations. But it's not real priority for us right now because
> there are plugins which don't rely on a lot of ssh operations (like Ambari
> or Cloudera: these plugins are almost entirely relying on interacting with
> managers via APIs), and a requirement of having a few floating ips is not
> so strict even for huge deployments.
>
>
> On Fri, Jul 15, 2016 at 9:36 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
>
>> Some specific things:
>>
>> Magnum trying to not use Barbican as it adds an addition dependency. See
>> the discussion on the devel mailing list for details.
>>
>> Horizon discussions at the summit around wanting to use Zaqar for dynamic
>> ui updates instead of polling, but couldn't depend on a non widely deployed
>> subsystem.
>>
>> Each