Community på Sveriges dataportal

@lfvjimisola Vi pratade om att undvika att försöka översätta allt för mycket till svenska. Guiden ska ju vara på svenska men jag håller med om att vi bör hålla etablerade begrepp i originalspråk.
Har du (eller någon annan) några specifika exempel på ord som borde stå på engelska istället?

Har uppdaterat texten på startsidan efter diskussion med @lfvjimisola och @Maria_Dalhage igår. Många bra synpunkter. Ska även byta ut bilden till den vanliga oändlighetsbilden som vi förknippar med DevOps och hålla min interna "pedagogik" för mig själv. Sedan vill jag utvidga första sidan åt att vara en mer allomfattande introduktion till DevOps-rörelsen. Så att man inte får en felaktig uppfattning att "grejen" med DevOps är alla verktyg. Den delen är viktig men det ska inte ligga längst fram på en sida som kallar sig "DevOps-guide". Den delen kanske borde ha rubriken referensarkitektur eller liknande.

@tove

"det var EXAKT denna kravlista jag satt och tittade på när vi diskuterade idag (men hade inte sett denna tråd)."

Jag misstänkte det Inget svar ännu ang hemvist för metadata och hur Umeå matar in detta. Men blir inte förvånad om det är Excel och att man extraherar datan i säg nattliga jobb inför publicering via API, CSV och JSON.

Jag gillar ju mitt YAML-exempel här i tråden men jag är inte de flesta.

@tove jo, där har jag iaf lagt till en rubrik som placeholder för någon slags intention. Det stämmer att det är tomt där än så länge. Men om du kan se innehåll under de andra rubrikerna så fungerar din browser förhoppningsvis som den ska. Vilken browser?

@tove trevligt! Gillar formatet. Jag vill utveckla DevOpsGuiden mer åt det hållet. Verktygslåda > Uppslagsverk. Alltså mer verktygslåda än uppslagsverk.

Vill bara säga att det är himla kul att få chansen att vara med i ett större sammanhang, att bidra till den digitala arenan, för ett så viktigt syfte. Fantastiskt! Ser fram emot att engagera mig och bidra mer!

@Maria-Söderlind
Var bor er masterdata någonstans? Hur ser gränsnittet ut för de som matar in nya krav eller ändrar i kraven? Excel?

@Maria-Söderlind
Tack, precis vad jag borde ha letat efter men av någon anledning inte letade efter!

@Maria_Dalhage
Har inte läst allt här än men tänkte be dig ändra i texten till David, inte Anders Berglund. Jag är visserligen också musikintresserad så det var en glad överraskning att se namnet.

Jag gillar enthusiasmen! Hjälper gärna till att publicera den på nosad, ge den ett "neutralt hem". Allt är som sagt i markdown redan https://github.com/devopsguiden/devopsguiden.

Jag är inte förtjust i byggsteget som krävs för mkdocs, men ni har väl redan automatik för stacket som körs på nosad.

...Om det inte var tydligt redan så gillar jag att ställa korkade frågor på internet. Nu läste jag vägledningen igen och jag missförstod uppenbarligen första genomläsningen.
Metadata: RDF-format
Data: JSON eller liknande

Korrekt?

Och eftersom att YAML är ett subset av JSON så skulle vi kunna köra något i stil med mitt YAML-exempel.
Hm.. eller JSON-LD, JSON för länkad data.

<kravkatalog.yaml>
...

catalog: "https://example.com/catalog1"
  - title: "kravkatalog"
    description: "Kravkatalog för IT-upphandlingar"
    publisher: "https://example.com/publisher1"
osv...
dataset:
  - id: "0012"
    group: "Loggning"
    title: "Loggning av åtkomst"
    description: "Loggning ska ske av åtkomst till lösningen"
    priority: "Ska"
    osv: ...
  - id: "0013"
    group: "..."
    title: "..."
    description: "..."
    priority: "..."
    osv: ...
  - id: "0014"
    group: "..."
    title: "..."
    description: "..."
    priority: "..."
    osv: ...

Tänkte se om jag kan få lite handledning i att sätta en RDF-struktur enl DCAT-AP-SE för ett exempelkrav från våran kravkatalog.

Ett exempelkrav, enl <Fält>: <Data>
ID: 012
Kravgrupp: Loggning
Rubrik: Loggning av åtkomst
Kravformulering: Loggning ska ske av åtkomst till lösningen
Prioritet: Ska
Bevis: Genom att svara Ja i anbudssvaret

OBS: detta är ett exempel och är inte det kompletta kravet som vi har formulerat det.

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:dcterms="http://purl.org/dc/terms/"
	xmlns:vcard="http://www.w3.org/2006/vcard/ns#"
	xmlns:dcat="http://www.w3.org/ns/dcat#"
	xmlns:foaf="http://xmlns.com/foaf/0.1/">
<dcat:Catalog rdf:about="https://example.com/catalog1">
	<dcterms:title xml:lang="sv">Kravkatalog</dcterms:title>
	<dcterms:description xml:lang="sv">Kravkatalog för IT-upphandlingar</dcterms:description>
	<dcterms:publisher rdf:resource="https://example.com/publisher1"/>
	<dcat:dataset rdf:resource="https://example.com/dataset1"/>
	<dcterms:license rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/"/>
</dcat:Catalog>
<foaf:Agent rdf:about="https://example.com/publisher1">
	<foaf:name>Exempelkatalog</foaf:name>
</foaf:Agent>
<dcat:Dataset rdf:about="https://example.com/dataset1">
	<dcterms:id xml:lang="sv">0012</dcterms:group>
	<dcterms:group xml:lang="sv">Loggning</dcterms:group>
	<dcterms:title xml:lang="sv">Loggning av åtkomst</dcterms:title>
	<dcterms:description xml:lang="sv">Loggning ska ske av åtkomst till lösningen</dcterms:description>
	<dcterms:priority xml:lang="sv">Ska</dcterms:priority>
	<dcterms:proof xml:lang="sv">Genom att svara Ja i anbudssvaret</dcterms:proof>
	<dcterms:publisher rdf:resource="https://example.com/publisher1"/>
	<dcat:distribution rdf:resource="https://example.com/distribution1"/>
	<dcat:contactPoint rdf:resource="https://example.com/contactpoint1"/>
</dcat:Dataset>
<dcat:Distribution rdf:about="https://example.com/distribution1">
	<dcat:accessURL rdf:resource="http://example.com/api"/>
	<dcat:accessService rdf:resource="https://example.com/dataservice1"/>
</dcat:Distribution>
<vcard:Organization rdf:about="https://example.com/contactpoint1">
	<vcard:fn>Exempelorganisation</vcard:fn>
	<vcard:hasEmail rdf:resource="mailto:oppnadata@example.com"/>
</vcard:Organization>
<dcat:DataService rdf:about="https://example.com/dataservice1">
        <dcterms:title xml:lang="sv">Exempel API</dcterms:title>
        <dcat:endpointURL rdf:resource="http://example.com/api"/>
</dcat:DataService>
</rdf:RDF>

Hur ser det ut för nästa krav? Hur nestar jag in kravlistan?

Jag vet ju hur jag skulle gjort med JSON eller YAML. Kan se hur det kontinuerliga arbetet med katalogen kan hämmas av det "omständiga"/pratiga formatet, även om jag förstår syftet.

@davidlars
..glömde att be om ursäkt för mina svenskaöversättningar. Det blev en mix av engelska och svenska till slut.

@Nina_Berlin
Jag har en del jobb innan det kan bli dags för publicering men jag tänkte ändå flagga för att en trasig länk på

Den här länken:
"I Sverige har vi valt att förregistrera alla offentliga aktörer, man kan enkelt kolla om man är
förregistrerad på registrera"

@Björn-Hagström
Nja, ett API hjälper inte det syftet direkt. Första steget behöver ju vara att dela datan och ta innehållet vidare gemensamt. Sträva åt någon slags gemensam masterdata kanske. Jag är på Örebro kommun.
Ser fram emot att kika på seminariet vid tillfälle! Hoppas att du är nöjd med hur det blev.

Intressanta länkar och intressant att höra om era erfarenheter!

Förra hösten letade jag efter strukturerad dokumentation kring detta (mycket brus och svårt att pejla in signal med allt säljsnack om DevOps-produkter!). Jag hittade till slut Fundamentals Playbook för DevSecOps från Department of Defense.

Och deras DevSecOps Reference Design.

Så under en tid har jag översatt den senare (så gott jag kunnat) och lagt in den i ett exceldokument för att börja prata om det här med en större förståelse för helheten. Och för att kunna se kopplingar mellan en given aktivitet (ex versionshantering av källkod) till ett lämpligt verktyg (git) och hitta en realistisk väg framåt för en organisation som vill anamma arbetssättet. Excel har väl inte riktigt visat sig vara det roligaste formatet, varken att jobba i eller som diskussionsunderlag. Och inte optimalt för ev publicering och samarbete/diskussion externt. Så jag bestämde mig för att knacka ner innehållet i webbformat istället. Initialt mha dokumentationsgeneratorn mkdocs (men jag är inte övertygad än om att jag gillar verktyget).
Jag har valt att kalla resultatet för DevOpsGuiden.

Först och främst är jag bara väldigt tacksam att höra er tankar om formatet och innehållet och om det finns intresse att tillsammans ta det här vidare i det öppna. Jag känner att jag uppnått mitt första mål som var att lära mig om hur DevOps/DevSecOps bedrivs inom en offentlig verksamhet där detta är livsviktigt (bokstavligen). Och det har hjälpt mig med det interna arbetet med att forma rutiner och se oss om efter nödvändiga verktyg. Jag tänker att detta eller något liknande behöver underhållas och säkert kan ta nya former och uppfylla syften som jag inte tänkt på.

Jag tänker, pragmatiskt, att en konkret koppling till faktiska verktyg och varför man behöver dem är det som verkligen skulle vara värt att jobba vidare med. Företrädelsevis med tips på öppen källkodsmjukvara.

@Nina_Berlin
Intressant och inte förvånad att höra utmaningarna kring PM3

Vilken bra diskussion!
API är ju mer någon slags (del)målbild och som det påpekats sekundärt just nu. Från excel -> strukturerad plain text (enl någon smart XML-struktur) i Gitlab av det som vi är bekväma att dela känns som ett bra första steg härifrån. Jag börjar på den interna Gitlab-instansen och återkommer med delbart material och förmodligen följdfrågor innan dess.

Jo, jag förstår oron. Metadatan i detta fall har givetvis en viss nivå av konfidentialitet, möjligen på nivån "Intern: informationen ska endast spridas till medarbetare inom organisationen och till externa som har behov av informationen".
Om sedan höga krav på riktighet och tillgänglighet kommer in i bilden förs tankarna till en molnlösning i det fall man inte tror sig ha förmågan att leverera detta internt. Så vida konfidentialitetskraven inte står i vägen.

För exemplet övervakning så behöver metadata givetvis flöda till den molnbaserade övervakningsplattformen, och då gissar jag att konfidentialitetskravet "1 - Intern: informationen ska endast spridas till medarbetare inom organisationen och externa som har behov av informationen"
skulle kunna tolkas som ok? Allt är från fall till fall iofs.

Har det amerikanska företaget möjligheter att göra något av exempelvis följande:
- Installera/uppdatera programvara som körs

Inte för en hybridlösning där det just bara är övervakningen och inget annat som körs i molnet.
Man ja, för exemplet Google Anthos och Azure Arc: det är en förutsättning för att deras marknadsplatser ska fungera. Och även för uppdatering av beroenden för övervakningsfunktionaliteten. Sedan är det kunden som styr över önskade applikationscontainers och möjligheten finns att även driftsätta plattformskomponenter vid sidan om molnplattformens gränssnitt.

- Konfigurera nätverk och omdirigera trafik.

Inte nödvändigtvis för en molnplattform som endast hanterar övervakning.
För ex Anthos/Arc så finns/krävs möjligheten att styra ingress/egress och trafik inom klustret. Man säljer ju ett centralt gränssnitt för administration av miljöer både i leverantörens och det egna datacentret och även hos konkurrentens datacenter. Sedan ger man ju givetvis inte ut åtkomst för att styra nätverkskonfiguration utanför kubernetesklustret.

Lägga till eller förändra autentiseringsinformation.

Anthos/Arc kan integrera mot ex Azure AD eller andra OAuth2/OIDC tjänster. Jag ser inte direkt hur de skulle modifiera dessa, men det finns ju möjligheter att skada om man sitter som en "man in the middle". RBAC inom klustret är också en feature att kunna styra från det centrala gränssnittet i molnet.

Åtkomst till administratörsgränssnitt även om de på pappret bara används för övervakning.

Yes, om molnplattformen erbjuder funktionalitet för att administrera infra i det egna datacentret så finns det ju spakar att dra i, även om de inte ska göra det...

Jag undrar om delar av detta kan utmanas med nya molnerbjudanden kring konfidentiella plattformar. Ex så pratar Google om compute där kunddata kan vara krypterad at rest - in transit och in use (smaka på den) och gav under senaste Google Next '22 ett exempel där två banker tillsammans bygger anti-fraud lösning tillsammans på samma infrastruktur och där bådas konfidentiella data nyttjades i samma plattform men förblev oläsbar för den andra parten. Men jag gissar att det här är ett upplägg som är mer experimentiellt än så länge.